背景
刚入职时，就发现我们的某一台服务器内存非常高，而且在不断的增长， 另一台服务器很正常
故障原因
经过排查发现 php-fpm 设置项为：pm=static，未开启pm.max_requests配置；导致php进程长期存活，由于存在内存泄漏问题，垃圾内存无法释放，内存消耗持续升高！
另一台正常的机器配置为：
pm=static
pm.max_requests=5000
参考阅读：php-fpm 三种运行方式：static，dynamic，ondemand
解决方案
修改php-fpm设置项：pm = dynamic
设置：
pm.max_children = 500
pm.start.servers = 100
pm.min_spare_servers = 20
pm.max_spare_servers = 100
pm.max_requests=2000
另外新增配置：
pm.status_path=pmstatus
并且新增nginx配置
location = /pmstatus {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
}
访问：http://192.144.176.65/pmstatus 可以查看phpfpm状态
pool: www
process manager: dynamic
start time: 15/Jul/2020:11:15:09 +0800
start since: 13937213
accepted conn: 77203116
listen queue: 0
max listen queue: 129
listen queue len: 128
idle processes: 99
active processes: 1
total processes: 100
max active processes: 500
max children reached: 3
slow requests: 0
参数说明：
pool – fpm池子名称，大多数为www
process manager – 进程管理方式,值：static, dynamic or ondemand. dynamic
start time – 启动日期,如果reload了php-fpm，时间会更新
start since – 运行时长
accepted conn – 当前池子接受的请求数
listen queue – 请求等待队列，如果这个值不为0，那么要增加FPM的进程数量
max listen queue – 请求等待队列最高的数量
listen queue len – socket等待队列长度
idle processes – 空闲进程数量
active processes – 活跃进程数量
total processes – 总进程数量
max active processes – 最大的活跃进程数量（FPM启动开始算）
max children reached - 进程最大数量限制的次数，如果这个数量不为0，那说明你的最大进程数量太小了，请改大一点。
slow requests – 启用了php-fpm slow-log，缓慢请求的数量
经过系统升级以及参数调整后，机器内存使用显著降低，经过一段时间运行后，内存又升起来了，高达8.5G， 开始怀疑人生了
free -g 统计实际并不大
经过ops同事排查，是exporter版本的问题导致了监控图表不准确，已经修复， 实际内存使用情况如下，符合预期
机器内存变化如图所示，说明我们的调整是正确的， 实际效果符合预期
结语
两台服务器的pm配置，一个使用static策略， 一个使用dynamic；经过对比发现使用dynamic实际内存消耗要小一些，cpu变化也不大，但是cache占用要多一些