一次操作系统报错OutOfMemory Error的处理记录

超、凢脫俗 2022-11-22 12:39 337阅读 0赞

参考文章：[一次操作系统报错OutOfMemory Error的处理记录][OutOfMemory Error]

[Linux 申请内存失败解决方法][Linux]

在启动公司内嵌的tomcat容器时出现报错, 如下:

# There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (malloc) failed to allocate 160088 bytes for AllocateHeap
    # An error report file with more information is saved as:
    # /users/xxx/hs_err_pidxxxx.log

然后查看`/users/xxx/hs_err_pidxxxx.log`内容:

#
    # There is insufficient memory for the Java Runtime Environment to continue.
    # Native memory allocation (mmap) failed to map 357564416 bytes for committing reserved memory.
    # Possible reasons:
    #   The system is out of physical RAM or swap space
    #   The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
    # Possible solutions:
    #   Reduce memory load on the system
    #   Increase physical memory or swap space
    #   Check if swap backing store is full
    #   Decrease Java heap size (-Xmx/-Xms)
    #   Decrease number of Java threads
    #   Decrease Java thread stack sizes (-Xss)
    #   Set larger code cache with -XX:ReservedCodeCacheSize=
    #   JVM is running with Unscaled Compressed Oops mode in which the Java heap is
    #     placed in the first 4GB address space. The Java Heap base address is the
    #     maximum limit for the native heap growth. Please use -XX:HeapBaseMinAddress
    #     to set the Java Heap base and to place the Java Heap above 4GB virtual address.
    # This output file may be truncated or incomplete.
    #
    #  Out of Memory Error (os_linux.cpp:2749), pid=4252, tid=0x00007f3f38bb5700
    #
    # JRE version:  (8.0_201-b09) (build )
    # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode linux-amd64 compressed oops)
    # Core dump written. Default location: /users/ems/core or core.4252 (max size 521000 kB). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
    #
    ...

翻译过来就是本地内存分配失败, 可能的原因有两种

> 1.  系统物理内存或虚拟内存不足
> 2.  程序在压缩指针模式下运行, Java堆会阻塞本地堆的增长

然后使用`free -m`命令查询, 发现内存足够:

total       used       free     shared    buffers     cached
    Mem:          7983       5415       2568          0        170       1460
    -/+ buffers/cache:       3784       4199
    Swap:        15257         71      15186

**解决方案:**

这个问题是由于`/proc/meminfo`下的`vm.overcommit_memory`被设置成不允许`overcommit`造成的

`overcommit是指`对虚拟内存的过量分配; 用户进程申请的是虚拟地址,虚拟内存需要物理内存做支撑, 如果分配太多虚拟内存, 会对性能参数影响.

**`vm.overcommit_memory`的用处: 控制过量分配的策略. 这个参数一共有3个可选值:**

>  *  `0`: Heuristic overcommit handling. 就是由操作系统自己决定过量分配策略
>  *  `1`: Always overcommit. 一直允许过量分配
>  *  `2`: Don't overcommit. 不允许过量分配

**优缺点分析:**

>  *  0 — 默认设置。内核执行启发式内存过量使用处理，方法是估算可用内存量，并拒绝明显无效的请求。遗憾的是因为内存是使用启发式而非准确算法计算进行部署，这个设置有时可能会造成系统中的可用内存超载。
>  *  1 — 内核执行无内存过量使用处理。使用这个设置会增大内存超载的可能性，但也可以增强大量使用内存任务的性能。
>  *  2 — 内存拒绝等于或者大于总可用 swap 大小以及 overcommit\_ratio 指定的物理 RAM 比例的内存请求。如果您希望减小内存过度使用的风险，这个设置就是最好的。

在这个案例里面, 使用`sysctl vm.overcommit_memory`来查看, 发现`vm.overcommit_memory = 2`, 即采用的是不允许过量分配的设置. 而在错误日志中也证明了这一点:

#查看内存申请和可用情况
    #CommitLimit 表示系统可申请的总内存
    #Committed_AS为当前已经申请的内存
    [root@localhost vm]# cat /proc/meminfo | grep Commit
    CommitLimit:    15951192 kB
    Committed_AS:   15837036 kB
    
    #说明:
    #  Committed_AS: OS会预测启动这个程序时, 所有的进程可能会用到多少的内存, 如果超过了CommitLimit, 就会报错

**解决方式:**

> 1.  echo 1 > /proc/sys/vm/overcommit\_memory  
>     此方式临时生效,系统重启后消失
> 2.  **`sudo sysctl vm.overcommit_memory=0`**, 即`vm.overcommit_memory = 0`, 允许系统自己决定过量分配策略
> 3.  编辑/etc/sysctl.conf , 添加vm.overcommit\_memory=1，然后sysctl -p 使配置文件永久生效  
>     **当然这是我们在开发环境下的解决方式, 在生产环境还是要尽量去优化调整JVM的参数来保证每个程序都有足够的内存来保证运行**

[OutOfMemory Error]: https://www.jianshu.com/p/3f8692eb3660
[Linux]: https://www.jianshu.com/p/eb2b0fe7392e?from=singlemessage