У меня есть многопользовательский сайт WordPress, на котором все мои процессоры загружены более чем на 90%:
top - 12:02:58 up 55 days, 5:25, 10 users, load average: 20.51, 15.66, 14.90
Tasks: 294 total, 24 running, 270 sleeping, 0 stopped, 0 zombie
Cpu0 : 87.5%us, 8.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 4.5%si, 0.0%st
Cpu1 : 97.9%us, 1.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu2 : 96.0%us, 3.5%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st
Cpu3 : 97.6%us, 2.1%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu4 : 97.1%us, 2.7%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu5 : 97.9%us, 1.9%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Cpu6 : 97.9%us, 1.6%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st
Cpu7 : 96.0%us, 3.5%sy, 0.0%ni, 0.3%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st
Mem: 14369424k total, 11903548k used, 2465876k free, 402360k buffers
Swap: 4063200k total, 3594784k used, 468416k free, 1484116k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
30658 apache 16 0 274m 97m 6304 R 62.1 0.7 0:12.49 php-cgi
30686 apache 16 0 213m 92m 6040 R 52.2 0.7 0:03.27 php-cgi
30685 apache 15 0 211m 87m 5764 S 50.3 0.6 0:04.50 php-cgi
28217 apache 16 0 529m 405m 6748 S 49.0 2.9 3:54.72 php-cgi
30468 apache 16 0 414m 291m 6452 R 48.5 2.1 0:49.78 php-cgi
29604 apache 15 0 258m 135m 6464 S 47.4 1.0 2:16.22 php-cgi
28308 apache 16 0 584m 408m 6724 R 43.9 2.9 3:43.07 php-cgi
28266 apache 16 0 550m 374m 6728 R 43.7 2.7 3:58.38 php-cgi
29573 apache 16 0 584m 407m 6592 R 36.8 2.9 1:59.88 php-cgi
30470 apache 16 0 219m 95m 6452 S 36.5 0.7 0:39.66 php-cgi
29138 apache 15 0 513m 334m 6528 S 33.6 2.4 2:03.14 php-cgi
30472 apache 17 0 441m 318m 6272 R 31.7 2.3 0:50.45 php-cgi
28283 apache 16 0 414m 291m 6580 R 29.3 2.1 3:53.06 php-cgi
29858 apache 16 0 251m 127m 6628 R 24.8 0.9 1:15.53 php-cgi
28253 apache 18 0 550m 374m 6580 R 24.5 2.7 4:08.05 php-cgi
30666 apache 15 0 217m 94m 5996 R 24.5 0.7 0:04.68 php-cgi
28208 apache 20 0 584m 407m 6436 R 24.2 2.9 4:36.36 php-cgi
29085 apache 25 0 358m 182m 6488 R 22.6 1.3 2:19.76 php-cgi
28258 apache 25 0 530m 407m 6512 R 22.4 2.9 3:58.70 php-cgi
29574 apache 16 0 530m 406m 6540 S 21.6 2.9 2:19.26 php-cgi
28947 apache 16 0 524m 401m 6476 R 14.1 2.9 2:32.33 php-cgi
28238 apache 15 0 488m 312m 6852 S 12.3 2.2 4:24.34 php-cgi
30464 apache 15 0 274m 151m 6176 R 11.2 1.1 0:19.67 php-cgi
28293 apache 16 0 269m 146m 6460 R 9.9 1.0 3:57.17 php-cgi
28205 apache 25 0 530m 407m 6496 R 9.6 2.9 4:05.49 php-cgi
30471 apache 19 0 263m 140m 6440 R 6.9 1.0 0:47.42 php-cgi
Выходные данные показывают, что максимальная загрузка ЦП отдельным процессом составляет ~ 60%, но были времена, когда у меня было целых 7 процессов, использующих более 90% ЦП.
Сайт работает следующим образом:
nginx работает как обратный прокси, обслуживая каждый статический файл, который он может, и кэширует страницы с помощью директивы proxy_cache.
Он делегирует Apache, когда требуются скрипты PHP. Они запускаются через mod_cgi с использованием опции ExecCGI
И Apache, и nginx сжимают каждый файл, читаемый человеком.
Чтобы избежать постоянного попадания в MySQL, мы сохраняем фрагменты HTML в memcached, который в настоящее время кэширует от 2 до 4 МБ, как сообщает команда stats в соединении telnet.
В базе данных Redis также хранятся счетчики, в основном для подсчета просмотров страниц для каждого сообщения.
Ни WP Super Cache (кеширование выполняет nginx), ни XCache.
Я не понимаю, как определить, что именно делает каждый процесс php-cgi для такой высокой нагрузки на ЦП - сайт был сильно изменен несколькими разными командами разработчиков программного обеспечения, прежде чем мы начали его обслуживать.
Журнал ошибок PHP показывает в основном следующие ошибки:
Ни один из них на самом деле не выполняет никаких вычислений, поэтому они не могут быть источником проблемы с процессором.
Я пробовал отслеживать системные вызовы и видел lstat, чтение, запись и доступ, которые генерировали бы ожидание, а не загрузку процессора, если бы они были проблемой (правильно?). Кроме того, были призывы как опросить, так и выбрать.
Может ли кто-нибудь подсказать, что проверить дальше?
Судя по другим ошибкам, которые вы видите, было бы очень удивительно, если бы не были скрывается какой-то плохо продуманный код - обзор кода был бы лучшим способом приблизиться к устранению неполадок.
Cannot redeclare class FacebookRestClientException
Мы знаем, что этот класс был загружен успешно, поэтому я бы начал с выяснения, какие внешние API вызывают скрипты, не работают они или нет, и как долго они связывают вещи во время работы (или не запускаются) - плохо продуманный вызов ( или серия вызовов) к внешнему API.
Ваша проблема здесь:
Ни WP Super Cache (кеширование выполняет nginx), ни XCache.
Установить APC Zend OPcache и W3 Total Cache и наблюдайте, как загрузка вашего процессора почти полностью падает.
APC Один только Zend OPcache должен дать вам некоторую передышку.
Обратите внимание, что W3 Total Cache не полностью поддерживает работу с несколькими сайтами, поэтому его необходимо настраивать для каждого сайта отдельно. Его можно настроить для использования существующего memcached для кеширования.
Вы также можете избавиться от Apache. Это абсолютно ничего не делает для вас.
(Примечание: APC устарел и на практике оказался ненадежным. В настоящее время я рекомендую вместо него использовать Zend OPcache.)
Кэширование памяти определенно поможет, особенно для внутреннего кеша объектов WordPress. Как говорит Майкл, W3 Total Cache не полностью поддерживает работу с несколькими сайтами и является довольно всеобъемлющим / сложным / тяжелым, поэтому я бы порекомендовал более чистую и простую альтернативу, которая очень похожа на настройку на wordpress.com: Кэш объектов APC (что быстрее, чем memcached для отдельных серверов) для кеша объектов и Batcache для кэширования полностраничной памяти. Обратите внимание на инструкции по установке для каждого, они отличаются от стандартных плагинов.
Очевидно, вам необходимо установить APC для PHP, если у вас его еще нет, и настроить его соответствующим образом. Например, stat = 0 значительно ускорит процесс, но если вы установите это, вам нужно будет перезапустить процессы PHP при изменении любых файлов PHP (например, при обновлении плагинов и ядра WordPress). Убедитесь, что вы установили панель apc.php (возможно, вам придется получить ее из архива исходных кодов APC в зависимости от пакетов вашей ОС), она очень полезна для настройки и отладки. (Заблокируйте его / защитите паролем, помните.)
В качестве альтернативы, поскольку у вас уже установлен memcached, есть Memcached Redux плагин, который выполняет ту же функцию, что и APC Object Cache. Это может быть более простой путь.
Возможно, вы не получите огромной выгоды от Batcache, поскольку вы уже используете nginx для файлового proxy_cache, но это, безусловно, не повредит, если у вас есть свободная память, и может помочь, преодолев разрыв между файловым кешем и напрямую поражает Apache, так что попробовать стоит.
Глядя на вашу точку зрения 3. Я настоятельно рекомендую отключить gzipping как в Apache, так и в PHP, т.е. отключить mod_deflate и изменить zlib.output_compression = Off в php.ini. Nginx - это ваш интерфейс, поэтому сжатие в любом случае будет выполняться за вас, поэтому нет необходимости делать это дважды - nginx, вероятно, сделает это быстрее / эффективнее и сэкономит процессор ваших процессов Apache / PHP.
Сколько плагинов активировано? Все ли они необходимы? Можете ли вы отключить их один за другим и посмотреть, какая разница? Я видел некоторые плагины с ужасно закодированным кодом, у которых были сильно испорченные сайты, так что проверьте их, если можете.
Вы упомянули, что сайт был сильно изменен несколькими разными командами разработчиков программного обеспечения. Есть ли какой-либо контроль версий, чтобы вы могли видеть, какие изменения были внесены? Они напрямую связаны с ядром, темой или плагинами? Если они дошли до сути, можете ли вы различать вещи, чтобы получить лучшее изображение, или это слишком сильно модифицировано? Двигаясь вперед, рефакторинг изменений от ядра к теме сайта functions.php и дискретных плагинах может значительно облегчить вашу жизнь, если вы сможете это сделать.