记Cassandra的OOM问题分析和解决（mmap failed）

背景

公司业务中使用到Cassandra，笔者在自运维过程中频繁遇到Cassandra进程定期OOM问题。问题截图如下：

此Cassandra集群共10台机器，每台机器都是固定大概10天左右会出现一次OOM，业务中是通过定时任务启动guard脚本在发现进程失败后马上重启进程保证了业务正常（Cassandra数据与副本，短暂的1台机器进程失败不会导致业务损失）。但这么解决终究不是办法，因此开启了长时间的OOM排查（由于10天才出现一次，各种调整等测试时间跨度都很大，大概用了1个Q才完整彻底确认有效的调整方案）。

历程

最初经历过堆内存调整、Cassandra配置调整、系统参数调整等各种尝试，都无效。偶然的一次分析中，注意到了Cassandra的启动日志中一些警告，猜想是否有关，经过实验确认后确实是有效。这些警告如下：

优化点1：启动日志：Maximum number of memory map areas per process (vm.max_map_count) 65530 is too low, recommended value: 1048575, you can change it with sysctl.
优化点2：启动日志：Unable to lock JVM memory (ENOMEM). This can result in part of the JVM being swapped out, especially with mmapped I/O enabled. Increase RLIMIT_MEMLOCK or run Cassandra as root.
优化点3：启动日志：Cassandra server running in degraded mode. Is swap disabled? : true,  Address space adequate? : true,  nofile limit adequate? : true, nproc limit adequate? : false 
优化点4：启动日志：jemalloc shared library could not be preloaded to speed up memory allocations

这里列出的优化点是最初根据日志判定的可能的4个优化点，最终并不是都是关键，笔者业务中OOM问题主要是优化点1。事后分析，实际也合理，因为报错中提到了mmap，mmap是linux环境下文件访问的一种优化手段。默认系统限制进程可使用的mmap数量，OOM问题即mmap数量达到上限，因此实际只需要调大这个参数即可。
虽然只有优化点1有效，但是下面对给出前3个优化点的调整方式，第4个优化点无法调整，改动较大，需要OP才有权限操作。
优化点1：
调整 /etc/sysctl.conf 新增如下内容：

vm.max_map_count = 1048575

然后执行命令使之生效：

sudo sysctl -p

优化点2&优化点3
调整 /etc/security/limits.conf 新增如下内容，其中work需要替换为账号即可。

work - memlock unlimited
work - nofile 102400
work - nproc 32768
work - as unlimited

注意，如上调整完之后，需要重启下Cassandra进程。

总结

Cassandra运维坑很多，但如多花时间，仔细看日志，看报错日志还是可分析些问题的。