这篇文章主要介绍了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 2017 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 2017 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:\"2017-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:\"2017-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.usage_in_bytes | 已使用的内存量(包含cache和buffer)(字节)，相当于linux的used_meme |
| memory.limit_in_bytes | 限制的内存总量(字节)，相当于linux的total_mem |
| memory.failcnt | 申请内存失败次数计数 |
| memory.stat | 内存相关状态 |
memory.stat的文件包含的内容
| 字段 | 含义 |
|---|---|
| cache | 页缓存，包括 tmpfs（shmem），单位为字节 |
| rss | 匿名和 swap 缓存，不包括 tmpfs（shmem），单位为字节 |
| mapped_file | memory-mapped 映射的文件大小，包括 tmpfs（shmem），单位为字节 |
| pgpgin | 存入内存中的页数 |
| pgpgout | 从内存中读出的页数 |
| swap | swap 用量，单位为字节 |
| active_anon | 在活跃的最近最少使用（least-recently-used，LRU）列表中的匿名和 swap 缓存，包括 tmpfs（shmem），单位为字节 |
| inactive_anon | 不活跃的 LRU 列表中的匿名和 swap 缓存，包括 tmpfs（shmem），单位为字节 |
| active_file | 活跃 LRU 列表中的 file-backed 内存，以字节为单位 |
| inactive_file | 不活跃 LRU 列表中的 file-backed 内存，以字节为单位 |
| unevictable | 无法再生的内存，以字节为单位 |
| hierarchical_memory_limit | 包含 memory cgroup 的层级的内存限制，单位为字节 |
| hierarchical_memsw_limit | 包含 memory cgroup 的层级的内存加 swap 限制，单位为字节 |
查看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查看容器的占用内存
![图片[1]-docker 内存监控与压测方式_docker-安全小天地](https://img.godyu.com/2023/12/20231226103003970.jpg?imageView2/0/format/webp/q/75)
查看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: tomcat
yaml文件中限制tomcat镜像的使用内存为300Mi，执行命令生成文件。通过docker stats查看没有负载情况下tomcat容器的内存占用。
![图片[2]-docker 内存监控与压测方式_docker-安全小天地](https://img.godyu.com/2023/12/20231226183004923.jpg?imageView2/0/format/webp/q/75)
(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如下：
![图片[3]-docker 内存监控与压测方式_docker-安全小天地](https://img.godyu.com/2023/12/20231226183004872.jpg?imageView2/0/format/webp/q/75)
![图片[4]-docker 内存监控与压测方式_docker-安全小天地](https://img.godyu.com/2023/12/20231226183006561.jpg?imageView2/0/format/webp/q/75)
配置好测试选项后点击启动按钮开始压测，通过docker stats查看容器内存使用情况发现已经到达限制。
![图片[5]-docker 内存监控与压测方式_docker-安全小天地](https://img.godyu.com/2023/12/20231226183007830.jpg?imageView2/0/format/webp/q/75)
通过kubectl get pods查看pod的运行情况发现tomcat由于内存超过限制值被kill掉。
![图片[6]-docker 内存监控与压测方式_docker-安全小天地](https://img.godyu.com/2023/12/20231226183008925.jpg?imageView2/0/format/webp/q/75)
总结
关于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占用。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持安全小天地。如有错误或未考虑完全的地方，望不吝赐教。
暂无评论内容