希望你能帮助我解决以下问题。
我们正在CentOS 6.6（Final）系统上运行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和我们在机器上运行的唯一服务。 日志看起来像系统正在杀死进程。
但我不明白为什么。 所以我search了一下发现这个设置
cat /proc/sys/vm/overcommit_memory 0
当我了解它是正确的，价值一定是好的，如果进程需要更多的内存，它应该能够得到它。
当我做一个“顶”时，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故障，系统内存不足。
现在我的问题是怎样才能找出哪个进程正在使用所有最后的空闲内存？
我已经读了一个OOM杀手日志已经有一段时间了，但是正如我记得的那样
Jun 28 05:06:23 crushftp kernel: Killed process 1491, UID 0, (java) total-vm:9620220kB, anon-rss:3245824kB, file-rss:128kB
意味着当OOM杀手头部开枪时，java正在使用9GB的虚拟机。 鉴于你有4GB的内核和4GB的交换空间，这似乎是一个合理的事情。 你然后写
当我了解它是正确的，价值一定是好的，如果进程需要更多的内存，它应该能够得到它。
我不明白。
首先，将该值设置为0不会closures超载。 正如红帽写的 ，将其设置为0要求
内核执行启发式内存过度承诺处理通过估计可用内存量和失败的请求是公然无效。 不幸的是，由于内存是使用启发式而非精确algorithm分配的，因此此设置有时会使系统上的可用内存过载。
把它设置为2 ，你似乎想要什么：
内核拒绝内存请求的数量等于或大于总可用交换和overcommit_ratio中指定的物理RAM的百分比。 如果您想要较小的内存过量使用风险，此设置是最好的。
但即使closuresovercommit也不能保证进程总是可以获得更多的RAM：只有无限的VM保证。 只要核心+交换是有限的，就可以用完了 – 如果你有一个进程在内核需要多一点的时候使用所有的空闲虚拟机，那么OOM杀手会醒来，看起来像是发生了什么事
我的build议是：
不要以root身份运行java 。 理想情况下，根本不要运行它，但是如果你必须的话，而不是根源; 这给了它在OOM杀手眼中的权重，可能会导致重要的东西被杀害。
find内存泄漏在任何使用Java。
如果你真的相信你没有内存泄漏，那么你没有足够的核心; 小马了一个更大的服务器。 给它更多的交换，以及。
更好地监控你的Java虚拟机占用空间; 如果全部肿起来，就把它射在头上。