自几天以来，我们的网络服务器每小时都会出现一些高负载峰值。
该网络服务器是一台配备 32GB RAM 和 4 核的专用服务器。它运行基于 drupal 的大型网络应用程序，其中包含大量存储数据和 rest api。
有时，PHP-FPM 进程似乎会无缘无故地停止响应（没有运行特定任务或特定的高流量）
这是我的池配置（我最近增加了 max_children 的数量，看看是否能解决问题）
pm = dynamic
pm.max_children = 80
pm.start_servers = 25
pm.min_spare_servers = 10
pm.max_spare_servers = 40
pm.max_requests = 200
request_terminate_timeout = 50s
以下是一些 new-relic 的屏幕截图，显示了问题发生时发生的情况。
您可以看到生成的子项数量在约 10 分钟内急剧上升，然后又恢复正常。
对于导致这些异常峰值的原因，您有什么想法吗？
[编辑1]
更具体地说，系统规格是，服务器还运行 NGINX、MYSQL、MEMCACHED 和 POSTFIX。16GB 内存分配给 mysql 数据库。CPU 是 Intel(R) Xeon(R) CPU E3-1225 V2 @ 3.20GHz
为了更好地了解问题发生时的服务器使用情况，您可以查看 newrelic 概览的屏幕截图
[编辑2]
这是梭子鱼中间的顶部的样子
top - 13:28:53 up 124 days, 2:15, 1 user, load average: 64.25, 25.29, 12.02
Tasks: 177 total, 77 running, 100 sleeping, 0 stopped, 0 zombie
%Cpu(s): 99.9 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 32917328 total, 32257288 used, 660040 free, 236848 buffers
KiB Swap: 1046520 total, 90328 used, 956192 free, 8352948 cached
几分钟后
top - 13:35:09 up 124 days, 2:21, 1 user, load average: 5.43, 20.97, 16.33
Tasks: 149 total, 3 running, 146 sleeping, 0 stopped, 0 zombie
%Cpu(s): 47.2 us, 1.7 sy, 0.0 ni, 43.8 id, 6.4 wa, 0.0 hi, 0.8 si, 0.0 st
KiB Mem: 32917328 total, 30507792 used, 2409536 free, 236852 buffers
KiB Swap: 1046520 total, 90328 used, 956192 free, 8308028 cached
还检查了 NGINX 日志，查看当时请求是否突然增加，以下是该命令的结果：
grep “ 15 / Sep / 2015：13” access.log | cut -d [ -f2 | cut -d] -f1 | awk -F：'{print $ 2“：”$ 3}'| sort -nk1 -nk2 | uniq -c | awk'{if ($1> 10) print $ 0}'
467 13:00
463 13:01
497 13:02
421 13:03
473 13:04
471 13:05
480 13:06
390 13:07
430 13:08
430 13:09
405 13:10
449 13:11
415 13:12
451 13:13
424 13:14
476 13:15
483 13:16
398 13:17
433 13:18
474 13:19
458 13:20
434 13:21
403 13:22
408 13:23
487 13:24
440 13:25
526 13:26
70 13:27
104 13:28
373 13:29
943 13:30
706 13:31
446 13:32
447 13:33
461 13:34
427 13:35
303 13:36
答案1
我曾经是一家广告服务公司的系统管理员，该公司在其广告服务器上使用 php-fpm。我们曾将其max_requests设置为 20,000 左右，非常高。在我开始之前，他们遇到了一个问题，负载/内存/CPU 会像您看到的那样激增，然后在一天中以循环方式回落。这是由于几乎所有 php-fpm 进程都重新启动，因为它max_requests几乎同时达到极限。
您可能遇到了同样的问题。我们通过在每台机器上运行 4-5 个 php-fpm 主进程并错开启动时间解决了这个问题。
最后，我们设置了几个实例，0看看max_requests是否需要启动它。结果发现应用程序没有任何严重的内存泄漏，每个 php-fpm 进程使用的内存增长非常缓慢。它也更加随机，我们最终使用monit观察每个 php-fpm 主进程的内存来观察内存使用情况，如果超过某个限制，则monit重新启动 php-fpm