devops-1："测试环境apollo配置服务频繁宕机"的问题解决

(1).异常现象

异常现象：2019-1-21~2019-1-22测试环境的apollo频繁宕机，大概有4~5次。

日志内容：提示内存不够。

(2).分析过程

测试环境的apollo机器只有一台，上边有两组应用：apollo和rocketmq。分别分析这两组应用。

先看系统内存：

很明显问题非常大，特别是cache，测试环境的体量不可能用到这么多cache。

我们需要分析哪些进程或者文件占用了这么多的cache，使用linux-fincore，统计结果：

如上图，可以看到，有个日志明显有问题，查看归属进程：

可以看到属于rocketmq-namesrv的gc日志，我们看看日志大小：

和fincore分析出的数据一致，那问题来了，为什么磁盘上的日志文件会占用内存的cache?

df -h看看磁盘，发现/dev/shm这个目录是在tmpfs文件系统上，tmpfs文件系统是很特殊的:

tmpfs,临时文件系统，是一种基于内存的文件系统。

内存的cache部分除了包含应用&磁盘的pageCache外，还包含tmpfs文件系统的cache。

真实原因：

rocketmq的gc日志默认打到了tmpfs文件系统上，也就是打到了内存里。

解决方法也很简单：

方法一：把gc日志文件改一个位置就可以了。

方法二（别这么干）：把gc文件删除，相当于把内存中的这部分空间释放。

(3).归纳&总结

1.linux有一种机制叫oom killer.

Linux 内核有个机制叫OOM killer(Out Of Memory killer)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存 耗尽而自动把该进程杀掉。

至于怎么选择杀掉那个进程，这个策略由内核决定。

2.tmpfs文件系统是一种基于内存的文件系统。

3.看到的未必是真实的，要顺着逻辑理。

4.这个问题又一次说明了为什么“云上的容器化"大行其道，容器互相隔离，互不影响。

(4).后续

1.apollo和rocketmq的容器化，apollo已经支持k8s容器化，两种方式：

k8s部署方式:

https://github.com/ctripcorp/apollo/blob/master/scripts/apollo-on-kubernetes/README.md

helm安装方式:

https://github.com/qct/apollo-helm

2.rocketmq方面，有一个rocketmq-operator:

https://github.com/huanwei/rocketmq-operator