而messages日志中，也没有OOM相关的记录。最后确认原因为：/proc/sys/vm/overcommit_memory参数导致。

该环境中该参数设置为2，表示“No overcommit”，即系统中所有进程占用的虚拟内存空间不能超过上限：

cat /proc/meminfo

CommitLimit:     kB  //虚拟地址空间的上限

Committed_AS:     kB  //当前的使用量

而该参数应该默认是0，这种情况下，只有还有空闲的物理内存，就可以继续分配，不受虚拟地址空间的限制。

echo  > /proc/sys/vm/overcommit_memory

如此修正后解决。

、关于overcommit_memory说明：

 取值为0，系统在为应用进程分配虚拟地址空间时，会判断当前申请的虚拟地址空间大小是否超过剩余内存大小，如果超过，则虚拟地址空间分配失败。因此，也就是如果进程本身占用的虚拟地址空间比较大或者剩余内存比较小时，fork、malloc等调用可能会失败。

 取值为1，系统在为应用进程分配虚拟地址空间时，完全不进行限制，这种情况下，避免了fork可能产生的失败，但由于malloc是先分配虚拟地址空间，而后通过异常陷入内核分配真正的物理内存，在内存不足的情况下，这相当于完全屏蔽了应用进程对系统内存状态的感知，即malloc总是能成功，一旦内存不足，会引起系统OOM杀进程，应用程序对于这种后果是无法预测的

 取值为2，则是根据系统内存状态确定了虚拟地址空间的上限，由于很多情况下，进程的虚拟地址空间占用远大小其实际占用的物理内存，这样一旦内存使用量上去以后，对于一些动态产生的进程(需要复制父进程地址空间)则很容易创建失败，如果业务过程没有过多的这种动态申请内存或者创建子进程，则影响不大，否则会产生比较大的影响