docker 内存监控与压测方式

一直运行的docker容器显示内存已经耗尽，并且容器内存耗尽也没出现重启情况，通过后台查看发现进程没有占用多少内存。内存的监控使用的是cadvisor，计算方式也是使用cadvisor的页面计算方式，所以决定对docker的内存计算做下研究。

docker version:

Client:

Version:  1.12.6

API version: 1.24

Go version: go1.6.4

Git commit: 78d1802

Built:  Tue Jan 10 20:20:01 2022

OS/Arch:  linux/amd64

Server:

Version:  1.12.6

API version: 1.24

Go version: go1.6.4

Git commit: 78d1802

Built:  Tue Jan 10 20:20:01 2022

OS/Arch:  linux/amd64

kubernetes version:

Client Version: version.Info{Major:”1″, Minor:”8″, GitVersion:”v1.8.2+coreos.0″, GitCommit:”4c0769e81ab01f47eec6f34d7f1bb80873ae5c2b”, GitTreeState:”clean”, BuildDate:”2022-10-25T16:24:46Z”, GoVersion:”go1.8.3″, Compiler:”gc”, Platform:”linux/amd64″}

Server Version: version.Info{Major:”1″, Minor:”8″, GitVersion:”v1.8.2+coreos.0″, GitCommit:”4c0769e81ab01f47eec6f34d7f1bb80873ae5c2b”, GitTreeState:”clean”, BuildDate:”2022-10-25T16:24:46Z”, GoVersion:”go1.8.3″, Compiler:”gc”, Platform:”linux/amd64″}
1.创建pod yaml文件，使用busybox镜像做测试，对镜像设定2核2G内存的限制

[docker@k8s busybox]$ cat busybox.yaml

apiVersion: v1

kind: Pod

metadata:

name: busybox

namespace: default

spec:

containers:

– image: registry.dcos:8021/public/busybox:latest

command:

  – sleep

  – “3600”

imagePullPolicy: IfNotPresent

name: busybox

resources:

  limits:

  cpu: “2”

  memory: 2Gi

  requests:

  cpu: 100m

  memory: 64Mi

restartPolicy: Always


2.通过kubectl命令生成busybox服务

[docker@k8s busybox]$ kubectl create -f busybox.yaml

pod “busybox” created


3.进入容器的/sys/fs/cgroup/memory目录，ls查看得到如下文件

-rw-r–r– 1 root  root   0 May 31 03:18 cgroup.clone_children

–w–w–w- 1 root  root   0 May 31 03:18 cgroup.event_control

-rw-r–r– 1 root  root   0 May 31 03:18 cgroup.procs

-rw-r–r– 1 root  root   0 May 31 03:18 memory.failcnt

–w——- 1 root  root   0 May 31 03:18 memory.force_empty

-rw-r–r– 1 root  root   0 May 31 03:18 memory.kmem.failcnt

-rw-r–r– 1 root  root   0 May 31 03:18 memory.kmem.limit_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.kmem.max_usage_in_bytes

-r–r–r– 1 root  root   0 May 31 03:18 memory.kmem.slabinfo

-rw-r–r– 1 root  root   0 May 31 03:18 memory.kmem.tcp.failcnt

-rw-r–r– 1 root  root   0 May 31 03:18 memory.kmem.tcp.limit_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.kmem.tcp.max_usage_in_bytes

-r–r–r– 1 root  root   0 May 31 03:18 memory.kmem.tcp.usage_in_bytes

-r–r–r– 1 root  root   0 May 31 03:18 memory.kmem.usage_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.limit_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.max_usage_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.memsw.failcnt

-rw-r–r– 1 root  root   0 May 31 03:18 memory.memsw.limit_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.memsw.max_usage_in_bytes

-r–r–r– 1 root  root   0 May 31 03:18 memory.memsw.usage_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.move_charge_at_immigrate

-r–r–r– 1 root  root   0 May 31 03:18 memory.numa_stat

-rw-r–r– 1 root  root   0 May 31 03:18 memory.oom_control

———- 1 root  root   0 May 31 03:18 memory.pressure_level

-rw-r–r– 1 root  root   0 May 31 03:18 memory.soft_limit_in_bytes

-r–r–r– 1 root  root   0 May 31 03:18 memory.stat

-rw-r–r– 1 root  root   0 May 31 03:18 memory.swAPPiness

-r–r–r– 1 root  root   0 May 31 03:18 memory.usage_in_bytes

-rw-r–r– 1 root  root   0 May 31 03:18 memory.use_hierarchy

-rw-r–r– 1 root  root   0 May 31 03:18 notify_on_release

-rw-r–r– 1 root  root   0 May 31 03:18 tasks我们主要关注一下几个文件

memory.stat的文件包含的内容

查看memory.limit_in_bytes文件

