一 问题描述

11月19日中午同事反馈，河南mongo(192.168.192.82-84)业务受影响，当时排查，发现shard3被宕掉了两个进程，shard2被宕掉了一个进程。

当时通过启动进程恢复了业务。

后听同事说11月20日上午mongo又发生了异常宕机的问题，通过临时启动mongo进程恢复了业务。

二 排查思路

2.1 查看11月20日哪个mongo进程宕机了

#这里通过mongo的启动日期判断

 发现11月20日宕掉了两个shard2，1个shard3。

2.2 查看宕机节点的日志是否有相关报错

cd /data/mongo/shard2

less shard2.log

发现并未有相关报错。

2.3 查看systemctl启动日志

执行journalctl -u mongod_shard2

可以看到mongod_shard2是被killed掉的：

mongod_shard2.service: main process exited, code=killed, status=9/KILL

2.4 使用dmesg查看mongo的信息

[5872527.013380] Out of memory: Kill process 31447 (mongod) score 531 or sacrifice child

[5872527.013591] Killed process 31447 (mongod) total-vm:13026860kB, anon-rss:9221132kB, file-rss:0kB, shmem-rss:0kB

 可以看到是操作系统内存不足，导致mongo被killed掉了。

当内存不足时，会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程，不是内核线程)，以便释放内存。

三 解决办法

① 增大服务器内存，增大swap

由于服务器内存不足，这里选择增大交换内存。

扩交换内存可参考：

Linux系统怎么调整swap分区大小_雅冰石的专栏-CSDN博客_linux调整swap大小

② 限制mongo内存使用

#由于服务器共16G内存，每台服务器上有三个分片，因此这里限制每个分片最多使用3G内存。

systemctl set-property mongod_shard2 MemoryLimit=3G

缺点：性能会有所下降。

③ 监控内存使用率

当发现服务器内存使用率较高，可通过重启较耗内存的mongo进程释放内存。

缺点：

治标不治本。

--本篇文章参考了：

MongoDB killed by linux - Stack Overflow