Я управляю сервером, на котором есть пара десятков веб-сайтов, и все они работали нормально до прошлой недели, когда было замечено, что один сайт, похоже, потерял способность поддерживать данные сеанса. Потом еще один. (Я предполагаю, что это влияет на все сайты на этом сервере, но пока об этом не сообщалось.) В последнее время я абсолютно ничего не изменил в конфигурациях обоих сайтов. В последнее время я не добавлял на сервер никакого программного обеспечения. Я не менял общие конфиги 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.