docker 限制容器对CPU的使用

上节学习了如何限制容器对内存的使用，本节我们来看CPU。

默认设置下，所有容器可以平等地使用 host CPU 资源并且没有限制。

Docker 可以通过-c或--cpu-shares设置容器使用 CPU 的权重。如果不指定，默认值为 1024。

与内存限额不同，通过-c设置的 cpu share 并不是 CPU 资源的绝对数量，而是一个相对的权重值。某个容器最终能分配到的 CPU 资源取决于它的 cpu share 占所有容器 cpu share 总和的比例。

换句话说：通过 cpu share 可以设置容器使用 CPU 的优先级。

比如在 host 中启动了两个容器：

docker run --name "container_A" -c 1024 ubuntu

docker run --name "container_B" -c 512 ubuntu

container_A 的 cpu share 1024，是 container_B 的两倍。当两个容器都需要 CPU 资源时，container_A 可以得到的 CPU 是 container_B 的两倍。

需要特别注意的是，这种按权重分配 CPU 只会发生在 CPU 资源紧张的情况下。如果 container_A 处于空闲状态，这时，为了充分利用 CPU 资源，container_B 也可以分配到全部可用的 CPU。

下面我们继续用 progrium/stress 做实验。

1、启动 container_A，cpu share 为 1024：

--cpu用来设置工作线程的数量。因为当前 host 只有 1 颗 CPU，所以一个工作线程就能将 CPU 压满。如果 host 有多颗 CPU，则需要相应增加--cpu的数量。

2、启动 container_B，cpu share 为 512：

3、在 host 中执行top，查看容器对 CPU 的使用情况：

container_A 消耗的 CPU 是 container_B 的两倍。

4、现在暂停 container_A：

5、top显示 container_B 在 container_A 空闲的情况下能够用满整颗 CPU：

CPU限额就讨论到这里，以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持我们。

赞 (0)

