热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

docker内存监控与压测方式

这篇文章主要介绍了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查看容器的占用内存

查看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)提取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占用。

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


推荐阅读
  • k8s进阶之搭建私有镜像仓库
    企业级私有镜像仓 ... [详细]
  • 在Docker中,将主机目录挂载到容器中作为volume使用时,常常会遇到文件权限问题。这是因为容器内外的UID不同所导致的。本文介绍了解决这个问题的方法,包括使用gosu和suexec工具以及在Dockerfile中配置volume的权限。通过这些方法,可以避免在使用Docker时出现无写权限的情况。 ... [详细]
  • docker+k8s+git+jenkins
    docker+k8s+git+jenkins,Go语言社区,Golang程序员人脉社 ... [详细]
  • 本文|层面_Kubernetes概述
    篇首语:本文由编程笔记#小编为大家整理,主要介绍了Kubernetes概述相关的知识,希望对你有一定的参考价值。前言本文搜集大量关于Kuber ... [详细]
  • 云原生边缘计算之KubeEdge简介及功能特点
    本文介绍了云原生边缘计算中的KubeEdge系统,该系统是一个开源系统,用于将容器化应用程序编排功能扩展到Edge的主机。它基于Kubernetes构建,并为网络应用程序提供基础架构支持。同时,KubeEdge具有离线模式、基于Kubernetes的节点、群集、应用程序和设备管理、资源优化等特点。此外,KubeEdge还支持跨平台工作,在私有、公共和混合云中都可以运行。同时,KubeEdge还提供数据管理和数据分析管道引擎的支持。最后,本文还介绍了KubeEdge系统生成证书的方法。 ... [详细]
  • 本文探讨了容器技术在安全方面面临的挑战,并提出了相应的解决方案。多租户保护、用户访问控制、中毒的镜像、验证和加密、容器守护以及容器监控都是容器技术中需要关注的安全问题。通过在虚拟机中运行容器、限制特权升级、使用受信任的镜像库、进行验证和加密、限制容器守护进程的访问以及监控容器栈,可以提高容器技术的安全性。未来,随着容器技术的发展,还需解决诸如硬件支持、软件定义基础设施集成等挑战。 ... [详细]
  • 随着我司的应用都开始容器化,相应的ETL流程也需要迁移到容器中。常规的SQL和shell脚本迁移之后执行基本没有问题,主要的问题在于数据接入使用kettle的场景下,kettle启 ... [详细]
  • 有意向可以发简历到邮箱内推.简历直达组内Leader.能做同事的话,内推奖励全给你. ... [详细]
  • 本文主要介绍关于linux文件描述符设置,centos7设置文件句柄数,centos7查看进程数的知识点,对【Linux之进程数和句柄数】和【linux句柄数含义】有兴趣的朋友可以看下由【东城绝神】投 ... [详细]
  • “自主设计与实施的故障注入微服务Sidecar,欢迎大佬批评指正!”
    “故障注入Sidecar“——为您的微服务注入故障以验证集群性能!由于导师和实验室师兄们的科研需要,本人专门以Sidecar的模式设计了一个用于错误注入的微服务模块。该模块可以与任 ... [详细]
  • Webmin远程命令执行漏洞复现及防护方法
    本文介绍了Webmin远程命令执行漏洞CVE-2019-15107的漏洞详情和复现方法,同时提供了防护方法。漏洞存在于Webmin的找回密码页面中,攻击者无需权限即可注入命令并执行任意系统命令。文章还提供了相关参考链接和搭建靶场的步骤。此外,还指出了参考链接中的数据包不准确的问题,并解释了漏洞触发的条件。最后,给出了防护方法以避免受到该漏洞的攻击。 ... [详细]
  • Oracle优化新常态的五大禁止及其性能隐患
    本文介绍了Oracle优化新常态中的五大禁止措施,包括禁止外键、禁止视图、禁止触发器、禁止存储过程和禁止JOB,并分析了这些禁止措施可能带来的性能隐患。文章还讨论了这些禁止措施在C/S架构和B/S架构中的不同应用情况,并提出了解决方案。 ... [详细]
  • k8shelm官网:https:helm.sh点击charts:https:artifacthub.iopackagessearch?sortrelevance&page11.1h ... [详细]
  • 本文csdn博客链接:http:blog.csdn.netscrescentarticledetails51135307本文qq空间链接:http:user.qzone.qq.com ... [详细]
  • kubelet配置cni插件_Kubernetes新近kubectl及CNI漏洞修复,Rancher 2.2.1发布
    今天,Kubernetes发布了一系列补丁版本,修复新近发现的两个安全漏洞CVE-2019-1002101(kubectlcp命令安全漏洞)和CVE-2 ... [详细]
author-avatar
mobiledu2502905343
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有