文章目录
问题描述
运维新增对某服务的监控后发现:内存不断上涨的现象。进一步确认,是因为有多个导出日志操作导致的内存上涨问题。
进一步的测试得出的结果是:容器刚启动是占用内存约为50M左右,在多次地导出日志操作后,内存能涨到2G以上。
问题:为什么日志导出会导致容器的内存不断上涨?
原因分析
分析1
在宿主机器中,使用docker stats 查看服务,内存占用内存792MB
在docker 容器中,通过ps aux命令查看容器中使用的总内存=29MB+147MB+139MB=315MB左右
使用kill命令杀死服务的workerman子进程(父进程不跑业务,并且在容器中杀不死),可以看到:
- workerman子进程重新拉起后内存24MB+21MB=45MB,重新拉起后的进程内存占用减少239MB
- doker stats 内存在kill后的内存减少了229MB
猜测:容器中只有wokerman的子进程会在执行导出后占用内存,并且使用ps命令也没有看到其他进程。怀疑:容器本身存在缓存,并且docker stat命令查看的内存值应该包含这部分缓存的内存。
分析2
使用docker stat查看容器的内存使用为:666MB
在容器中,使用htop命令查看容器中各个进程的总内存约为:27MB+118MB+85MB = 230MB左右(包含部分的代码缓存等)
在 /sys/fs/cgroup/memory/docker//memory.stat 中查看内存情况
验证猜想
为了验证确实是 cache占用的内存,我们手动清理cache缓存验证一下,如下
运行以下命令可以清理 PageCache:
- sudo sh -c "echo 1 > /proc/sys/vm/drop_caches" (这将清空 PageCache 中的缓存数据,但不会影响正在使用的程序数据。)
可以看到,docker stats 的内存也从 666.MB降到了182MB,和 /sys/fs/cgroup/memory/docker//memory.stat 中查看内存情况基本一致。
结论和经验
结论:不是代码中的内存泄露,是cache缓存占用的内存。
经验:
ps aux
查看的RSS只包含了物理内存,不包含buffer/cache
内存- 使用docker stats 命令查看到的内存数据不是实际上的物理内存,而是包含了cache部分,使用该数据用于监控不一定准确。
- 从
/sys/fs/cgroup/memory/docker/<container-id>/memory.stat
可以看到docker容器实际的内存使用情况(很有用!!) - 如有必要,可以使用
sudo sh -c "echo 1 > /proc/sys/vm/drop_caches"
释放cache内存