相关推荐

  • 详解Docker cpu限制分析

    本文测试了,Docker容器限制cpu资源使用的几个配置参数.分别使用top和dstat命令分析了资源占有情况. package main import ( "flag" "runtime" "fmt" ) func main() { cpunum := flag.Int("cpunum", 0, "cpunum") flag.Parse() fmt.Println("cpunum:",

  • docker 限制容器对CPU的使用

    docker 限制容器对CPU的使用

    上节学习了如何限制容器对内存的使用,本节我们来看CPU. 默认设置下,所有容器可以平等地使用 host CPU 资源并且没有限制. Docker 可以通过-c或--cpu-shares设置容器使用 CPU 的权重.如果不指定,默认值为 1024. 与内存限额不同,通过-c设置的 cpu share 并不是 CPU 资源的绝对数量,而是一个相对的权重值.某个容器最终能分配到的 CPU 资源取决于它的 cpu share 占所有容器 cpu share 总和的比例. 换句话说:通过 cpu shar

  • Docker 限制容器可用的CPU的方式

    默认情况下容器可以使用的主机 CPU 资源是不受限制的.和内存资源的使用一样,如果不对容器可以使用的 CPU 资源进行限制,一旦发生容器内程序异常使用 CPU 的情况,很可能把整个主机的 CPU 资源耗尽,从而导致更大的灾难.本文将介绍如何限制容器可以使用的 CPU 资源. 本文的 demo 中会继续使用<Docker: 限制容器可用的内存>一文中创建的 docker 镜像 u-stress 进行压力测试,文中就不再过多的解释了. 限制可用的 CPU 个数 在 docker 1.13 及更高的

  • 如何使用docker对容器资源进行限制

    问题窥探 在服务器当中,假设iis服务部署多个站点,那么只要其中一个站点出问题,假设是cpu100%,或者是内存爆满,那么这台服务器上的其他站点都会跟着挂掉.同样在使用容器时,单台主机上可能会跑几十个容器,容器虽然都相互隔离,但是用的却是与宿主机相同的内核,CPU.内存.磁盘等硬件资源.如果不对容器资源进行限制,容器之间就会相互影响. 解决办法 Docker提供了限制内存,CPU或磁盘IO的方法, 可以对容器所占用的硬件资源大小以及多少进行限制,我们在使用docker create创建一个容器或

  • 聊聊Docker中容器的创建与启停问题

    聊聊Docker中容器的创建与启停问题

    目录 1. 镜像和容器 2. 新建并启动容器 3. 使用第一个容器 4. 容器命名 5.重启容器 6. 附着到容器上 1. 镜像和容器 看待镜像和容器的一种方式是将它们类比成程序与进程.一个进程可以视为一个被执行的应用程序,同样,一个Docker容器可以视为一个运行中的Docker镜像. 标题Docker镜像与容器 如果大家熟悉面向对象原理,看待镜像和容器的另一种方法是将镜像看作类而将容器看作对象.对象是类的具体实例,同样,容器是镜像的实例.用户可以从单个镜像创建多个容器,就像对象一样,它们之间

  • Docker Runc容器生命周期详细介绍

    Docker Runc容器生命周期 容器的生命周期涉及到内部的程序实现和面向用户的命令行界面,runc内部容器状态转换操作.runc命令的参数定义的操作.docker client定义的容器操作是不同的,比如对于docker client的create来说, 语义和runc就完全不同,这一篇文章分析runc的容器生命周期的抽象.内部实现以及状态转换图.理解了runc的容器状态转换再对比理解docker client提供的容器操作命令的语义会更容易些. 容器生命周期相关接口 最基本的require

  • .NETCore Docker实现容器化与私有镜像仓库管理

    一.Docker介绍 Docker是用Go语言编写基于Linux操作系统的一些特性开发的,其提供了操作系统级别的抽象,是一种容器管理技术,它隔离了应用程序对基础架构(操作系统等)的依赖.相较于虚拟机而言,Docker共享的是宿主机的硬件资源,使用容器来提供独立的运行环境来运行应用.虚拟机则是基于Supervisor(虚拟机管理程序)使用虚拟化技术来提供隔离的虚拟机,在虚拟机的操作系统上提供运行环境!虽然两者都提供了很好的资源隔离,但很明显Docker的虚拟化开销更低! Docker涉及了三个核心

  • docker中容器的网络配置常用命令详解

    网络基础配置 虽然Docker可以根据镜像"多开"容器,并而每个容器互不影响,但并不代表容器与容器之间是完全决裂的.Docker在运行镜像的时候提供了映射容器端口到宿主主机.容器端口到另一个容器的网络互联功能,使得容器与宿主主机.容器与容器之间可以相互通信. ### 从外部访问容器应用 在启动容器的时候,如果不指定对应的参数,在容器外是无法通过网络来访问容器内的网络应用和服务的.当容器中运行一些需要被外部访问的网络应用时,可以通过-P或者-p参数来指定端口映射.当使用-P标记时,Doc

  • Centos7下安装与卸载docker应用容器引擎的方法

    Docker 是一个开源的应用容器引擎,基于Go 语言并遵从Apache2.0协议开源. Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级.可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化. 容器是完全使用沙箱机制,相互之间不会有任何接口(类似 iPhone 的 app),更重要的是容器性能开销极低. Docker的应用场景 Web 应用的自动化打包和发布. 自动化测试和持续集成.发布. 在服务型环境中部署和调整数据库或其他的后台应用. 从头编译或者扩展现

  • Docker创建容器时目录权限踩坑

    昨天写项目时需要用到Mysql的衍生版本percona, 就想用Doker来安装.结果踩了一晚上坑, 今早终于解决. 现记录在此. 这个坑原因是我对linux的目录权限问题不敏感导致的. 我的系统是ubuntu16.04, 运行 docker pull percona 拉取镜像时一切正常. 拉取完后,输入 docker images查看所有镜像, 显示正常: 然后我创建容器,命令为(执行时不要有换行): docker create --name percona -v /data/mysql-da

  • IDEA中使用Docker Compose容器编排的实现

    (一)确保idea 中连接到docker (二)打包镜像 我这里测试的是前后分离项目 如果是微服务中呢,由于前文中在pom.xml 中绑定了idea docker 打包插件 在其 父工程中使用 打包命令 即可将其子模块 打成一个个镜像 (三)Compos编排文件编写 docker compose 使用镜像编排 version: '3' #compose 文件版本(1.2.x+ 用3即可) services: #指定服务名 建议还是与项目名一致 虽然其并没有什么实际性联系 lei-server:

随机推荐