Мои уведомления Munin, настроенные для нашего (Debian) кластера LAMP, постоянно уведомляли меня о том, что наша нагрузка на нашу производственную машину находится на опасном уровне. В то время как средняя годовая нагрузка обычно составляет от 2 до 8, нагрузка в прошлом месяце и только за последний месяц резко выросла до 10, 18, а иногда даже 50-60. Спайки длятся всего 5-10 минут за раз и происходят примерно каждые 2-3 часа. Пики не влияют на производительность только потому, что у меня есть сценарий, который отправляет трафик с нашего сервера на зеркальный CDN, когда нагрузка превышает 10. Я искал задания cron, которые коррелируют с этим временным интервалом, но я не вижу ничего, что могло бы причина этого. Посещаемость сайта тоже нормальная (мы получаем около 200К посещений в день). База данных MySQL, на которую полагается этот веб-сервер, похоже, работает нормально. Нагрузка на этот сервер низкая, а производительность хорошая.
Я также пытаюсь вспомнить все, что я изменил в то время, когда возникла эта проблема, и я действительно ничего не могу придумать.
Это, наверное, не так уж много. Возможно, в верхней распечатке (ниже) есть подсказка, которую я не вижу.
Как мне найти причину?
- Типичный верх, когда нагрузка НЕ пиковая:
top - 11:13:09 up 472 days, 25 min, 1 user, load average: 6.08, 4.29, 3.80
Tasks: 105 total, 1 running, 104 sleeping, 0 stopped, 0 zombie
Cpu(s): 41.2%us, 5.8%sy, 0.0%ni, 49.5%id, 2.7%wa, 0.1%hi, 0.7%si, 0.0%st
Mem: 3369592k total, 2166980k used, 1202612k free, 559504k buffers
Swap: 2650684k total, 1892k used, 2648792k free, 1129116k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
32046 apache 15 0 36300 12m 9828 S 20 0.4 0:01.97 apache2
32679 apache 15 0 36568 13m 10m S 19 0.4 0:01.69 apache2
31441 apache 15 0 36616 13m 10m S 19 0.4 0:04.13 apache2
31477 apache 15 0 36596 13m 9.8m S 15 0.4 0:01.99 apache2
31993 apache 15 0 36876 16m 12m S 12 0.5 0:02.01 apache2
31782 apache 15 0 36836 14m 10m S 8 0.4 0:02.17 apache2
32198 apache 15 0 36536 13m 10m S 7 0.4 0:01.59 apache2
880 apache 15 0 36508 9708 6236 S 7 0.3 0:00.42 apache2
31945 apache 17 0 36876 16m 13m S 5 0.5 0:03.17 apache2
32197 apache 16 0 36636 10m 7504 S 5 0.3 0:02.70 apache2
32326 apache 15 0 37024 11m 7632 S 5 0.3 0:02.15 apache2
32565 apache 15 0 37280 13m 9.8m S 5 0.4 0:03.75 apache2
32676 apache 15 0 36896 16m 12m S 4 0.5 0:00.95 apache2
32678 apache 15 0 36536 12m 9692 S 4 0.4 0:02.27 apache2
974 apache 16 0 37064 9888 6016 D 4 0.3 0:00.13 apache2
32150 apache 16 0 36832 13m 10m S 3 0.4 0:01.74 apache2
31780 apache 16 0 36848 11m 7660 S 3 0.3 0:02.87 apache2
И вот вершина, когда мы набираем обороты:
top - 15:25:22 up 474 days, 4:37, 1 user, load average: 78.73, 50.20, 24.79
Tasks: 250 total, 4 running, 244 sleeping, 0 stopped, 2 zombie
Cpu(s): 36.5%us, 4.7%sy, 0.0%ni, 56.4%id, 2.0%wa, 0.1%hi, 0.3%si, 0.0%st
Mem: 3369592k total, 2099904k used, 1269688k free, 553840k buffers
Swap: 2650684k total, 5104k used, 2645580k free, 729252k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27716 apache 15 0 43612 20m 9.8m S 20 0.6 0:01.95 apache2
16782 apache 16 0 39460 19m 13m R 19 0.6 0:04.61 apache2
19701 apache 15 0 39232 16m 10m S 17 0.5 0:03.18 apache2
19677 apache 16 0 39208 15m 9956 R 12 0.5 0:05.03 apache2
16760 apache 15 0 36620 16m 13m S 8 0.5 0:06.35 apache2
19798 apache 15 0 36564 13m 9988 S 6 0.4 0:02.76 apache2
20325 apache 15 0 36616 13m 9704 S 6 0.4 0:02.11 apache2
19699 apache 15 0 36860 15m 12m S 5 0.5 0:03.10 apache2
15109 apache 15 0 36624 16m 13m S 4 0.5 0:05.97 apache2
15101 apache 15 0 36592 13m 10m S 3 0.4 0:08.96 apache2
15112 apache 15 0 36612 16m 13m S 3 0.5 0:07.57 apache2
20204 apache 15 0 44612 21m 9.9m S 3 0.6 0:03.55 apache2
19624 apache 15 0 36588 13m 10m S 3 0.4 0:02.00 apache2
20151 apache 15 0 36616 16m 13m S 3 0.5 0:02.14 apache2
26252 apache 15 0 37072 13m 9m S 3 0.4 0:01.09 apache2
19805 apache 15 0 36472 16m 12m S 2 0.5 0:03.68 apache2
20163 apache 15 0 36640 13m 10m S 2 0.4 0:02.50 apache2
27260 apache 18 0 44292 20m 9328 S 2 0.6 0:02.08 apache2
29149 apache 15 0 36172 11m 8744 S 2 0.4 0:00.69 apache2
20315 apache 15 0 36360 15m 12m S 2 0.5 0:02.06 apache2
29148 apache 16 0 36184 8872 5644 S 2 0.3 0:00.08 apache2
На самом деле Loadavg мало что говорит о том, работает ли ваша система неэффективно; это очень общий показатель, который описывает, насколько занята ваша система, где занятость определяется как индекс количества процессов, которые в данный момент либо выполняются, либо ожидают выполнения инструкции процессора. В восьмиъядерной системе, где рабочая нагрузка описывается короткоживущими процессами большого объема (например, веб-сервером), loadavg более 50 может даже не привлечь мое внимание.
Можете ли вы сопоставить эти всплески с вашими журналами Apache, чтобы увидеть, страдает ли время отклика в периоды всплесков? Вы просто обслуживаете больше запросов во время пиков? Вы ведете статистику по таким вещам, как iowait и пользователь и системный процессор, и коррелируют ли они? Другой плакат, который упомянул подкачку, прав: подкачка может вызвать накопление процессов, поскольку доступ к памяти замедляется до скорости диска, что может привести к более высокой загрузке, поскольку процессы зависают.
Это все, что нужно исследовать; дополнительные данные и данные, хранящиеся в прошлом, могут помочь вам решить эту проблему. Надеюсь это поможет; удачи!
Согласно появившемуся новому системному администратору, нагрузка стала настолько высокой, потому что в последнее время мы постоянно превышаем пропускную способность выделенной полосы пропускания (не уверен, входящий или исходящий). Некоторые респонденты на этот вопрос правы в том, что это вовсе не признак проблемы с сервером. Это проблема сети, при которой новые запросы должны ждать, пока не освободится пропускная способность, прежде чем они смогут продолжить - отсюда и высокая нагрузка (задержка). В любом случае, недавно мы переехали в новый центр обработки данных с гораздо большей пропускной способностью. Спасибо всем!
Если ваши приложения Apache работают с серверной частью базы данных, вполне возможно, что вы столкнулись с проблемами блокировки / конкуренции на стороне базы данных. Часто создаваемые (или повторно используемые) процессы apache просто ждут завершения длительного запроса к базе данных и, таким образом, накапливаются до большого числа.
Поэтому проверьте, отражает ли ваш сервер базы данных изображение загрузки. Если вы используете MySQL (это буква M в LAMP, не так ли?), Вам следует подумать об использовании mysql-snmp для более подробного отчета.
Используете ли вы что-нибудь вроде Memcached на сервере? Срок действия TTL истекает примерно в это время?
Действительно ли влияет на производительность, когда нагрузка превышает 100%? В многоядерных процессорах это, скорее всего, нормально.
P.S также похоже, что вы погружаетесь в распределение SWAP; Я бы посмотрел на это.