JVM崩溃时hs_err_pidxxx.log文件中错误的rlimit信息

Question

    #
    # There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (mmap) failed to map 65536 bytes for committing reserved memory.
    # Possible reasons:
    #   The system is out of physical RAM or swap space
    #   In 32 bit mode, the process size limit was hit
    # Possible solutions:
    #   Reduce memory load on the system
    #   Increase physical memory or swap space
    #   Check if swap backing store is full
    #   Use 64 bit Java on a 64 bit OS
    #   Decrease Java heap size (-Xmx/-Xms)
    #   Decrease number of Java threads
    #   Decrease Java thread stack sizes (-Xss)
    #   Set larger code cache with -XX:ReservedCodeCacheSize=
    # This output file may be truncated or incomplete.
    #
    #  Out of Memory Error (os_linux.cpp:2627), pid=1094, tid=0x00007fac4041e700
    #
    # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 1.8.0_102-b14)
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode linux-amd64 compressed oops)
    # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
    #

    ---------------  S Y S T E M  ---------------

    OS:DISTRIB_ID=Ubuntu
    DISTRIB_RELEASE=14.04
    DISTRIB_CODENAME=trusty
    DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"

    uname:Linux 3.13.0-101-generic #148-Ubuntu SMP Thu Oct 20 22:08:32 UTC 2016 x86_64
    libc:glibc 2.19 NPTL 2.19 
    rlimit: STACK 8192k, CORE 0k, NPROC 30034, NOFILE 4096, AS infinity
    load average:10.38 6.50 2.88

我的问题是：为什么NOFILE不对应于我在系统上设置的值（在limits.conf文件中，它应该是20000）？当我使用与运行jvm的用户相同的用户运行命令ulimit-n时，我有一个不同的值。请注意，显示的堆栈是我在系统上设置的正确值，而不是默认值。JVM运行在AWS C3.Large随需应变实例上。

以下是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) 30034
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 20000
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) 30034
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Answer 1

我检查了源代码¹。事实证明，转储中打印的rlimit值是通过调用getrlimit获得的。这是一个直接从操作系统获取信息的POSIX库方法。JVM不会减少它的NOFILES rlimit，尽管在某些情况下，它会将软rlimit增加到硬rlimit的值。

因此，我怀疑转储中报告的rlimit必须在启动运行应用程序的JVM的环境中设置。这不能与运行ulimit的shell环境相同。

^{1-...使用find和grep，所以我可能遗漏了什么。}