apache报错 kernel: httpd invoked oom-killer

您是否已在系统日志(/var/log/messages)中注意到这种行为？

kernel: httpd invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
kernel: Call Trace:
kernel: [<ffffffff800cb67d>] out_of_memory+0x8e/0x2f3
kernel: [<ffffffff8002e493>] __wake_up+0x38/0x4f
kernel: [<ffffffff8000a7ea>] get_page_from_freelist+0x2/0x442
kernel: [<ffffffff8000f6a2>] __alloc_pages+0x27f/0x308
kernel: [<ffffffff8001308d>] __do_page_cache_readahead+0x96/0x17b
kernel: [<ffffffff800139d6>] filemap_nopage+0x14c/0x360
kernel: [<ffffffff80008972>] __handle_mm_fault+0x1fd/0x103b
kernel: [<ffffffff8000c795>] _atomic_dec_and_lock+0x39/0x57
kernel: [<ffffffff800671ae>] do_page_fault+0x499/0x842
kernel: [<ffffffff8005ddf9>] error_exit+0x0/0x84

此外，当时系统挂起/非常慢，内存用尽，交换被吃掉了……

好吧，由于某种原因(错误或者流量突然增加)，所有可用内存已分配给一个或者多个系统进程(以上内容可以在多个系统进程中注意到，任何可能请求访问内存的人)。
在当前情况下，罪魁祸首是Apache，这种行为在Apache，MySQL，cron等等中可见。

我建议调查以下内容：

• 使用“sar”跟踪当时的load/ressource使用行为
• 导致oom killer/out of \u memory事件的第一个进程上的用法
• 当时的系统繁忙程度
• 可能已触发事件的计划cron作业

如果以上方法均不能解释峰值使用率，则可能是您遇到了软件或者内核错误。
尝试更新所涉及的软件，内核可以解决此问题。

现在，为什么发生"内存不足"情况，我们如何防止这种情况发生？

请记住，默认情况下，内核将分配内存，而不管当前的使用情况或者系统上的内存总量。

您可以通过应用以下内核参数(/etc/sysctl.conf)来改善这种行为：

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

注意：必须重新启动才能应用sysctl.conf参数。
例如，您可以发出" sysctl -w vm.overcommit_memory = 2"命令立即应用设置，但不要忘记添加到sysctl.conf中，因为这些命令将无法重启。

这是" overcommit_memory"参数的可能值和说明：

0:启发式过度限制（这是默认值）
1:总是超负荷，从不检查
2:经常检查，不要过度

另外，在涉及Apache的此特定问题上，您可以在" httpd.conf"中限制每个进程的内存：

RLimitMEM <value_in_bytes>

例如，您希望将进程大小限制为128 MB，参数和值将为：

RLimitMEM 134217728