• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    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占用。

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

    上一篇:docker 查看进程, 内存, cup消耗的情况
    下一篇:docker 查看jvm内存占用方式
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

    docker 内存监控与压测方式 docker,内存,监控,与,压测,