贸易网站建设案例北京优化靠谱的公司

问题描述

运维新增对某服务的监控后发现：内存不断上涨的现象。进一步确认，是因为有多个导出日志操作导致的内存上涨问题。

进一步的测试得出的结果是：容器刚启动是占用内存约为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缓存占用的内存。

经验：

1. ps aux 查看的RSS只包含了物理内存，不包含 buffer/cache 内存
2. 使用docker stats 命令查看到的内存数据不是实际上的物理内存，而是包含了cache部分，使用该数据用于监控不一定准确。
3. 从 /sys/fs/cgroup/memory/docker/<container-id>/memory.stat 可以看到docker容器实际的内存使用情况（很有用！！）
4. 如有必要，可以使用 sudo sh -c "echo 1 > /proc/sys/vm/drop_caches" 释放cache内存