php cgi грузит процессор
Сайт тормозит и php перегружает процессор
Несколько дней назад заметил, что сайт стал очень сильно тормозить, загрузка одной страницы до 10 секунд, хотя раньше было не более двух, сайт WordPress, работает на VPS CentOS 7 (2 Гб ОЗУ, 4 CPU x 2,2 Ghz) с Nginx + PHP-FPM. Поиск медленных скриптов через slow.log ничего не дал, часто попадает в лог файл index.php (выполняется более 5 секунд). Увеличение мощности сервера на одно ядро тоже. Кэширование включено через плагин W3 Total Cache, страницы кэшируются на диск, а база данных и объекты wordpress в memcached. Посещаемость до 15к уникальных пользователей в сутки. Пытался отсеять ботов с помощью модуля nginx testcookie, отсеиваются только боты поисковых систем, но да, тогда нагрузка падает, правда это не вариант. Да и директива Crawl-daily в robots.txt есть. Если W3TC отключить, PHP вообще падает по 502, а страницы начинают загружаться не быстрее, чем за 40-50 секунд. Что со всем этим можно сделать? Ниже конфигурационные файлы и статистика:
Глобальный конфиг Nginx:
Вообще мне кажется, что проблема или в вордпрессе, или в mysql.
Я, конечно, посоветую вам сделать nginx вот так:
а для fpm что-то подобное:
Хм, спасибо. Настройки Nginx похоже помогли чуть, судя по pingdom время ожидания ответа от Nginx уменьшилось с 400 до 200 мс, но с PHP ничего не изменилось, к сожалению.
Лог есть, да только там ничего нет полезного:
Отключил плагин redirection, лог больше не пополняется так интенсивно, но ситуация не улучшилась.
И заодно конфиг fpm (который основной, а не ваш пул)
по любому процессу fpm
Там иногда SIGSEGV бывают, а так конечно /var/log/nginx *error_log*
Проверьте, какие расширения грузятся + включено ли кэширование байт-кода
php-fpm.conf
Меня смущают вот эти три строчки минимум. ХЗ что вам посоветовать. В идеале strace’ом ловить, какие файлы пытается читать fpm и решать проблему с ними, но тут с вашей нагрузкой задача та еще.
Покажи, сколько занимают каталоги с кешем Покажи, сколько записей в таблицах с кешем в базе данных Можешь отсортировать записи из mysql slow_log по времени выполнения?
мож сессии надо в мемкашу тоже засунуть. надо посмотреть на waitы при большой загрузке.
Да не может оно тормозить из-за сессий при 15к суточном трафике, большинство из которых судя по всему даже неавторизованые пользователи.
Пытался закрыть доступ к wp-admin, но сейчас вечер, нагрузка немного упала, загрузка процессора держится на уровне 70-100%, но сайт по прежнему грузится долго. Нужно будет тестировать с утра. И еще только что проверил скорость по pingdom, Wait time составил до 10 секунд, с чего бы это? https://losst.ru/wp-content/uploads/2017/07/Snimok-ekrana-ot-2017-07-10-22-18.
Я вот думаю, допустим это даже поисковики, они же не будут писать комментарии, рыть поиск и т д. Они запрашивают обычные страницы. Им должна отдаваться статика (кэширование включено), а значит никакой нагрузки на PHP быть не должно. А она есть. Есть ли какой-нибудь инструмент, чтобы посмотреть при такой нагрузке что, кто и где делает, например, анализатор логов access.log? Как понять откуда та нагрузка?
Пытался закрыть доступ к wp-admin, но сейчас вечер, нагрузка немного упала
Папка с кєшем от w3tc занимает 68 мегабайт, в memcached занято около 19 мб, если я правильно понял:
access.log анализировать можно(и нужно) с помощью стандартного набора из cat,tail,awk,sort и uniq.
С помощью конвеера из данных команд с нужными параметрами вы можете получить статистику по количеству запросов к тому или иному URL, статистику по количеству запросов для каждого или наиболее активных IP и т.п.
Но, как правило, одних логов в подобной ситуации не достаточно, что-бы понять почему именно длительное время висят запросы к скриптам сайта нужен strace одного из нагруженных обработчиков php-fpm.
Если посещаемость ресурса большая, и из-за большого колчества запросов трейс затруднён, можно на время(к примеру ночью, когда посетителей меньше) перенаправить всех посетителей не с вашего внешнего ip на статический сайт-заглушку, тогда у вас появится пару десятков минут для вдумчивого трейса проблемных скриптов. И при этом запросы от других посетителей сайта не будут вам мешать трейсить скрипты сайта. Главное не забыть потом убрать заглушку:)
И еще неплохо было бы написать, с чего все началось. Были ли тормоза изначально, или появились недавно? Какие то изменения может были?
Да, есть брут, но там не очень активно. Идет четыре попытки с одного IP, потом IP меняется, видимо попадает в бан wordpress. Интервал между сериями в несколько минут. Попробую закрыть и посмотрю что будет. Спасибо!
Раньше все работало отлично, если брать тот же pingdom, то сайт загружался за плюс минус две секунды. Ничего не менялось. Буквально три дня назад нагрузка начала расти и вот до сих пор.
Ну если ничего не менялось, то можно рассмотреть вариант с хостером: например диски начали тормозить.
Глянь iotop/iostat.
Может какой-то вордпрес плагин заглючил, попробуй повыключать и посмотреть на результаты.
Использую php5 из официальных репозиториев и без opcache.
Надо обязательно переехать на 7, но это не отменяет того вопроса, что раньше не тормозило а теперь начало 🙂 Конкретно wp чуть ли не в 2 раза быстрее работает на 7, по сравнению с 5. Ну это так, оффтоп.
Медиафайлы есть, но насколько я знаю wordpress их обрабатывает во время загрузки, а пользователям отдает уже статику.
Да это понятно. Но я не думаю, что там с каждого ip всего по одному запросу, поэтому какую-то часть он отрежет. Не настолько крупный сайт, чтобы какой-то более изощренный ботнет на несколько дней натравлять.
Не настолько крупный сайт, чтобы какой-то более изощренный ботнет на несколько дней натравлять.
Это не так работает, конкретно на какие-то сайты никто ничего не направляет: берется большой список доменов и чекается, это ж бизнес.
Но я не думаю, что там с каждого ip всего по одному запросу
Чаще всего именно так.
Запросы на wp-login все еще есть, но теперь та страница закрыта аутентификацией Nginx. Теперь они php трудностей не составляют, нагрузка на процессор от php упала. Всем спасибо. Возможно действительно только в этом было дело. Вот даже сейчас есть:
Сейчас среднее время загрузки 3-4 секунд что в принципе норма. Завтра еще планирую обновить Nginx до последней версии с полной поддержкой http2 и обновить PHP до 7.0. Плюс сессии пользователей в memcached и настрою opcode. Надеюсь после этого скорость еще вырастет. Но вообще очень странно, что запросы на одну страницу смогли так уложить сайт.
Но вообще очень странно, что запросы на одну страницу смогли так уложить сайт.
Мда, школьничек какой-то с одного ip брутит 🙂
Огромная нагрузка на веб-сервер (nginx + php-fastcgi)
Здравствуйте. Есть такая проблема: раньше стоял апач, при многократном обновлении страницы (F5 10-15 раз) CPU загружается на 100%. Я решил, что нужно сменить веб-сервер, поставил nginx + php-fpm, но, проблема осталась. Прошу подсказать, как можно решить данную проблему? Заранее спасибо!
VPS взята на digitalcloud.
Сайт находится на движке WordPress.
и посмотрите сколько коннектов выдает site.ru/stat и сколько в очереди
Active connections: 6
server accepts handled requests
7 7 19
Reading: 0 Writing: 1 Waiting: 5
Зажал F5, обновилось раз 20-30, выдает:
Active connections: 3
server accepts handled requests
196 196 271
Reading: 0 Writing: 1 Waiting: 2
Еще думаю поможет xdebug, хотя склоняюсь к мысли что проблема в медленных запросах mysql, их же можно посмотреть в mysql slow log
Также как вариант можно помониторить сайт сервисом New Relic, на графиках все поинтереснее будет.
PHP-FastCGI, скапливаются процессы
Shared-хостинг
FasctCGI процессы скапливаются, пока не займут всю свободную память, и потом все лезет в своп. Почему это происходит? Пока аккаунтов было мало, оно перед тем как память закончится, убивало все спящие процессы.
С временем выполнения связи не вижу. Накапливаются спящие процессы.
А есть что интересного в местном аналоге /var/log/kern.log, касающееся php-cgi?
Как запускаете php-cgi, чему равны значения PHP_FCGI_CHILDREN и PHP_FCGI_MAX_REQUESTS?
> Накапливаются спящие процессы.
Как запускаете php-cgi, чему равны значения PHP_FCGI_CHILDREN и PHP_FCGI_MAX_REQUESTS?
Извините за нубизм, а где их найти?
Нашел /etc/sysconfig/spawn-fcgi
Там только
> php-cgi invoked oom-killer
Ну вот и ответ. Похоже на то, что OOM Killer убивает master process php-cgi — который присматривает за дочерними процессами и перезапускает их по мере надобности.
spawn-fcgi, в свою очередь, смотрит за master process (от которого форкаются все остальные). Когда этот мастер гибнет от руки OOM Killer, spawn-fcgi его перезапускает. От него форкается еще 4 процесса. А старые процессы php остаются — их некому прибить.
PS: если возможно, отрубите Zend Optimizer.
А почему он его убивает? Где можно проверить PHP_FCGI_CHILDREN?
Очевидно потому, что php съел всю доступную память. Отсюда и Out of memory. И жестокость oom killer.
Если не боитесь, можете попробовать что-то вида (от рута):
Перед этим обязателен к прочтению man 5 proc
Где можно проверить PHP_FCGI_CHILDREN
Php cgi грузит процессор
В выдаче Яндекса появятся расширенные ответы для сервисов Profi.ru и YouDo
Три современных инструмента в помощь арбитражнику
Имеется сайт на Nginx + PHP5-FPM. При вводе команды Top в SSH появляются такие показатели:
Собственно каждому посетителю сайта отводится процесс php5-fpm. Если таких процессов более 3-4, то показатель load average: переваливает за 2.00
У меня 2-ядерная VPS, поэтому нагрузка на процессор получается всегда выше нормы, соответственно все работает медленно. Кто знает, в чем проблема? или куда хотя бы копать?
Kepus:
Собственно каждому посетителю сайта отводится процесс php5-fpm. Если таких процессов более 3-4, то показатель load average: переваливает за 2.00
У меня 2-ядерная VPS, поэтому нагрузка на процессор получается всегда выше нормы, соответственно все работает медленно. Кто знает, в чем проблема? или куда хотя бы копать?
Сайт пробовали запускать в других PHP режимах?
Нужно смотреть скрипты сайта в первую очередь и все логи в уровне debug.
Как именно смотреть эти скрипты? Так не должно быть?
Другие режимы пробовал, примерно тоже самое.
Сейчас отключил все плагины на сайты, но ситуация по-прежнему такая же.
Забавно, но на каждого посетителя сайта отводится примерно 15% двух ядер CPU. Не думаю, что так должно быть.
Я думаю мне нужно сделать перезагрузку Fast-FPM если время ожидания больше нескольких секунд например. Можно ли это реализовать?
То есть например пользователь грузит страницу более 5 секунд, затем сервер Fast-FPM сам перезагружается, пользователь на доли секунды видит 502 ошибку, а затем сразу открывается его ссылка.
если пользователь видит 502, то ему придется уже нажимать F5.
В общем не выдумывайте. Либо думайте как оптимизировать скрипты, всякие долгие конекты к базе, вычисление капчи по супералгоритму или расчет числа Пи до милиона знаков после запятой, либо хотя бы поставьте всякие акселераторы типа apc, xcache.
Оптимизация PHP-FPM: максимальная производительность и pm static
pm = ondemand – процессы плодятся по требованию (при необходимости, в отличие от динамического варианта, где pm.start_servers запускаются при запуске сервиса).
…вы можете посмотреть полный список директив php-fpm.conf для получения дополнительной информации.
Менеджер процессов (process manager) PHP-FPM-а схож с CPUFreq Governor
Governor = ondemand – Динамически увеличивает/уменьшает тактовую частоту процессора в зависимости от загруженности системы. Выводит до максимальной частоты, а потом уменьшает по мере увеличения времени простоя.
Governor = conservative – Похож на ondemand, но более экономный (предпочтение отдаётся меньшим тактовым частотам). Частота растёт более плавно.
Governor = performance – Поддерживает процессор(ы) на максимальной тактовой частоте.
… для дополнительной информации см. полный список настроек CPUFreq governor.
Заметили сходство? Я хотел сначала использовать это сравнение, чтобы более наглядно и лучше описать рекомендацию использовать pm static для PHP-FPM в качестве вашего первого выбора.
Настройка performance в CPU governor – это довольно безопасный прирост производительности, потому что это почти полностью зависит от предела процессора вашего сервера. Но есть несколько побочных эффектов (при постоянном удерживании частоты вашего процессора на 100%) – такие, как нагрев, время автономной работы (ноутбук) и другие. Однако это действительно самый быстрый параметр для вашего процессора.
Использование pm = static для максимальной производительности вашего сервера
Настройка pm = static в PHP-FPM сильно зависит от того, сколько свободной памяти на сервере. В основном, если вы страдаете от нехватки памяти сервера, то pm ondemand или dynamic могут оказаться лучшими вариантами. С другой стороны, если у вас достаточно свободной памяти, вы можете избежать большей части накладных расходов менеджера процессов, установив pm static до максимальной емкости сервера. Другими словами, когда вы делаете расчёты, pm.static нужно установить на максимальное количество PHP-FPM процессов, которые могут выполняться без создания проблем доступности памяти или кеша; однако, не так высоко, чтобы перегрузить процессор(ы) и иметь кучу отложенных операций PHP-FPM-а.
Тут отображаются не все процессы, а только та часть, что вместилась в ваше терминальное окно. В нашем случае отсортированных по %CPU (потреблению процессора). Чтобы увидеть все 100 PHP-FPM процессов, вы можете использовать что-то вроде этого:
Когда использовать pm ondemand и dynamic
Вы можете попытаться увеличить/изменить настройки и по-прежнему видеть ту же ошибку. Подобная ситуация описана в этом вопросе на Serverfault. В таком случае, pm.min была слишком низкой, а т. к. трафик сильно колеблется, режим dynamic достаточно сложно настроить правильно. Общий совет: используйте ondemand , как советуют в этом же вопросе. Однако что еще хуже, т. к. ondemand будет завершать процессы в простое вплоть до 0 когда мало трафика, то после вы получите настолько много накладных расходов, насколько скакнёт трафик. Если, конечно, вы не установите время ожидания чрезвычайно высоким. В этом случае вам просто нужно использовать pm = static + высокий pm.max_requests .
Заключение
Читайте также
Стандартные библиотеки PHP умеют генерировать только целые случайные числа. Однако, возникают задачи где нужно не целое рандомное число с максимально…
Казалось бы http_build_query — простая функция, однако, имеет некоторые особенности. Нельзя однозначно сказать что это баг, скорее просто недокументированная фича,…
Иногда при обработке с помощью PHP больших и не очень данных, можно словить досадную ошибку посреди выполнения скрипта: PHP Fatal…