Linux 服务器内存不足，除 ssh 之外的所有服务器都停止了，并且 swap 也未使用

Question 1

从日志输出来看，apache 正在尝试 malloc 一个非常大的分配。要弄清楚原因，您可能需要查看 apache 设置并查看什么可以做到这一点（您是否使用 mod_perl、mod_python 等）。如果您无法通过这种方式找到它，您可以在 apache 前面放置一个像 nginx 这样的代理，然后 nginx 将记录哪个请求失败。如果您愿意，您可以在同一个主机上运行 nginx，然后使用 limits 命令来限制 apache，以便在调用 oom killer 之前将其杀死（让 nginx 继续，或 urlsnarf 等）。

flush PID 是处理同步 VFS 缓存缓冲区的内核线程。很可能与 rm 有关。您可以通过查找 flush 线程及其工作的设备并验证 rm 正在处理的设备来进行验证：

# ps axwwu | grep flush
root     21658  0.0  0.0      0     0 ?        S    21:33   0:00 [flush-8:16]
# ls -l /dev/ | grep 8 | grep 16
brw-rw----  1 root disk      8,  16 2011-09-13 13:53 sdb

Answer

从日志输出来看，apache 正在尝试 malloc 一个非常大的分配。要弄清楚原因，您可能需要查看 apache 设置并查看什么可以做到这一点（您是否使用 mod_perl、mod_python 等）。如果您无法通过这种方式找到它，您可以在 apache 前面放置一个像 nginx 这样的代理，然后 nginx 将记录哪个请求失败。如果您愿意，您可以在同一个主机上运行 nginx，然后使用 limits 命令来限制 apache，以便在调用 oom killer 之前将其杀死（让 nginx 继续，或 urlsnarf 等）。

flush PID 是处理同步 VFS 缓存缓冲区的内核线程。很可能与 rm 有关。您可以通过查找 flush 线程及其工作的设备并验证 rm 正在处理的设备来进行验证：

# ps axwwu | grep flush
root     21658  0.0  0.0      0     0 ?        S    21:33   0:00 [flush-8:16]
# ls -l /dev/ | grep 8 | grep 16
brw-rw----  1 root disk      8,  16 2011-09-13 13:53 sdb

Question 2

您的系统已耗尽低内存（直接映射到内核虚拟内存空间的 RAM）。在 32 位 Linux 系统中，内核最多可使用大约 700-800 MB 的物理 RAM 来存储其内部数据（添加更多 RAM 实际上会使情况变得更糟，因为内存管理器使用的数据结构需要更多低内存）。其余 RAM 进入“高内存”区域，可供用户空间进程和页面缓存使用，但内核本身无法使用。

摘自您的日志：

DMA free:2908kB ... present:15808kB ...
Normal free:5376kB ... present:719320kB ... slab_reclaimable:664084kB slab_unreclaimable:11976kB ...
HighMem free:149216kB ... present:1336932kB ...

DMA 区域是与过时的 ISA 设备配合使用所需的低 16 MB；如今，它基本上可以忽略不计。低内存是 DMA 和正常区域的总和；只有此内存可用于保存内核数据。其余内存进入 HighMem 区域。

请注意，HighMem 区域中有大量可用内存，但系统仍然耗尽了内存，因为内核使用的某些结构需要内存，而 HighMem 不适合这样做。而 Normal 区域的大部分被 slab 缓存（slab_reclaimable和slab_unreclaimable）占用 — 这是另一个内核内存分配器，用于分配小于页面的块。不幸的是，无法从日志中找出哪些 slab 分配占用了这么多内存（可以从中读取当前 slab 缓存使用情况统计信息/proc/slabinfo；也许您需要为这些数据设置一些监控）。

真正的问题可能是内核中的一些内存泄漏错误；/proc/slabinfo如果问题再次发生，监控应该有助于找出原因。

Answer

您的系统已耗尽低内存（直接映射到内核虚拟内存空间的 RAM）。在 32 位 Linux 系统中，内核最多可使用大约 700-800 MB 的物理 RAM 来存储其内部数据（添加更多 RAM 实际上会使情况变得更糟，因为内存管理器使用的数据结构需要更多低内存）。其余 RAM 进入“高内存”区域，可供用户空间进程和页面缓存使用，但内核本身无法使用。

摘自您的日志：

DMA free:2908kB ... present:15808kB ...
Normal free:5376kB ... present:719320kB ... slab_reclaimable:664084kB slab_unreclaimable:11976kB ...
HighMem free:149216kB ... present:1336932kB ...

DMA 区域是与过时的 ISA 设备配合使用所需的低 16 MB；如今，它基本上可以忽略不计。低内存是 DMA 和正常区域的总和；只有此内存可用于保存内核数据。其余内存进入 HighMem 区域。

请注意，HighMem 区域中有大量可用内存，但系统仍然耗尽了内存，因为内核使用的某些结构需要内存，而 HighMem 不适合这样做。而 Normal 区域的大部分被 slab 缓存（slab_reclaimable和slab_unreclaimable）占用 — 这是另一个内核内存分配器，用于分配小于页面的块。不幸的是，无法从日志中找出哪些 slab 分配占用了这么多内存（可以从中读取当前 slab 缓存使用情况统计信息/proc/slabinfo；也许您需要为这些数据设置一些监控）。

真正的问题可能是内核中的一些内存泄漏错误；/proc/slabinfo如果问题再次发生，监控应该有助于找出原因。

Question 3

从我的角度来看，OOM Killer 并不总是会终止有问题的进程。但是，如果你有 apache（prefork？），最常见的情况是它会导致内存占用。

而且，由于当时是凌晨 1 点，几乎没有 Apache 连接。

我会在这里小心一点。你无法知道你有多少个连接（或者也许你可以？-抱歉）。调用像 Collectd 这样的工具，它可以非常密集地绘制图表，在这种情况下非常有用：内存、tcp 连接数（当然是在 apache 使用的端口上）以及 http 错误（尤其是服务器错误 50x）。

我有时会感到震惊，服务器上 20 秒内可以发生多少变化。

您拥有的以下值有哪些：vm.overcommit_memory vm.overcommit_ratio（这可能太低导致过早终止进程）您的平均 apache 进程内存使用量是多少？

Answer