![为什么运行 nginx/php-fpm 的服务器不断丢失会话功能而没有产生任何错误?](https://linux22.com/image/664107/%E4%B8%BA%E4%BB%80%E4%B9%88%E8%BF%90%E8%A1%8C%20nginx%2Fphp-fpm%20%E7%9A%84%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8D%E6%96%AD%E4%B8%A2%E5%A4%B1%E4%BC%9A%E8%AF%9D%E5%8A%9F%E8%83%BD%E8%80%8C%E6%B2%A1%E6%9C%89%E4%BA%A7%E7%94%9F%E4%BB%BB%E4%BD%95%E9%94%99%E8%AF%AF%EF%BC%9F.png)
我正在管理一台有几十个网站的服务器,它们一直运行良好,直到上周我注意到一个网站似乎失去了维护会话数据的能力。然后另一个也一样。 (我猜这会影响这台服务器上的所有网站,只是还没有报告。)我最近没有更改任何一个网站的配置。我最近没有在服务器中添加任何软件。我没有更改常规 nginx 或 php-fpm 配置。nginx 或 php-fpm 错误日志中没有与此故障相对应的错误。重新启动 php-fpm 似乎可以至少暂时解决问题。不可避免地,问题会再次出现。php-fpm 怎么可能像这样失败而不在某处产生错误消息?我已经在 Google 上进行了广泛搜索,没有发现其他遇到此问题的人。
该服务器运行的是带有 nginx 和 php-fpm (remi repo) 的 RHEL 6。我不记得这台服务器是否运行的是 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 错误日志中都没有任何内容。
PS:我在提到的所有日志中都收到了其他类型的错误消息,因此缺少错误消息不是权限问题。
以下是 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
答案1
php-fpm 怎么可能出现这样的失败,而没有在某处产生错误消息?
因为编写失败代码的人没有检查失败并导致程序写入错误消息。程序不是魔法;它们是由人编写的,人并不总是能预料到所有可能的问题。
我的直觉是,您在某个地方达到了磁盘存储限制;磁盘空间、inode 等等。解决方案是tmpreaper
定期对会话存储进行类似操作,以将旧会话数量保持在最低限度,或者切换到使用其他(自动过期)会话存储,例如 memcached。