登录 / 注册
IT168云计算频道
IT168首页 > 云计算 > 云计算资讯 > 正文

对比:Docker和容器内进程内存计算差别

2018-07-12 16:02    潇洒的云世界 来源:潇洒的云世界  作者: 潇洒 编辑: 陶然

  【IT168 资讯】生产环境上了大规模容器集群后,肯定需要对容器进行监控,容器的编排我们采用了Kubernetes,监控前期采用了Weave Scope,后期采用了cAdvisor+Heapster+InfluxDB的方案,刚开始监控感觉并没有什么异常,但是集群运行久了之后,发现监控的指标和预想的并不一样。

  我们有对应的Java应用跑在容器中,每个Container的资源限制了4C16G(看起来和虚机一样夸张),JVM设置了Xmx2G的限制,但是发现有些容器的内存使用率一直在16G左,完全没有释放出来。Weave Scope和Heapster监控采集到的指标都是一样的,但是实际登录容器后发现JVM才用了800M不到。Weave Scope上其实可看到container和container内process的内存消耗,这个和实际登录容器看到的是一样的结果,如下图(剩余的那些sleep等进程其实占内存很少,忽略不计)

  

  

  我们可以用docker stats查看对应容器的资源消耗,看到内存使用率在16G左,如下图

  

  其实容器内部就是Linux对于内存的计算方式,我Baidu了一下发现Linux和Docker对于容器内存的计算是有差异的,Linux中buffer/cache是不计算进used memory的,所以下图中total=free+used+buff/cache,free命令的数据来源于/proc/meminfo

  

  Docker本身的内存要通过cgroup文件中相关数据计算,我们进入对应容器的cgroup目录中,我们的容器以Pod为最小单位运行在Kubernetes环境中,所以路径在/sys/fs/cgroup/memory/kubepods下,后面跟着Pod的唯一标识和container的唯一标志

  /sys/fs/cgroup/memory/kubepods/pod2534673f-68bd-11e8-9fff-325ce3dddf77/245ac9f74c34b666ba14fadab30ef51c0f6259324b4b2f100e9b6b732b4c0933

  在该目录中有一个memory.limit_in_bytes文件,这个就是Kubernetes的YAML文件通过resource.limit将值传递给Docker API下发的内存限制,cat查看为17179869184,单位Byte,转换后刚好为16G;然后我们看到有一个memory.usage_in_bytes,为当前容器的内存使用量,cat查看为17179824128,转换后15.9999G,Docker的原生监控,就是我们在用的这些Weave Scope和Heapster其实都是查询这个memory.usage_in_bytes的值;那么我们怎么推算出实际容器中应用消耗的内存总量呢,我们需要查看该目录下的memory.stat文件,cat看到如下内容

  [root@docker 245ac9f74c34b666ba14fadab30ef51c0f6259324b4b2f100e9b6b732b4c0933]# cat memory.stat cache 15749447680 rss 817262592 rss_huge 715128832 mapped_file 3653632 swap 0 pgpgin 59308038 pgpgout 55485716 pgfault 97852409 pgmajfault 1048 inactive_anon 0 active_anon 817238016 inactive_file 7932751872 active_file 7816630272 unevictable 0 hierarchical_memory_limit 17179869184 hierarchical_memsw_limit 34359738368 total_cache 15749447680 total_rss 817262592 total_rss_huge 715128832 total_mapped_file 3653632 total_swap 0 total_pgpgin 59308038 total_pgpgout 55485716 total_pgfault 97852409 total_pgmajfault 1048 total_inactive_anon 0 total_active_anon 817238016 total_inactive_file 7932751872 total_active_file 7816630272 total_unevictable 0

  对其中常用项的解释如下表

  

  实际Container中实际内存使用量real_used =memory.usage_in_bytes - (rss + active_file + inactive_file),但是一个resource.limit为16G的Container,JVM应用只是用了几百兆,但监控查到使用了16G,多出的15G用在哪里。我们查询了InfluxDB数据库,拉出了Pod的监控历史,发现有一个时间点,内存使用率从16G一下子掉到了11G,并且在1分钟后上升到了16G,此时间点通过工作记录发现是有清容器日志的操作,应用将日志通过文件的形式写在宿主机的文件系统中,我们找了测试环境尝试,将一个内存消耗为7G的Container的5G日志清掉,docker stats可以看到Container的内存使用率一下子掉到了4G,并且active_file和inactive_flie都有大幅度的下降,这里为什么清了日志内存使用率只掉到4G,因为我们还有其他的写文件日志没有清,以及Container本身输出在Stdout的json.log。这样的高内存使用率长达1周,但是我们发现并没有让容器因为OOM(Out-Of-Memory)而退出,推算出容器中的Cache其实会根据实际的内存分配量而使用,并不像程序为超额使用导致容器OOM退出。

关键字: Docker
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部