Я управляю сервером, который имеет пару дюжины веб-сайтов на нем, и они все хорошо работали до прошлой недели, когда было замечено, что один сайт по-видимому потерял способность поддержать данные сессии. Затем другой. (Я предполагаю, что это влияет на все сайты на этом сервере, но просто еще не было сообщено.) Я абсолютно ничего не изменил в конфигурациях ни одного сайта недавно. Я не добавил программного обеспечения к серверу недавно. Я не изменил общий nginx или конфигурации php-fpm. Нет никаких ошибок в nginx или php-fpm журналах ошибок, которые соответствуют этому отказу. Перезапуск php-fpm, кажется, разрешает проблему по крайней мере временно. Неизбежно, проблема повторяется. Как возможно, что php-fpm может перестать работать как это, не производя сообщение об ошибке где-нибудь? Я гуглил экстенсивно и не нашел никого больше с этой проблемой.
Сервер выполняет RHEL 6 с nginx и php-fpm (remi repo). Я не могу помнить, выполняет ли этот сервер APC, но я не думаю, что это. Все патчи актуальны.
Я предполагаю, что просто поразил своего рода порог, где текущие конфигурации php-fpm недостаточны, хотя я не понимаю, почему я не получаю ошибок, когда тот предел достигнут. Вот то, что я подозреваю, соответствующие php-fpm настройки...
pm = dynamic
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 35
php_admin_value[error_log] = /var/log/php-fpm/www-error.log
php_admin_flag[log_errors] = on
Существует ли журнал ошибок где-нибудь я' пропавшие без вести, где об этом сообщили бы? Как я упомянул, нет ничего в /var/log/php-fpm/www-error.log, или в общем nginx журнале ошибок или в сайт-специфичных nginx журналах ошибок.
P.S.: Я действительно получаю другие виды сообщений об ошибках во всех журналах, которые я упомянул, таким образом, отсутствие сообщений об ошибках не является проблемой разрешения.
Вот df выводы (отредактированы для удаления определяющих физических путей)...
# df -h
Filesystem Size Used Avail Use% Mounted on
xxx
8.4G 3.8G 4.2G 48% /
xxx 7.8G 0 7.8G 0% /dev/shm
xxx 477M 79M 373M 18% /boot
xxx
976M 713M 213M 78% /home
xxx
976M 30M 896M 4% /tmp
xxx
9.8G 4.6G 4.7G 50% /var
# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
xxx
547584 87083 460501 16% /
xxx 2041821 1 2041820 1% /dev/shm
xxx 128016 50 127966 1% /boot
xxx
65536 19285 46251 30% /home
xxx
65536 173 65363 1% /tmp
xxx
655360 19441 635919 3% /var
И вот php-fpm страница состояния, в то время как сайт не позволяет сессиям быть сохраненными...
pool: www
process manager: dynamic
start time: 06/Aug/2015:10:53:06 -0400
start since: 332263
accepted conn: 2899
listen queue: 0
max listen queue: 0
listen queue len: 128
idle processes: 9
active processes: 1
total processes: 10
max active processes: 9
max children reached: 0
slow requests: 0
Как это возможно, что php-fpm может дать сбой, не создавая где-нибудь сообщения об ошибке?
Потому что тот, кто написал сбойный код, не проверил сбой и не заставил программу написать сообщение об ошибке. Программы не волшебство; они написаны людьми, которые не всегда предвидят все возможные проблемы.
Моя интуиция подсказывает, что вы где-то достигли предела дискового пространства; дисковое пространство, иноды, что угодно. Решение состоит в том, чтобы либо регулярно запускать что-то вроде tmpreaper
в вашем хранилище сеансов, чтобы свести количество старых сеансов к минимуму, либо переключиться на использование другого (автоматически истекающего) хранилища сеансов, такого как memcached.