Docker资源限制和如何监控

　　容器比较强大的地方就是使用方便，强大的隔离性，但是生产上往往需要做到保护，比如a容器不能对于b容器造成任何影响，比如a容器资源占用太高，导致b容器无法响应，获取a容器down机影响宿主机或其他容器等等，都是不允许的，所以容器隔离技术就解决了这些问题！1、cgroup简介
　　cgroup是ControlGroups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组所使用的物理资源（如cpu、memory、磁盘IO等等）的机制，被LXC、docker等很多项目用于实现进程资源控制。cgroup将任意进程进行分组化管理的Linux内核功能。cgroup本身是提供将进程进行分组化管理的功能和接口的基础结构，IO或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。这些具体的资源管理功能称为cgroup子系统，有以下几大子系统实现：blkio：设置限制每个块设备的输入输出控制。例如：磁盘，光盘以及usb等等。cpu：使用调度程序为cgroup任务提供cpu的访问。cpuacct：产生cgroup任务的cpu资源报告。cpuset：如果是多核心的cpu，这个子系统会为cgroup任务分配单独的cpu和内存。devices：允许或拒绝cgroup任务对设备的访问。freezer：暂停和恢复cgroup任务。memory：设置每个cgroup的内存限制以及产生内存资源报告。netcls：标记每个网络包以供cgroup方便使用。ns：命名空间子系统。perfevent：增加了对每group的监测跟踪的能力，即可以监测属于某个特定的group的所有线程以及运行在特定CPU上的线程。
　　目前docker只是用了其中一部分子系统，实现对资源配额和使用的控制。2、docker如何限制的
　　使用的是stress镜像压测：https：hub。docker。comrjfustermstressdockerpulljfustermstress1、内存限制
　　选项
　　描述
　　m，memory
　　内存限制，格式是数字加单位，单位可以为b，k，m，g。最小为4M
　　memoryswap
　　内存交换分区大小总限制。格式同上。必须必m设置的大
　　memoryreservation
　　内存的软性限制。格式同上
　　oomkilldisable
　　是否阻止OOMkiller杀死容器，默认没设置
　　oomscoreadj
　　容器被OOMkiller杀死的优先级，范围是〔1000，1000〕，默认为0
　　memoryswappiness
　　用于设置容器的虚拟内存控制行为。值为0100之间的整数
　　kernelmemory
　　核心内存限制。格式同上，最小为4M
　　为了压测我们选择一个容器
　　1、只设置m参数，可以发现当限制内存在128m时，我们还是可以分配128m的，所以m并不是全部的限制dockerrunitrmm128mjfustermstressvm1vmbytes128mt5sstress：info：〔1〕dispatchinghogs：0cpu，0io，1vm，0hddstress：info：〔1〕successfulruncompletedin5s
　　当我们继续增加到原来的两倍，发现运行失败dockerrunitrmm128mjfustermstressvm1vmbytes256mt5sstress：info：〔1〕dispatchinghogs：0cpu，0io，1vm，0hddstress：FAIL：〔1〕（415）worker6gotsignal9stress：WARN：〔1〕（417）nowreapingchildworkerprocessesstress：FAIL：〔1〕（421）killerror：Nosuchprocessstress：FAIL：〔1〕（451）failedruncompletedin1s
　　当我们设置为250m，发现运行成功dockerrunitrmm128mjfustermstressvm1vmbytes250mt5sstress：info：〔1〕dispatchinghogs：0cpu，0io，1vm，0hddstress：info：〔1〕successfulruncompletedin5s
　　2、设置memory和memoryswap参数
　　设置128128，分配127时OK的，dockerrunitrmmemory128mmemoryswap128mjfustermstressvm1vmbytes127mt5sstress：info：〔1〕dispatchinghogs：0cpu，0io，1vm，0hddstress：info：〔1〕successfulruncompletedin5s
　　设置128128，分配128失败dockerrunitrmmemory128mmemoryswap128mjfustermstressvm1vmbytes128mt5sstress：info：〔1〕dispatchinghogs：0cpu，0io，1vm，0hddstress：FAIL：〔1〕（415）worker7gotsignal9stress：WARN：〔1〕（417）nowreapingchildworkerprocessesstress：FAIL：〔1〕（421）killerror：Nosuchprocessstress：FAIL：〔1〕（451）failedruncompletedin1s2、如何查看容器真实内存〔rootcentoslinux〕dockerrunrmitm128malpinebinshfreemtotalusedfreesharedbuffcacheavailableMem：19802661143215691559Swap：000
　　经常遇到这种问题，容器内的内存和真实内存其实是不一致的，原因是啥？
　　这是由于docker产生的容器的隔离性不足造成的。docker创建容器时，会为容器提供一些必要的目录和文件，比如proc下的若干文件。其中procmeminfo文件docker并没有直接提供其生成，而是将宿主机的procmeminfo挂载给了容器。因此容器看到的procmeminfo与宿主机的procmeminfo的内容是一样的。而free命令也不过是查看该文件的信息而已。如果想增强其隔离性，可以使用lxcfs的方式。
　　那如何解决了？
　　docker其实本身使用cgroup进行隔离，其实它监控也只能监控cgroup，本机是CentOSLinuxrelease7。9。2009（Core）〔rootcentoslinux〕lssysfscgroupmemorydocker9fc278a2cab2bde9f2aa10fb8eb58732f4d1f3ce0f988ed64cac4b4616a585f1cgroup。clonechildrenmemory。kmem。tcp。maxusageinbytesmemory。oomcontrolcgroup。eventcontrolmemory。kmem。tcp。usageinbytesmemory。pressurelevelcgroup。procsmemory。kmem。usageinbytesmemory。softlimitinbytesmemory。failcntmemory。limitinbytesmemory。statmemory。forceemptymemory。maxusageinbytesmemory。swappinessmemory。kmem。failcntmemory。memsw。failcntmemory。usageinbytesmemory。kmem。limitinbytesmemory。memsw。limitinbytesmemory。usehierarchymemory。kmem。maxusageinbytesmemory。memsw。maxusageinbytesnotifyonreleasememory。kmem。slabinfomemory。memsw。usageinbytestasksmemory。kmem。tcp。failcntmemory。movechargeatimmigratememory。kmem。tcp。limitinbytesmemory。numastat
　　文件名称
　　含义
　　memory。usageinbytes
　　已使用的内存量（包含cache和buffer）（字节），相当于linux的usedmeme
　　memory。limitinbytes
　　限制的内存总量（字节），相当于linux的totalmem
　　memory。failcnt
　　申请内存失败次数计数
　　memory。memsw。usageinbytes
　　已使用的内存和swap（字节）
　　memory。memsw。limitinbytes
　　限制的内存和swap容量（字节）
　　memory。memsw。failcnt
　　申请内存和swap失败次数计数
　　memory。stat
　　内存相关状态
　　查看〔rootcentoslinux〕dockerstats9fc278a2cab2bde9f2aa10fb8eb58732f4d1f3ce0f988ed64cac4b4616a585f1nostreamCONTAINERIDNAMECPUMEMUSAGELIMITMEMNETIOBLOCKIOPIDS9fc278a2cab2elatedpanini0。00560KiB128MiB0。431。01kB0B0B0B1〔rootcentoslinux9fc278a2cab2bde9f2aa10fb8eb58732f4d1f3ce0f988ed64cac4b4616a585f1〕catmemory。usageinbytes573440
　　所以可以看到两组数据基本一致，具体逻辑：https：github。comopencontainersruncblobv0。1。1libcontainercgroupsfsmemory。goL148
　　参考：Docker容器内存监控