php-fpm 调用 oom-killer

php-fpm 调用 oom-killer

我发现一个问题,PHP-FPM 运行了几天,然后决定填满所有内存 + 交换并调用 OOM-Killer。发生这种情况后,服务器完全死机,你甚至无法再通过 SSH 进入。必须进行硬重启才能恢复正常。

我想知道为什么会发生这种情况,以及是否有修复或解决方法,例如限制它可以使用的内存量或者在开始使用过多内存时重新启动该进程。

我捕获了最近几次发生这种情况时的内核转储。

  1. http://pastebin.com/raw.php?i=rX6jYDe0
  2. http://pastebin.com/raw.php?i=f2qx5GcS

我的 php-fpm.conf

  1. http://pastebin.com/raw.php?i=27hvN27q

我的www.conf:

  1. http://pastebin.com/raw.php?i=VgYtut9j

如果我可以为您提供有关为什么会发生这种情况的更多信息,请告诉我。

答案1

关于 OOM 有很多很棒的信息。如果你想了解发生了什么,我建议用更多这样的关键词来搜索

我曾经在客户项目中遇到过这种情况,必须处理这个问题。不幸的是,上述建议都没有帮助,因为这与内核有关。OOM 是一种肮脏的解决 Linux 中内存过度使用的问题。

对我有帮助的是设置一些可以完全避免 OOM 的内核参数。要快速修复它,请添加以下几行以/etc/sysctl.conf使更改在启动时持久:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

不过我建议你阅读一下 OOM。你可能会发现一些关于它的有用信息。

答案2

尝试将 pm.max_requests 减少到较低的值(1000)。此外,您有较高的 pm.start_servers、pm.start_servers、pm.max_spare_servers 值和极高的 pm.max_children

答案3

您可能需要查明所有内存分配是否是由一个不寻常的请求引起的(在这种情况下,您必须修复代码)或者这是渐进式内存泄漏的结果。在后一种情况下,您可以减少max_requests参数以更频繁地重新启动 PHP-FPM 子进程。

如果您无法修复代码中的问题,则可能需要使用一些卑鄙的黑客手段。例如,编写一个脚本来监控 PHP 内存消耗并重新启动它。

还有一种方法可以限制给定进程的内存消耗(如上所述这里),但我没有机会测试它。

答案4

检查是否有东西在继续创建 php 文件(例如 twig/smarty 缓存)。您可以计算目录中的文件数量,然后忽略 var/cache 目录。

相关内容