Как найти причину роста нагрузки на сервер

12

У меня проблемы с загрузкой на моем сервере, и хотя я несколько опытный администратор Linux, у меня нет идей.

Проблема заключается в медленно, но неуклонно увеличивающейся нагрузке на сервер без видимой причины.

Сервер представляет собой двухъядерный процессор AMD Athlon (tm) 64 X2 6000+ с 6 ГБ ОЗУ. Он работает под управлением Debian Stable с Linux gir 2.6.26-2-amd64 # 1 SMP Ср 19 августа 22:33:18 UTC 2009 x86_64 GNU / Linux.

Сервер в основном работает с Lighttpd, несколькими процессами FastCGI PHP и базой данных MySQL. Типичные задачи веб-сервера.

Процессор никогда полностью не используется, а память в основном используется для буферов и кеша, что нормально. Я попытался перезапустить различные службы, чтобы увидеть, уменьшит ли один из них нагрузку снова, но безуспешно.

Вот графика, показывающая нагрузку, процессор и IOStat:

Итак, вопрос: что может вызвать медленно, но постоянно увеличивающуюся нагрузку? И как мне узнать, что за это отвечает?

Обновление: я забыл упомянуть, когда я перезагружаю сервер, нагрузка снизится примерно до 0,3 до 0,6 и начнет медленно подниматься в течение следующих недель.

linux

— Андреас Гур
источник

1

Изображения, которые вы разместили, больше не существуют. Пожалуйста, не стесняйтесь повторно загружать их, если у вас все еще есть копии.

— Майкл Хэмптон

6

Каждый процесс зомби добавляет 1,0 к нагрузке. Возможно, вы видите скопление зомби.

Да. Проверьте график « Количество процессов ».

— Тедди

Если это было правильно, то набора текста for N in {1..100} ; do sleep 60 & done ; exec sleep 500должно быть достаточно, чтобы вызвать высокую нагрузку. Но это не так. Эта команда производит 100 зомби, но нагрузка на мой компьютер осталась ниже 1.

— kasperd

5

Я нашел отличный намек в ответ на другой вопрос .

Поиск процессов в состоянии «D» показывает четыре PHP-процесса, которые, по-видимому, довольно долго зависают, что соответствует «шагам» в кривой нагрузки:

#> ps aux | awk '$8 ~ /D/  { print $0 }'
wiki      6651  0.0  0.0      0     0 ?        D    Oct04   0:41 [php-cgi]
bugs      6731  0.0  0.0      0     0 ?        D    Oct27   0:14 [php-cgi]
manpages  7536  0.0  0.0      0     0 ?        D    Oct30   0:21 [php5-cgi]
wiki     23847  0.0  0.0      0     0 ?        D    Oct06   1:32 [php-cgi]

Так что, похоже, это проблема. Теперь мне нужно выяснить, когда эти процессы зависают, и как это исправить. Спасибо всем.

— Андреас Гур
источник

Этот ответ решил мою проблему. Нагрузка увеличилась с 0,5 до 350 и продолжала расти. Это было из-за процессов зомби, пытающихся прочитать удаленную удаленную папку.

— Филипп Делтейл

2

Я предполагаю, что сервер нуждается в IO, возможно, вам следует добавить статистику iotop к графикам

Интересно, можете ли вы иметь активность для каждого приложения, которая также является фактором нагрузки на сервер

http://rt.wiki.kernel.org/index.php/I/Otop_utility

другой инструмент - это dstat

— Mariuz
источник

Я также добавил графику для IOStat. Дисковый ввод-вывод не увеличивается по мере загрузки. Это то, к чему ты стремился?

— Андреас Гор

Ох и dstat выглядит полезным. Я должен прочитать немного больше об этом.

— Андреас Гор

2

Если бы это был ввод / вывод, то он бы увидел iowait (розовый) на графиках процессора.

— 3molo
источник

0

Проблемы такого рода часто возникали из-за того, что жесткий диск недостаточно быстр, чтобы обслуживать данные, необходимые для базы данных MySQL и HTTP-сервера. Вы должны посмотреть на команду iostat

IO выглядит нормально для меня. И это не объясняет, почему нагрузка медленно увеличивается.

— Андреас Гор

-1

Вообще говоря, неплохо иметь высокую нагрузку на сервер; это означает, что вы не сидите без дела и делаете меньше, чем могли бы. Нагрузка 80% -90% от общей емкости (с некоторым «взрывным» пространством) - это то, что обычно ищут. Я бы порекомендовал проверить вывод mpstat и vmstat. В частности, первые 2 числа из vmstat могут дать вам более значимую информацию о том, насколько вы «зарезервированы» с точки зрения процессов в очереди выполнения. В последнем столбце ("wa") вывода vmstat можно указать, ожидаете ли вы завершения ввода-вывода и как долго. Размер очереди выполнения и время ожидания ввода / вывода часто коррелируют. Также проверьте sar (из пакета sysstat): он дает вам подробное представление о том, что происходит за определенный период времени; метрики, которые он записывает, очень тщательны.