История изменений
Исправление DALDON, (текущая версия) :
И так!
Результаты следующие: Во-первых мне тут подсказали использовать iotop. За что отдельное спасибо.
В общем теперь процессы rm -rf стали жить в режиме: idle. la по-прежнему высок. Но теперь войти на сервер по ssh можно со второго раза. В общем, субъективно, стало жить полегче немного. Но...
Вот чего говорит iotop: в те моменты, когда отрабаывает rm -rf, он говорит нечеловеческим голосом, что забивают всё на свете процессы: kworker (их много) и процесс: jbd2/sda3-8 - тот, так вообще тащится то того чем он занимается...
jbd2 - это журнал насколько я понял. А вот про kworker - не очень понятно. Но они убираются, когда убирается активный rm -rf. Думаю это служебные процессы ядра.
В спокойном состоянии, jbd2 кушает: 8-50 % i/o, судя по iotop.
Что делать? Можно-ли журнал перенести на SSD? Или выбрать другую ФС - для множества мелких файлов (512-1 мб)?
P.S.
find / -name 
reprimand MrClon
Может вынести: /var/www/zm - в отдельную фс, с опцией:
* writeback mode In data=writeback mode, ext4 does not journal data at all. This mode provides a similar level of journaling as that of XFS, JFS, and ReiserFS in its default mode - metadata journaling. A crash+recovery can cause incorrect data to appear in files which were written shortly before the crash. This mode will typically provide the best ext4 performance.
Исправление DALDON, :
И так!
Результаты следующие: Во-первых мне тут подсказали использовать iotop. За что отдельное спасибо.
В общем теперь процессы rm -rf стали жить в режиме: idle. la по-прежнему высок. Но теперь войти на сервер по ssh можно со второго раза. В общем, субъективно, стало жить полегче немного. Но...
Вот чего говорит iotop: в те моменты, когда отрабаывает rm -rf, он говорит нечеловеческим голосом, что забивают всё на свете процессы: kworker (их много) и процесс: jbd2/sda3-8 - тот, так вообще тащится то того чем он занимается...
jbd2 - это журнал насколько я понял. А вот про kworker - не очень понятно. Но они убираются, когда убирается активный rm -rf. Думаю это служебные процессы ядра.
В спокойном состоянии, jbd2 кушает: 8-50 % i/o, судя по iotop.
Что делать? Можно-ли журнал перенести на SSD? Или выбрать другую ФС - для множества мелких файлов (512-1 мб)?
Исправление DALDON, :
И так!
Результаты следующие: Во-первых мне тут подсказали использовать iotop. За что отдельное спасибо.
В общем теперь процессы rm -rf стали жить в режиме: idle. la по-прежнему высок. Но теперь войти на сервер по ssh можно со второго раза. В общем, субъективно, стало жить полегче немного. Но...
Вот чего говорит iotop: в те моменты, когда отрабаывает rm -rf, он говорит нечеловеческим голосом, что забивают всё на свете процессы: kworker (их много) и процесс: jbd2/sda3-8 - тот, так вообще тащится то того чем он занимается...
jbd2 - это журнал насколько я понял. А вот про kworker - не очень понятно. Но они убираются, когда убирается активный rm -rf. Думаю это служебные процессы ядра.
В спокойном состоянии, jbd2 кушает: 8-50 % i/o, судя по iotop.
Что делать? Можно-ли журнал перенести на SSD?
Исходная версия DALDON, :
И так!
Результаты следующие: Во-первых мне тут подсказали использовать iotop. За что отдельное спасибо.
В общем теперь процессы rm -rf стали жить в режиме: idle. la по-прежнему высок. Но теперь войти на сервер по ssh можно со второго раза. В общем, субъективно, стало жить полегче немного. Но...
Вот чего говорит iotop: в те моменты, когда отрабаывает rm -rf, он говорит нечеловеческим голосом, что забивают всё на свете процессы: kworker (их много) и процесс: jbd2/sda3-8 - тот, так вообще тащится то того чем он занимается...
jbd2 - это журнал насколько я понял. А вот про kworker - не очень понятно. Но они убираются, когда убирается активный rm -rf. Думаю это служебные процессы ядра.
В спокойном состоянии, jbd2 кушает: 8-50 % i/o, судя по iotop.
Что делать? Можно-ли журнал перенести на SSD?