«Средняя загрузка» на машине * nix - это «средняя длина очереди выполнения», или, другими словами, среднее количество процессов, которые что-то делают (или ждут, чтобы что-то сделать). Хотя концепция достаточно проста для понимания, устранение неполадок может быть менее простым.
Вот статистика сервера, над которым я работал сегодня, и заставила меня задуматься, как лучше всего исправить подобные вещи. Вот статистика:
В конце концов я "исправил" проблему, перезапустив MySQLd ... что не имеет большого смысла, потому что, согласно команде mysql "show processlist", сервер теоретически простаивал.
Какие еще инструменты / показатели мне следовало использовать, чтобы помочь диагностировать эту проблему и, возможно, определить, что вызвало такую высокую нагрузку на сервер?
Похоже, ваш сервер привязан к вводу-выводу - следовательно, процессы сидели в D штат.
Использовать iostat чтобы увидеть, какая нагрузка на ваши диски.
Если MySQL вызывает много обращений к диску, рассмотрите возможность размещения данных MySQL на совершенно отдельном физическом диске. Если он по-прежнему медленный и является частью настройки главный-подчиненный, поместите журналы репликации также на отдельный диск.
Обратите внимание, что отдельного раздела или логического диска недостаточно - обычно ограничивающим фактором является время поиска, а не скорость передачи данных.
Возвращаясь к этому 6 лет спустя, я понял, что никакой ответ здесь бесполезен. Вот самый простой способ узнать, что влияет на среднюю нагрузку в Linux:
# View processes and threads affecting load average
ps auxH | grep -v " S"
Причина, по которой вы можете получить среднюю нагрузку 25 только с 3 запущенными процессами, заключается в том, что каждый поток индивидуально учитывается в средней нагрузке. В H возможность ps отображает потоки, как если бы они были процессами.
При средней загрузке 25 и только 2-3 процессах, которые запрашивают процессор, звучит немного странно. Загрузка 25 означает, что в вашей системе постоянно 25 процессов, которые находятся в состоянии «Выполняется» (R) или «Непрерывно» (D). Некоторые комментарии отмечают, что потоки, не показанные в ps aux, считаются активными в очереди выполнения. Вы можете увидеть тему с ps axms. То, как они точно учитываются в нагрузке, зависит от используемой Системы.
Но что действительно важно знать. Нагрузка абсолютно не связана с загрузкой процессора. Если каждый из этих процессов использует только 1% ЦП, а затем блоки, у вас также будет средняя нагрузка 25.
Итак, я предполагаю, что в то время, когда ваша нагрузка увеличивается до 25, у вас слишком много процессов, которые нуждаются в io и не получают его. Поэтому они блокируются и ждут доступа для ввода или записи. Все они попадают в настоящую очередь выполнения, и ваша нагрузка достигает этого уровня.
Если у вас есть только 2-3 активных процесса, следите за потоками. Ваша система может достичь средней загрузки 25, только если количество процессов и / или потоков в заданный период времени составляет 25.
Если это постоянно, у вас проблема. Если это происходит только один или два раза в день, следите за дорогостоящими операциями ввода-вывода cronjobs и измените время их выполнения.
Также другой проблемой может быть сценарий или программа, которая запускает 25 потоков или процессов одновременно, и эти процессы или потоки блокируют друг друга. Я предполагаю, что загрузка ЦП в данный момент также очень высока, и система не удовлетворяет все запросы, которые запрашиваются в это время.
Если у вас ядро> 2.6.20, я предлагаю использовать iotop вместо vmstat. iotop показывает текущий ввод-вывод системы в виде сверху в реальном времени. Может это тебе поможет.
Еще один отличный инструмент для демонстрации использования ЦП и процессов - htop. Он показывает использование ЦП каждого процессора в виде небольшого графика, все три загрузки + графическая полоса памяти и используемого пространства подкачки.
У вас ведь не закончилось место? Вы не упоминаете оборудование проблемы, много свободной оперативной памяти и т. д. Либо больше нет свободного места (возможно, в / var?), либо ваша база данных mysql смонтирована на удаленном диске и возникают проблемы с сетью.
В таких ситуациях мне нравится Мунинили аналогичный, контролировать рассматриваемый сервер. Таким образом, вы получите историю, представленную в виде графика, которая вполне может дать хорошие подсказки в том, в какой области изначально начала проявляться нагрузка. Кроме того, стандартная установка Munin поставляется с хорошим набором предварительных тестов.