防止Linux内核用非常大的堆杀死Java进程

运行32核244GB的Ubuntu 12.04.3 LTS。它是AmazonEC2内存实例的大实例和Java1.7u25

我的java进程正在使用-Xmx226g运行

我正在尝试使用CQEngine创建一个非常大的本地缓存，到目前为止，它的速度非常快，有30000000条记录。当然，我将添加一个逐出策略，允许垃圾收集清理被逐出的旧对象，但我确实试图在这里突破限制：）

在查看jvisualvm时，总堆大约为180GB，很快就会消失40GB。我应该可以再挤出一点

并不是说我不希望内核在进程耗尽资源时终止进程，而是我认为它会提前终止进程，并希望尽可能地压缩mem的使用

ulimit输出如下所示

ubuntu@ip-10-156-243-111:/var/log$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 1967992
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1967992
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

kern.log输出为

340 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
63999984 pages RAM
1022168 pages reserved
649 pages shared
62830686 pages non-shared
[ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
[  505]     0   505     4342       93   9       0             0 upstart-udev-br
[  507]     0   507     5456      198   2     -17         -1000 udevd
[  642]     0   642     5402      155  28     -17         -1000 udevd
[  643]     0   643     5402      155  29     -17         -1000 udevd
[  739]     0   739     3798       49  10       0             0 upstart-socket-
[  775]     0   775     1817      124  25       0             0 dhclient3
[  897]     0   897    12509      152  10     -17         -1000 sshd
[  949]   101   949    63430       91   9       0             0 rsyslogd
[  990]   102   990     5985       90   8       0             0 dbus-daemon
[ 1017]     0  1017     3627       40   9       0             0 getty
[ 1024]     0  1024     3627       41  10       0             0 getty
[ 1029]     0  1029     3627       43   6       0             0 getty
[ 1030]     0  1030     3627       41   3       0             0 getty
[ 1032]     0  1032     3627       41   1       0             0 getty
[ 1035]     0  1035     1083       34   1       0             0 acpid
[ 1036]     0  1036     4779       49   5       0             0 cron
[ 1037]     0  1037     4228       40   8       0             0 atd
[ 1045]     0  1045     3996       57   3       0             0 irqbalance
[ 1084]     0  1084     3627       43   2       0             0 getty
[ 1085]     0  1085     3189       39  11       0             0 getty
[ 1087]   103  1087    46916      300   0       0             0 whoopsie
[ 1159]     0  1159    20490      215   0       0             0 sshd
[ 1162]     0  1162  1063575      263  15       0             0 console-kit-dae
[ 1229]     0  1229    46648      153   4       0             0 polkitd
[ 1318]  1000  1318    20490      211  10       0             0 sshd
[ 1319]  1000  1319     6240     1448   1       0             0 bash
[ 1816]  1000  1816 70102543 62010032   4       0             0 java
[ 1947]     0  1947    20490      214   6       0             0 sshd
[ 2035]  1000  2035    20490      210   0       0             0 sshd
[ 2036]  1000  2036     6238     1444  13       0             0 bash
[ 2179]  1000  2179    13262      463   2       0             0 vi
Out of memory: Kill process 1816 (java) score 987 or sacrifice child
Killed process 1816 (java) total-vm:280410172kB, anon-rss:248040128kB, file-rss:0kB

---

kern.log清楚地表明它杀死了我的进程，因为它耗尽了内存。但就像我说的，我想我可以再挤一点。是否需要进行任何设置才能使用分配给JAVA的226GB。

您使用的是哪个JVM？您的系统有多少处理器或内核？您在Linux内核中启用了NUMA吗？我用详细信息编辑了我的问题。。。至于努玛。。。我不知道…JVM消耗的内存比堆多。它的开销需要一些内存。使用分布式缓存，而不是太大的堆。我想知道主要的车库收藏需要多长时间：）。顺便说一句：你使用巨大的页面吗？对于G1GC来说，只有几毫秒的时间是可以的。大页面？我试试看Distributed cache=要立即实施，需要花费一定的费用。。。但是在-Xmx226g中，虚拟机需要多少？请记住，linux以180Gb的速度杀死了它，我认为这可能与Java开发人员有关。特别是当它们需要调整以适应大内存使用时。