У нас есть довольно сильно загруженный сервер с nginx и PHP-FPM. У нас есть 6 веб-сайтов на этом сервере, на которых работают PHP-FPM и nginx. Программное обеспечение - это vBulletin 3.8 и WordPress. Базы данных находятся на отдельном сервере.
Теперь, поскольку это очень популярные веб-сайты, у нас обычно одновременно находятся 7-8000 посетителей онлайн, причем каждая страница большей частью попадает в базу данных. Я считаю, что это причина наших проблем.
Поскольку у нас так много больших баз данных на сервере MySQL, и поскольку запросы могут, честно говоря, быть намного лучше в программном обеспечении, я думаю, что MySQL иногда не может своевременно возвращать результаты в PHP, создавая каскадный эффект, который в конечном итоге заставляет все просто остановиться, пока мы не перезагрузим PHP-FPM. После этого все снова начинает работать нормально.
Причина, по которой у меня возникают проблемы с устранением неполадок, заключается в том, что я ничего не могу различить из журналов. В журнале медленных запросов MySQL я не вижу ничего интересного в случае простоя. В журналах nginx я вижу тысячи записей, в которых говорится, что истекло время ожидания запроса на чтение или истекло время ожидания соединения (для PHP-FPM). И в журналах PHP-FPM я вижу много строк, в которых говорится: «Время выполнения истекло (31 сек), завершение
Так что на данный момент я просто не знаю, где искать проблему. Очевидно, что все, что происходит, происходит, потому что эти сценарии иногда не выполняются достаточно быстро (обычно они загружаются менее чем за секунду, но что-то происходит, что приводит к резкому увеличению времени загрузки). Это происходит много раз в день, и это стало для нас серьезной проблемой.
На данный момент у меня просто есть crontab для обслуживания перезагрузки php5-fpm каждые 10 минут, что решает проблему сбоя. Конечно, когда PHP перезагружается, nginx выдает ошибку шлюза 502, так что это не лучшее решение.
PHP использует кеш APC, если это важно. Я читал в нескольких местах, что APC может вызывать зависание при определенных обстоятельствах.
Любые указатели были бы полезны. Мне бы очень хотелось, чтобы мне не приходилось постоянно беспокоиться об этой машине.
Конечно, может быть предоставлена дополнительная информация. Просто дайте мне знать, что вам нужно.
Обновить: Я просто скопировал apc.php в корневой каталог и получил доступ к нашей статистике. Все выглядело хорошо. Затем я щелкнул ссылку, чтобы перейти к статистике пользователей, и БУМ сервер мгновенно завис. Я перезагрузил php-fpm, а затем перезагрузил страницу пользовательской статистики, и все прошло нормально. Подождал минуту, снова перезагрузился, сервер снова завис.
Так что это определенно похоже на APC. Вопрос в том, как это исправить?
Конфигурация APC:
[apc]
apc.enabled="1"
apc.stat = "1"
apc.max_file_size = "2M"
apc.localcache = "1"
apc.localcache.size = "256"
apc.shm_segments = "1"
apc.ttl = "3600"
apc.user_ttl = "7200"
apc.gc_ttl = "3600"
apc.cache_by_default = "1"
apc.filters = ""
apc.write_lock = "1"
apc.num_files_hint= "10000"
apc.user_entries_hint="10000"
apc.shm_size = "1G"
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.include_once_override = "0"
apc.file_update_protection="2"
apc.canonicalize = "1"
apc.report_autofilter="0"
apc.stat_ctime="0"
Обновление 2: Здесь мы добились определенного прогресса. Оказывается, именно плагин кеширования WordPress (W3 Total Cache) вызывал сбои. Мы до сих пор не знаем почему, но с его отключением мы запускаем PHP уже почти 4 часа без перезагрузок, без замедлений и сбоев. Мы все еще используем APC на форумах vBulletin, и никаких проблем там нет. Есть ли способ определить ЗАЧЕМ АПК рушится? Я хотел бы использовать его в наших установках WordPress, но не за счет хрупкости системы.
Вы используете php-fpm, поэтому я предлагаю более агрессивно подходить к вопросу о том, сколько времени детям php-fpm разрешено жить. Вам нужно найти золотую середину между недолговечными потоками / дочерними элементами и стабильностью. Значения по умолчанию php-fpm слишком щедры для любой производственной системы, ИМХО.
Я бы уменьшил количество для pm.max_requests для ваших производственных бассейнов. Я думаю, что по умолчанию 200. Я бы начал с 50 и посмотрел, к чему это приведет.
В случае неудачи / дополнения к этому вы также можете попробовать эти глобальные параметры (AFAIK все они отключены по умолчанию):
emergency_restart_threshold=3
emergency_restart_interval=1m
process_control_timeout=5s
Что это значит? Если 3 дочерних процесса PHP-FPM завершаются с SIGSEGV или SIGBUS (т.е. сбой) в течение 1 минуты, предполагается, что PHP-FPM перезапустится автоматически. Дочерние процессы ждут 5 секунд реакции на сигналы от мастера.
Это должно держать ваш пул рабочих потоков PHP красивым, свежим и чистым. Чем дольше работнику разрешено отправлять запросы, тем более нестабильным он становится. Также повышается риск утечки памяти.
Вот хороший обзор всех параметров конфигурации, которые я упомянул здесь, а также других: http://myjeeva.com/php-fpm-configuration-101.html
Надеюсь, эти советы вам помогут! Не забудьте настроить и наблюдать, к сожалению, для всего этого не существует практического правила, слишком много переменных, которые влияют на поведение и стабильность PHP.