文章目录
问题描述
运维新增对某服务的监控后发现：内存不断上涨的现象。进一步确认，是因为有多个导出日志操作导致的内存上涨问题。
进一步的测试得出的结果是：容器刚启动是占用内存约为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内存