/sys/fs/cgroup/memory # cat memory.limit_in_bytes

2147483648计算容器的限制内存为2g，和yaml文件里面定义的限制内存一样。查看memory.usag_in_bytes文件

/sys/fs/cgroup/memory # cat memory.usage_in_bytes

2739376通过docker stats 容器id查看容器的占用内存，和memory.usage_in_bytes的数据相符。


4.使用dd命令快速生成1.5g大文件

~ # dd if=/dev/zero of=test bs=1M count=1500

1500+0 records in

1500+0 records out

1572864000 bytes (1.5GB) copied, 1.279989 seconds, 1.1GB/s再次通过docker stats 容器id查看容器的占用内存

查看memory.usage_in_bytes文件

/sys/fs/cgroup/memory # cat memory.usage_in_bytes

1619329024发现容器的占用内存达到了1.5g，查看memory.stat

/sys/fs/cgroup/memory # cat memory.stat

cache 1572868096

rss 147456

rss_huge 0

mapped_file 0

dirty 1572868096

writeback 0

swap 0

pgpgin 384470

pgpgout 433

pgfault 607

pgmajfault 0

inactive_anon 77824

active_anon 12288

inactive_file 1572864000

active_file 4096

unevictable 0

hierarchical_memory_limit 2147483648

hierarchical_memsw_limit 4294967296

total_cache 1572868096

total_rss 147456

total_rss_huge 0

total_mapped_file 0

total_dirty 1572868096

total_writeback 0

total_swap 0

total_pgpgin 384470

total_pgpgout 433

total_pgfault 607

total_pgmajfault 0

total_inactive_anon 77824

total_active_anon 12288

total_inactive_file 1572864000

total_active_file 4096

total_unevictable 0

memory.stat文件中的cache字段添加了1.5g，而inactive_file字段为1.5g，因此，dd所产生的文件cache计算在inactive_file上。这就导致了所看到的容器内存的监控居高不下，因为cache是可重用的，并不能反映进程占用内存。

一般情况下，计算监控内存可根据计算公式：

active_anon + inactive_anon = anonymous memory + file cache for tmpfs + swap cache

Therefore

active_anon + inactive_anon ≠ rss, because rss does not include tmpfs.

active_file + inactive_file = cache – size of tmpfs所以实际内存使用计算为：

real_used = memory.usage_in_bytes – (active_file + inactive_file)
5.压测

(1)准备tomcat镜像和jmeter压测工具，tomcat的yaml文件如下

apiVersion: extensions/v1beta1

kind: Deployment

metadata:

name: tomcat-deployment

spec:

replicas: 1

template:

metadata:

  labels:

  app: tomcat

spec:

  containers:

  – name: tomcat

  image: registy.dcos:8021/public/tomcat:8

  ports:

  – containerPort: 8080

  resources:

   limits:

   cpu: “1”

   memory: 300Mi

—

apiVersion: v1

kind: Service

metadata:

labels:

name: tomcat

name: tomcat

namespace: default

spec:

ports:

– name: tomcat

port: 8080

protocol: TCP

targetPort: 8080

type: NodePort

selector:

app: tomcatyaml文件中限制tomcat镜像的使用内存为300Mi，执行命令生成文件。通过docker stats查看没有负载情况下tomcat容器的内存占用。

(2)提取tomcat的service nodePort端口

[docker@ecs-5f72-0006 ~]$ kubectl get svc tomcat -o=custom-columns=nodePort:.spec.ports[0].nodePort

nodePort

31401(3)登陆jmeter官网下载压测工具

在windows上运行jmeter工具，到bin目录点击运行jmeter，配置jmeter如下：

配置好测试选项后点击启动按钮开始压测，通过docker stats查看容器内存使用情况发现已经到达限制。

通过kubectl get pods查看pod的运行情况发现tomcat由于内存超过限制值被kill掉。

总结

关于docker stats内存监控的问题一直存在，docker将cache/buffer纳入内存计算引起误解。docker内存的计算方式和linux的内存使用计算方式一致，也包含了cache/buffer。

但是cache是可重复利用的，经常使用在I/O请求上，使用内存来缓解可能被再次访问的数据，为提高系统性能。

在官方github上，也有很多人提交了关于内存监控的issue，直到了Docker 17.06版本，docker stats才解决了这个问题。

但是这也仅仅是docker stats的显示看起来正常了，而进入容器查看内存的使用还是包含的cache，如果直接使用cadvisor搜集的数据，还是会出现包含了cache的情况。

通过压测docker，最后发现当压测到程序的限制内存时，pod出现重启，这也解释了我们在使用docker监控时，即使内存占用99%+，却不出现pod重启的情况，这里面有相当一部分的内存是cache占用。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持共生网络。如有错误或未考虑完全的地方，望不吝赐教。