Если речь идет об прямой отправке логов в программу (в документации это описывается как piped logs), разумеется не успевающая или ошибочно написанная программа затормозит все остальное. Программы блокируются если буфер слегка переполнен - так было задумано изначально .
Любой вариант с записью в простой файл и парсингом этого файла вам должен помочь.
LEOnidUKG, ну почему же невозможно разделить? есть iotop. Если ядро не очень старое, iotop даже отсортирует активность программ по числу операций, а не байт итого. На старых ядрах можно было счетчики с разделов или lvm-разделов снимать и тем самым оценивать опосредованно.
А если atop поставили с самого начала и не сломали, там можно старые логи посмотреть когда у вас эти проблемы хорошо проявлялись.
Все же, что в smart ?
Если ядра нагружены, тогда почему вы начали с диска ? Откуда данные, что он загружен ?
Посмотрите шапку atop - там отдельно загрузка дисков и ядер показывается. Мне htop кажется не очень показательным. Его единственный плюс в том, что он память показывает на манер windows - много свободной.
Так mysql может не только читать, но и писать. Кеш в этом случае не помогает.
Для начала на smart на SSD посмотрите. Если диск побит жизнью, то они начинают сначала на запись подтормаживать.
О, так не бывает.
Попробуйте все же проверить SMART и собрать данные iotop за бОльшие промежутки времени - по 10 сек, 1 минуте. Там ведь интервал по-умолчанию 1 секунда. Может быть, будет более ясно на что обратить внимание - на php или nginx. Тут вам заметили, что суммарная запись из шапки iotop не такая уж высокая.
Я повторюсь - как в дебиане. Это не такое очевидное выражение. Тот кто это писал, тоже помучился и отразил в комментариях в файле /etc/cron.d/mdadm :
Может. Почему бы ему не читать, если это его основная функция ?
Да всего у вас понемножку и сосредоточиться не на чем.
По-моему, nginx многовато пишет. Вот от лишней записи имеет смысл избавляться.
Используются ли буферы ответов, то есть создаются ли файлы в /var/spool/nginx/cache/ ? Агрессивное кеширование в файлы (как у сеонизаторов модно) ?
Kpd, начните с изучения данных от iotop.
AGHost, смысл в получении уверенности в сохранности данных. Спешка тут не нужна.
Некоторые считают, что нагрузка на диск такая же пластичная как на процессор. Однако, процессор может почти моментально переключиться и начать обрабатывать более приоритетную задачу. И все видели как это работает. А жесткий диск, если начал перемещать головку, то уже не может остановиться и начать перемещать в другом направлении. Единственный выход - не давать слишком оптимистичных заданий. Ограничить скорость синхронизации.
Если у вас все работает - вы диски не нагружаете полностью.
Kpd, допустим, atop покажет колонку busy. И так ясно что она у вас к 100% приближается, раз вы вообще заметили проблемы при включенной синхронизации. Но сайт должен работать все равно. Так что думать надо не об этом, а как сохранить стабильность при такой загрузке. То есть, уменьшение скорости синхронизации должно помочь.
Kpd, кажется так не сработает. Но почему бы просто не взять проверенный скрипт из debian ?
Там в первый понедельник, но не так важно месяцем раньше или позже это запустится в следующий раз.
