☰

CentOS，内核：内存不足

tag-icon • tag-icon memory centos6 kernel memory-usage
CentOS，内核：内存不足

希望您能帮助我解决以下问题。

我们在 CentOS 6.6 版（最终版）系统上运行 CrushFTP 服务。但几乎每周该服务都会崩溃。

所以我查看了日志并发现了以下几行

cat /var/log/messages

Jun 28 05:06:23 crushftp kernel: Out of memory: Kill process 1491 (java) score 883 or sacrifice child
Jun 28 05:06:23 crushftp kernel: Killed process 1491, UID 0, (java) total-vm:9620220kB, anon-rss:3245824kB, file-rss:128kB

CrushFTP 是 Java，也是我们在机器上运行的唯一服务。日志显示系统正在终止该进程。

但我不明白为什么。所以我搜索了一下，找到了这个设置

cat /proc/sys/vm/overcommit_memory
0

当我正确理解它时，该值一定是可以的，并且如果该过程需要更多的 RAM，它应该能够获得它。

当我执行“top”时，java 进程是 RAM 使用率最高的进程。

top - 11:13:58 up 1 day, 4 min,  1 user,  load average: 0.93, 0.94, 0.91
Tasks:  97 total,   1 running,  96 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.2%us, 19.7%sy,  0.0%ni, 68.6%id,  0.0%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:   3924136k total,  2736996k used,  1187140k free,   149380k buffers
Swap:  4128764k total,        0k used,  4128764k free,   814480k cached

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
1486 root      20   0 3633m 1.5g  13m S 20.3 39.8 191:24.36 java

RAM 大约为 4GB，SWAP 文件大小相同。

[root@atcrushftp ~]# cat /proc/meminfo
MemTotal:        3924136 kB
MemFree:         1159964 kB
Buffers:          149400 kB
Cached:           814476 kB
SwapCached:            0 kB
Active:          1956028 kB
Inactive:         619664 kB
Active(anon):    1611452 kB
Inactive(anon):      528 kB
Active(file):     344576 kB
Inactive(file):   619136 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:       4128764 kB
SwapFree:        4128764 kB
Dirty:                36 kB
Writeback:             4 kB
AnonPages:       1597696 kB
Mapped:            34108 kB
Shmem:               164 kB
Slab:             136024 kB
SReclaimable:      74432 kB
SUnreclaim:        61592 kB
KernelStack:        1384 kB
PageTables:         5948 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     6090832 kB
Committed_AS:     746432 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      285216 kB
VmallocChunk:   34359441520 kB
HardwareCorrupted:     0 kB
AnonHugePages:   1501184 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       18432 kB
DirectMap2M:     4175872 kB

我询问了支持人员，但他们说这不是 CrushFTP 的故障，而是系统内存不足。

现在我的问题是如何找出哪个进程占用了所有最后的可用内存？

答案1

我已经很久没有读过 OOM-killer 日志了，不过我记得，这个

Jun 28 05:06:23 crushftp kernel: Killed process 1491, UID 0, (java) total-vm:9620220kB, anon-rss:3245824kB, file-rss:128kB

意味着当 OOM-killer 击倒 Java 时，它正在使用 9GB 的 VM。考虑到你有 4GB 的核心和 4GB 的交换空间，这似乎是合理的。然后你写

当我正确理解它时，该值一定是可以的，并且如果该过程需要更多的 RAM，它应该能够获得它。

我不明白。

首先，将该值设置为0不会关闭过度承诺。 正如 Red Hat 所写，将其设置为0需要

内核通过估计可用内存量并拒绝明显无效的请求来执行启发式内存过量使用处理。遗憾的是，由于内存是使用启发式算法而非精确算法分配的，因此此设置有时会导致系统上的可用内存过载。

将其设置为2您想要的操作：

内核拒绝的内存请求等于或大于总可用交换和 overcommit_ratio 中指定的物理 RAM 百分比之和。如果您希望降低内存过量使用的风险，此设置是最佳选择。

但即使关闭过度使用也不能保证进程总能获得更多的 RAM：只有无限 VM 才能保证这一点。只要核心 + 交换是有限的，它就会被用完 - 如果你有一个进程在内核需要更多 VM 时消耗了所有可用的 VM，那么 OOM-killer 就会被唤醒，嗯，看起来就是这样的。

我的建议是：

  1. 不要java以 root 身份运行。理想情况下，根本不要运行它，但如果必须运行，也不要以 root 身份运行；这会让它在 OOM 杀手眼中占有重要地位，从而导致一些重要的东西被杀死。

  2. 查找使用 Java 的任何内容中的内存泄漏。

  3. 如果你真的相信你没有内存泄漏，那么你的核心就不够；花点钱买一个更大的服务器。同时给它更多的交换空间。

  4. 更好地监控你的 java 的 VM 占用空间；如果它变得肿胀，就把它射向头部。

相关内容