Назад | Перейти на главную страницу

Стек LAMP на 64-битном 16-ядерном блоке потребляет 100% ЦП

=== РЕШЕНО ===

Эта проблема решена. Оказывается, у ImageMagick проблемы с несколькими процессорами. Компиляция ImageMagick для использования одного процессора решила проблему.

================

Я добавил новый веб-сервер в качестве обновления, но он отключается в течение нескольких секунд.

В старой коробке 8 ядер Xeon с частотой 2,33 ГГц. Новая машина имеет 16 ядер Xeon с тактовой частотой 2,40 ГГц. Память на новой машине составляет 8 ГБ и 32 ГБ.

Другое важное отличие - это переход с 32-битной на 64-битную.

ОС - CentOS 5.6 на обоих, и Apache 2.2.3-45 на обоих.

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

Судя по всей этой информации, новая машина будет кричать, но текущая коробка справляется с нагрузкой и время от времени падает. Новая машина умирает каждый раз менее чем за минуту.

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

старая коробка

09:14:18 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
09:14:20 PM  all   31.34    0.00    2.62    9.68    0.12    1.00    0.00   55.24  11163.50
09:14:20 PM    0   53.00    0.00    5.50   16.00    0.50    6.50    0.00   18.50  10249.50
09:14:20 PM    1   36.68    0.00    2.51   11.06    0.00    0.00    0.00   49.75    126.00
09:14:20 PM    2   17.41    0.00    1.99    7.96    0.00    0.00    0.00   72.64    125.50
09:14:20 PM    3   41.00    0.00    3.00    9.00    0.00    0.00    0.00   47.00    125.50
09:14:20 PM    4   30.00    0.00    2.00    7.50    0.00    0.50    0.00   60.00    143.00
09:14:20 PM    5   28.50    0.00    2.00   12.00    0.00    0.00    0.00   57.50    142.50
09:14:20 PM    6   22.61    0.00    1.51    7.54    0.00    0.00    0.00   68.34    125.50
09:14:20 PM    7   21.50    0.00    2.50    6.50    0.00    0.00    0.00   69.50    125.50

новая коробка

09:13:41 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
09:13:43 PM  all   98.69    0.00    0.81    0.00    0.03    0.47    0.00    0.00   4723.50
09:13:43 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   1000.50
09:13:43 PM    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    2  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    3  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    4   98.01    0.00    1.49    0.00    0.00    0.50    0.00    0.00      0.00
09:13:43 PM    5  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    6  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    7   98.51    0.00    1.49    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    8  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM    9   99.50    0.00    0.50    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   10  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   11  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   12   95.50    0.00    4.00    0.00    0.00    0.50    0.00    0.00     84.50
09:13:43 PM   13  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   14  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00      0.00
09:13:43 PM   15   87.56    0.00    4.98    0.00    0.50    6.97    0.00    0.00    3640.0

Трафик проходит через балансировщик нагрузки и распределяется между ними 50/50. Как только я включаю новую машину, загрузка резко возрастает до 200, и мне приходится выключать ее, поскольку она перестает принимать запросы.

strace против httpd не кажется таким показательным, но вот результат команды strace -c -f -p 

% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 73.52    2.763912         419      6594      1663 futex
  8.65    0.325110          55      5869      4099 open
  5.35    0.201250         107      1873       381 stat
  3.12    0.117305          67      1748       165 lstat
  2.30    0.086434        2010        43           wait4
  1.64    0.061543           7      8825       769 read
  1.31    0.049158         125       394           clone
  0.77    0.028874          53       543           chdir
  0.75    0.028356          29       973           munmap
  0.34    0.012783          35       370           times
  0.30    0.011298         257        44           madvise
  0.24    0.008897           7      1312           fstat
  0.22    0.008225           1      9341         2 poll
  0.18    0.006682           2      2777        14 write
  0.14    0.005358           5      1184           mmap
  0.13    0.005020          19       262           set_robust_list
  0.13    0.004990           3      1688        30 writev
  0.13    0.004799           7       671       598 access
  0.08    0.003194           0      6531           recvfrom
  0.06    0.002404           4       673         8 sendto
  0.06    0.002398           4       578           getcwd
  0.06    0.002367           5       491           mprotect
  0.05    0.002013           4       457           brk
  0.05    0.001965           2       883           semop
  0.05    0.001924           3       760           lseek
  0.04    0.001622           2       845           setitimer
  0.04    0.001525           4       412           epoll_wait
  0.04    0.001486           1      2595           close
  0.04    0.001430           3       412           accept
  0.04    0.001429           3       433       231 connect
  0.04    0.001388           1      1185           rt_sigaction
  0.03    0.000999           2       594           rt_sigprocmask
  0.03    0.000963           0      2325           fcntl
  0.02    0.000935           1       690           setsockopt
  0.01    0.000393           1       534           socket
  0.01    0.000380           1       393        12 shutdown
  0.00    0.000158           1       127           setuid
  0.00    0.000156           0       411           getsockname
  0.00    0.000156           2        70        46 unlink
  0.00    0.000080           0       254           epoll_ctl
  0.00    0.000000           0        64           ioctl
  0.00    0.000000           0        38         6 select
  0.00    0.000000           0        10           alarm
  0.00    0.000000           0       230           getsockopt
  0.00    0.000000           0         3           rename
  0.00    0.000000           0        22           getrusage
  0.00    0.000000           0       127           setgid
  0.00    0.000000           0       254           geteuid
  0.00    0.000000           0       127           setgroups
  0.00    0.000000           0       127           epoll_create
------ ----------- ----------- --------- --------- ----------------
100.00    3.759359                 67166      8024 total

========== РЕДАКТИРОВАТЬ / ОБНОВЛЕНИЕ ==========

Я обнаружил, что когда я ограничил трафик до 10% на балансировщике нагрузки, как было предложено, он все равно рушился. Когда я победил его с осадой и 400 связями, он держался очень хорошо. Нагрузка увеличилась, но колебалась в районе 6 и обслуживала все запросы.

У меня отключены журналы доступа, но я немного включил и сказал балансировщику нагрузки снова начать отправку трафика. Я оставил это работать до тех пор, пока нагрузка не достигнет 200, что заняло около 3 минут, и сохранил журнал.

Я проанализировал журнал на предмет запросов на использование с осадой. Это дало бы мне более точный тест.

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

Пока что это похоже на то, что интенсивно использует ImageMagick, но я сократил 10K запросов GET до 50 и все еще продолжаю.

Это будет не столько ответ, сколько ряд шагов, которые помогут вам отследить это.

  1. Установите Ganglia: http://ganglia.sourceforge.net/. Это мой любимый инструмент для устранения неполадок с загрузкой. Тебе понравится.
  2. Посмотрите, сможете ли вы использовать балансировщик нагрузки для отправки меньшего процента трафика, скажем 5%, на ваш новый сервер. Надеюсь, это позволит вашему серверу дольше работать.
  3. Запустите top на своем новом сервере и выполните сортировку по ЦП с помощью ключа сортировки "P". Посмотрите, что занимает большинство циклов.
  4. Дважды проверьте все привязки PHP к MySQL и Apache, и библиотеки установлены правильно. Это мой подозреваемый номер один в том, что идет не так, исходя из информации, которую вы предоставили на сегодняшний день. Тот факт, что вы вручную скомпилировали свой PHP, также поднимает потенциальный красный флаг. Дважды проверьте параметры конфигурации и убедитесь, что ничего не изменилось в том, что ожидается или требуется при изменении 32/64 бит.
  5. Включите и посмотрите журналы: журналы ошибок php error_log и apache, чтобы увидеть, что происходит. Это всегда информативно, но вам нужно отделить сигнал от шума в вашей конкретной среде.

Один или несколько из этих шагов могут помочь понять, что идет не так.

Если вы переключитесь на пакеты php или php53 вашего дистрибутива, будет ли по-прежнему возникать высокая загрузка ЦП?

Если вы используете кеш-код операции, будет ли высокая загрузка ЦП, если вы его отключите?

Если вы запустите такой инструмент, как apachebench, против простого PHP-скрипта "hello world" вместо вашего реального приложения, будет ли по-прежнему иметь место высокая загрузка ЦП?

Можете ли вы отключить модули PHP один за другим и проверить, сохраняется ли высокая загрузка ЦП после отключения каждого из них?

Можете ли вы использовать профилировщик / отладчик PHP для анализа того, что происходит в вашем приложении?