精华内容
下载资源
问答
  • docker内存及cpu限制
    千次阅读
    2022-01-28 13:21:48

    在一台物理机上启动了多个docker容器时,就需要对内存及cpu做出相关的限制,以达到容器互不影响的目的

    限制内存:-m选项

    注:限制内存后进入容器中(free -m)查看内存,显示的内存为物理机的内存

    [root@120 ~]# docker ps
    CONTAINER ID        IMAGE                                                                                         COMMAND                  CREATED             STATUS              PORTS                                        NAMES
    1aeade88d27a        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-product:2.1.8-tag             "/bin/sh -c 'java $J…"   25 hours ago        Up 3 hours                                                       mofang-product-2.1.8-tag
    8610b298396c        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-data-task:2.1.8-tag           "/bin/sh -c 'java $J…"   2 days ago          Up 2 days                                                        mofang-data-task-2.1.8-tag
    101e1f5ee972        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-order:2.1.8-tag               "/bin/sh -c 'java $J…"   2 days ago          Up 2 days                                                        mofang-order-2.1.8-tag
    e994363d153e        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-poster:2.1.8-tag              "/bin/sh -c 'java $J…"   5 days ago          Up 5 days                                                        mofang-poster-2.1.8-tag
    4877fd9dbb4c        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-favorable:2.1.8-tag           "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-favorable-2.1.8-tag
    7607f38b6370        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-favorable-service:2.1.8-tag   "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-favorable-service-2.1.8-tag
    25766b7207d8        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-train-order:2.1.8             "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-train-order-2.1.8
    48c320d6c632        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-pay-h5:2.1.8                  "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-pay-h5-2.1.8
    8717fae49094        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-api:2.1.8                     "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-api-2.1.8
    8fc24cf77676        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-user-service:2.1.8            "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-user-service-2.1.8
    8af954b1c40d        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-pro-service:2.1.8             "/bin/sh -c 'java $J…"   8 days ago          Up 8 days                                                        mofang-pro-service-2.1.8
    ebe4174da4bd        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-task:2.1.7-tag                "/bin/sh -c 'java $J…"   3 weeks ago         Up 3 weeks                                                       mofang-task-2.1.7-tag
    c352d4d80891        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-base:2.1.7                    "/bin/sh -c 'java $J…"   3 weeks ago         Up 3 weeks                                                       mofang-base-2.1.7
    d11759013859        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-user:2.1.5                    "/bin/sh -c 'java $J…"   4 weeks ago         Up 4 weeks                                                       mofang-user-2.1.5
    6ed77309b86d        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-order-service:2.1.5           "/bin/sh -c 'java $J…"   4 weeks ago         Up 4 weeks                                                       mofang-order-service-2.1.5
    eccc0a54b58e        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-direct-tickets-order:2.1.2    "/bin/sh -c 'java $J…"   2 months ago        Up 2 months                                                      mofang-direct-tickets-order-2.1.2
    e7a9333952b0        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-direct-presale-order:2.1.2    "/bin/sh -c 'java $J…"   2 months ago        Up 2 months                                                      mofang-direct-presale-order-2.1.2
    b03aa8bd0f06        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-pc:2.0.9-2-tag                "/bin/sh -c 'java $J…"   6 months ago        Up 6 months                                                      mofang-pc-2.0.9-2-tag
    92ff30ad1fd1        registry.cn-shenzhen.aliyuncs.com/mofang-images-shenzhen/mofang-permission:2.0.9-2-tag        "/bin/sh -c 'java $J…"   6 months ago        Up 6 months                                                      mofang-permission-2.0.9-2-tag
    08939d203840        registry.cn-shenzhen.aliyuncs.com/mofang-images/mofang-ueditor:master                         "sh -c 'java $JAVA_O…"   17 months ago       Up 17 months        8778/tcp, 0.0.0.0:5555->5555/tcp, 9779/tcp   mofang-ueditor
    [root@120 ~]# 
    

    查看限制结果:docker stats命令  可以看到此容器的内存使用量以及最大可以内存

    [root@120 ~]# docker stats 1aeade88d27a
    

     限制cpu的使用个数:--cpuset-cpus

    --cpuset-cpus使用方法:

        0,1,3,5:指定使用0,1,3,5的cpu

        0-3:使用0,1,2,3的cpu

    测试限制cpu是否成功:

    注:限制cpu后进入容器中通过top查看的还是物理机的cpu

    测试方法:agileek/cpuset-test

     下载CPU测试p_w_picpath;agileek/cpuset-test给出了一种用于测试CPU的p_w_picpath,功能就是将指定的CPU资源用满

    [root@47 ~]# docker pull agileek/cpuset-test
    Using default tag: latest
    Trying to pull repository docker.io/agileek/cpuset-test ... 
    latest: Pulling from docker.io/agileek/cpuset-test
    93ac0475d7f8: Pull complete 
    Digest: sha256:e35ce26d2c801af5e22dbb994dbaa4a17688caa5d7c8faeb1e8dad35f2e7b56e
    Status: Downloaded newer image for docker.io/agileek/cpuset-test:latest
    [root@47 ~]# 
    

    测试--cpuset-cpus=0

    另开一窗口观察cpu的压力情况:mpstat -P ALL 3(mpstat安装包为sysstat)

    可以看到cpu0的在完全占用的情况,其余的cpu并没有受到影响

    由此判定--cpuset-cpus的高定生效了

    [root@47 ~]# mpstat -P ALL 3
    Linux 3.10.0-862.14.4.el7.x86_64 (47.113.108.247) 	01/28/2022 	_x86_64_	(8 CPU)
    
    02:18:25 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
    02:18:28 PM  all   13.25    0.00    0.84    0.00    0.00    0.08    0.00    0.00    0.00   85.83
    02:18:28 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
    02:18:28 PM    1    0.33    0.00    0.00    0.00    0.00    0.33    0.00    0.00    0.00   99.33
    02:18:28 PM    2    1.35    0.00    2.02    0.00    0.00    0.00    0.00    0.00    0.00   96.63
    02:18:28 PM    3    0.33    0.00    0.33    0.00    0.00    0.33    0.00    0.00    0.00   99.00
    02:18:28 PM    4    1.35    0.00    1.68    0.00    0.00    0.00    0.00    0.00    0.00   96.97
    02:18:28 PM    5    0.34    0.00    0.34    0.00    0.00    0.00    0.00    0.00    0.00   99.33
    02:18:28 PM    6    1.67    0.00    2.01    0.00    0.00    0.00    0.00    0.00    0.00   96.32
    02:18:28 PM    7    0.34    0.00    0.67    0.00    0.00    0.00    0.00    0.00    0.00   98.99
    
    02:18:28 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
    02:18:31 PM  all   13.67    0.00    1.42    0.00    0.00    0.54    0.00    0.00    0.00   84.36
    02:18:31 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
    02:18:31 PM    1    0.32    0.00    0.65    0.00    0.00    4.21    0.00    0.00    0.00   94.82
    02:18:31 PM    2    1.69    0.00    2.03    0.00    0.00    0.00    0.00    0.00    0.00   96.27
    02:18:31 PM    3    1.34    0.00    0.67    0.33    0.00    0.00    0.00    0.00    0.00   97.66
    02:18:31 PM    4    2.34    0.00    2.68    0.00    0.00    0.00    0.00    0.00    0.00   94.98
    02:18:31 PM    5    0.34    0.00    1.01    0.00    0.00    0.00    0.00    0.00    0.00   98.65
    02:18:31 PM    6    2.04    0.00    2.72    0.00    0.00    0.00    0.00    0.00    0.00   95.24
    02:18:31 PM    7    0.68    0.00    0.68    0.00    0.00    0.00    0.00    0.00    0.00   98.65
    
    02:18:31 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
    02:18:34 PM  all   13.44    0.00    1.00    0.08    0.00    0.33    0.00    0.00    0.00   85.14
    02:18:34 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
    02:18:34 PM    1    0.00    0.00    0.33    0.00    0.00    1.97    0.00    0.00    0.00   97.70
    02:18:34 PM    2    2.01    0.00    2.01    0.33    0.00    0.00    0.00    0.00    0.00   95.65
    02:18:34 PM    3    1.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    0.00   98.00
    02:18:34 PM    4    1.35    0.00    1.68    0.00    0.00    0.00    0.00    0.00    0.00   96.97
    02:18:34 PM    5    0.34    0.00    0.34    0.34    0.00    0.00    0.00    0.00    0.00   98.99
    02:18:34 PM    6    1.67    0.00    2.00    0.33    0.00    0.00    0.00    0.00    0.00   96.00
    02:18:34 PM    7    1.00    0.00    1.00    0.00    0.00    0.00    0.00    0.00    0.00   98.01
    
    02:18:34 PM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
    02:18:37 PM  all   14.35    0.00    1.13    0.38    0.00    0.13    0.00    0.00    0.00   84.02
    02:18:37 PM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
    02:18:37 PM    1    0.00    0.00    0.00    0.00    0.00    1.33    0.00    0.00    0.00   98.67
    02:18:37 PM    2    1.01    0.00    2.02    0.00    0.00    0.00    0.00    0.00    0.00   96.97
    02:18:37 PM    3    8.70    0.00    1.67    2.68    0.00    0.00    0.00    0.00    0.00   86.96
    02:18:37 PM    4    2.00    0.00    2.33    0.00    0.00    0.00    0.00    0.00    0.00   95.67
    02:18:37 PM    5    0.99    0.00    1.32    0.00    0.00    0.00    0.00    0.00    0.00   97.68
    02:18:37 PM    6    1.35    0.00    1.69    0.00    0.00    0.00    0.00    0.00    0.00   96.96
    02:18:37 PM    7    0.34    0.00    0.34    0.00    0.00    0.00    0.00    0.00    0.00   99.32
    

    更多相关内容
  • 详解Docker cpu限制分析

    2021-01-10 15:59:53
    本文测试了,Docker容器限制cpu资源使用的几个配置参数。分别使用top和dstat命令分析了资源占有情况。 package main import ( flag runtime fmt ) func main() { cpunum := flag.Int(cpunum, 0, cpunum) flag....
  • docker CPU限制的实现

    2021-01-09 00:01:51
     2)例如:如果主机有2个CPU,设置–cpus=”1.5″,则可以报称容器醉倒 容纳一半的CPU,相当于设置–cpu-period=”100000″和–cpu-quota=”150000″ 4核服务器中启动centos基础镜像,并设置使用1核CPU docker run...
  • 0. 问题原本部署在物理机...由于这些线程的数量与 CPU 的核心数是正相关的,所以在 docker 容器设置了 CPU 限制之后,应该比在物理机上少一些才对。以一个 CPU 设置为 4 的 docker 容器为例: “Parallel GC Threads...

    0. 问题

    原本部署在物理机上服务迁移至 docker 容器之后,发现 “Parallel GC Threads” 和 “C* CompilerThread” 的数量不正常。

    由于这些线程的数量与 CPU 的核心数是正相关的,所以在 docker 容器设置了 CPU 限制之后,应该比在物理机上少一些才对。

    以一个 CPU 设置为 4 的 docker 容器为例:

    c798163c5b9878dcc67147af692d6316.png

    “Parallel GC Threads” 线程数的计算公式在 vm_version.cpp 中:

    3f5f433315d0ac701e2c08cac4e453dd.png

    如果 os::active_processor_count() 返回 4,那么线程数应该是 4;但是实际的线程数为 33,可以反推 JVM 获取到的 CPU 核心数为 48,与物理机的核心数一致。

    现在的问题是:JVM 无法感知 docker 容器设置的 CPU 限制,至少在 Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode) 版本是这样。

    1. active_processor_count 的实现

    我们先看一下 jdk8u102-b14 中 active_processor_count() 方法的实现,在 os_linux.cpp 中:

    44aa9207d96d956e4692aef4aad51518.png

    通过 sysconf 获取当前在线的 CPU 核心数,这样获取的当然是物理机的 CPU 核心数。

    As of Java SE 8u131, and in JDK 9, the JVM is Docker-aware with respect to Docker CPU limits transparently. That means if -XX:ParalllelGCThreads, or -XX:CICompilerCount are not specified as command line options, the JVM will apply the Docker CPU limit as the number of CPUs the JVM sees on the system. The JVM will then adjust the number of GC threads and JIT compiler threads just like it would as if it were running on a bare metal system with number of CPUs set as the Docker CPU limit.

    使用 JDK 9 还遥遥无期,万幸 Java SE 8u131 也进行了兼容,在验证测试之前我们先看一下 jdk8u131-b11 中的代码实现:

    37c092fbd7f142fbee7fdf9e24a14463.png

    这个实现看起来只支持 --cpuset-cpus 这种指定固定 CPU 的方式。

    再来看一下 jdk8u191-b12 中的代码实现:

    3e29fdd5d70c5bc2cd0405a97096d1ba.png

    如果设置了 ActiveProcessorCount,那么使用配置的 CPU 核心数;

    如果判断是容器环境,判断和计算的逻辑封装在 OSContainer 中;

    否则,逻辑与 jdk8u131-b11 一致。

    is_containerized() 的实现在 osContainer_linux.hpp 中:

    4d65bab563d37b97bc9111c74caa8039.png

    _is_containerized 的初始化在 init() 方法中,由于代码比较多这里就不复制了,总结一下处理逻辑:

    如果 UseContainerSupport 为 false,那么 _is_containerized 为 false;

    无法读取 /proc/self/mountinfo,也是 false;

    无法解析 memory、cpuset、cpu,cpuacct、cpuacct、cpu 的 mount 信息,也是 false;

    无法读取 /proc/self/cgroup,也是 false;

    否则 _is_containerized 为 true。

    接着看一下 OSContainer::active_processor_count() 的实现:

    93f8752e5a27af0d8470e6eaa9deeaa5.png

    处理逻辑在注释中写得很清楚:

    8658367c9b436510a610c91ce81500b0.png

    如果你对 docker 不太熟悉,可以通过官方文档理解 cpu_quota、cpu_period 和 cpu_shares 这三个配置项。

    需要说明一下 cpu_shares 只是一个软限制,只有在机器 CPU 资源饱和时才有效,所以 PreferContainerQuotaForCPUCount 默认也是 true。

    2. 验证测试

    设置 --cpu-quota=800000、--cpu-period=100000、--cpu-shares=4096,也就是预期的 CPU 核心数是 8。

    fea9d15d98f2a086cb21f74f97f1ae85.png

    “Parallel GC Threads” 线程数符合预期。

    3. 其它解决方案

    升级 JDK 版本不太容易,新 feature 往往伴随着新 bug,所以也有一些外部链接预加载库的方案。

    展开全文
  • docker CPU限制参数

    千次阅读 2020-06-11 14:39:28
    docker CPU限制参数 Option Description --cpus=<value> Specify how much of the available CPU resources a container can use. For instance, if the host machine ...

    docker CPU限制参数

    Option

    Description

    --cpus=<value>

    Specify how much of the available CPU resources a container can use. For instance, if the host machine has two CPUs and you set --cpus="1.5", the container is guaranteed at most one and a half of the CPUs. This is the equivalent of setting --cpu-period="100000" and --cpu-quota="150000". Available in Docker 1.13 and higher.

    --cpu-period=<value>

    Specify the CPU CFS scheduler period, which is used alongside--cpu-quota. Defaults to 100 micro-seconds. Most users do not change this from the default. If you use Docker 1.13 or higher, use --cpusinstead.

    --cpu-quota=<value>

    Impose a CPU CFS quota on the container. The number of microseconds per --cpu-period that the container is limited to before throttled. As such acting as the effective ceiling. If you use Docker 1.13 or higher, use --cpus instead.

    --cpuset-cpus

    Limit the specific CPUs or cores a container can use. A comma-separated list or hyphen-separated range of CPUs a container can use, if you have more than one CPU. The first CPU is numbered 0. A valid value might be 0-3 (to use the first, second, third, and fourth CPU) or 1,3 (to use the second and fourth CPU).

    --cpu-shares

    Set this flag to a value greater or less than the default of 1024 to increase or reduce the container’s weight, and give it access to a greater or lesser proportion of the host machine’s CPU cycles. This is only enforced when CPU cycles are constrained. When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. --cpu-shares does not prevent containers from being scheduled in swarm mode. It prioritizes container CPU resources for the available CPU cycles. It does not guarantee or reserve any specific CPU access.

    ①   --cpus指示容器可以使用的CPU数量。改参数指定的是百分比,并不是具体的个数。比如:主机有4个逻辑CPU,限制容器—cpus=2,那么该容器最多可以使用的CPU时间是200%,但是4个CPU分配的时间可能是每个CPU各50%,而不一定是有其中2个CPU使用100%,而另2个CPU使用0%。

    --cpus是docker 1.13之后才出来的参数,目的是替代--cpu-period和--cpu-quota两个参数,从而使配置更简单。

    ②   --cpu-period表示的是设置CPU时间周期,默认值是100000,单位是us,即0.1s。

    ③   --cpu-quota指示容器可以使用的最大的CPU时间,配合--cpu-period值使用。如果—cpu-quota=200000,即0.2s。那就是说在0.1s周期内改容器可以使用0.2s的CPU时间,显然1个CPU是无法满足要求的,需要至少2个CPU才能满足。

    ④   --cpuset-cpus设置容器具体可以使用哪些个CPU。如--cpuset-cpus=”0,1,2”或者--cpuset-cpus=”0-2”,则容器会使用第0-2个CPU。

    ⑤   --cpu-shares,容器使用CPU的权重,默认值是1024,数值越大权重越大。该参数仅当有多个容器竞争同一个CPU时生效。对于单核CPU,如果容器A设置为--cpu-shares=2048,容器B设置为--cpus-shres=1024,仅当两个容器需要使用的CPU时间超过整个CPU周期的时候,容器A会被分配66%的CPU时间,容器B被分配33%的CPU时间,大约是2:1;对于多核CPU,仅当多个容器竞争同一个CPU的时候该值生效。

    kubernetes对CPU限制

    第一种:资源对象LimitRange限制POD和Container的资源

    apiVersion: v1
    kind: LimitRange
    metadata:
      name: mylimits
    spec:
      limits:
      - max:
          cpu: "2"
          memory: 1Gi
        min:
          cpu: 200m
          memory: 6Mi
        type: Pod
    
      - default:
          cpu: 300m
          memory: 200Mi
        defaultRequest:
          cpu: 200m
          memory: 100Mi
        max:
          cpu: "2"
          memory: 1Gi
        min:
          cpu: 100m
          memory: 3Mi
    type: Container

    第二种:定义pod时候限制资源

    spec:
      containers:
      - image: gcr.io/google_containers/serve_hostname
       imagePullPolicy: Always
       name: kubernetes-serve-hostname
       resources:
         limits:
           cpu: "1"
           memory: 512Mi
         requests:
           cpu: "1"
           memory: 512Mi

    如果两者都配置?

    先匹配pod里的,再匹配namespace里。

    有些时候, 我们大部分容器遵循一个规则就好, 但有一小部分有特殊需求, 这个时候, 小部分的就需要单独在容器的配置文件中指定. 这里有一点要注意的是, 单独在容器中配置的参数是不能大于指定的k8s资源限制, 否则会报错, 容器无法启动

    PS: 对于一些java项目, 必须设置java虚拟机的参数, 而且这个参数不能大于容器设置的限定值, 否则容器会因为内存过大不停的重启

     

    其中:

    limits.cpu  <==>  --cpu-quota         # docker inspect中的CpuQuota值

    requests.cpu  <==>  --cpu-shares     # docker inspect中的CpuShares值

    实验对比

    测试工具stress介绍

    root@ustress-77b658748b-7856l:/# stress --help

    `stress' imposes certain types of compute stress on your system

     

    Usage: stress [OPTION [ARG]] ...

     -?, --help         show this help statement

         --version      show version statement

     -v, --verbose      be verbose

     -q, --quiet        be quiet

     -n, --dry-run      show what would have been done

     -t, --timeout N    timeout after N seconds

         --backoff N    wait factor of N microseconds before work starts

     -c, --cpu N        spawn N workers spinning on sqrt()  #启动N个进程,每个进程最多占满一个CPU

     -i, --io N         spawn N workers spinning on sync()

     -m, --vm N         spawn N workers spinning on malloc()/free()

         --vm-bytes B   malloc B bytes per vm worker (default is 256MB)

         --vm-stride B  touch a byte every B bytes (default is 4096)

         --vm-hang N    sleep N secs before free (default none, 0 is inf)

         --vm-keep      redirty memory instead of freeing and reallocating

     -d, --hdd N        spawn N workers spinning on write()/unlink()

         --hdd-bytes B  write B bytes per hdd worker (default is 1GB)

     

    Example: stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 10s

     

    Note: Numbers may be suffixed with s,m,h,d,y (time) or B,K,M,G (size).

    创建一个测试镜像

    FROM ubuntu:latest

    RUN apt-get update && \

            apt-get install stress

     

    docker build -t reg.99bill.com/99bill/ustress .

    创建一个kubernetes中deployment对象

    apiVersion: apps/v1

    kind: Deployment

    metadata:

      labels:

        appname: ustress

        version: 0.0.6

      name: ustress

      namespace: default

    spec:

      replicas: 1

      selector:

        matchLabels:

          appname: ustress

      template:

        metadata:

          labels:

            appname: ustress

            version: 0.0.6

        spec:

          containers:

          - image: reg.99bill.com/99bill/u-stress:latest

            name: ustress

            command: ['sh', '-c', 'stress -c 4']

            resources:

              limits:

                cpu: 2   #实验修改值

                memory: 1G

              requests:

                cpu: 1   #实验修改值

                memory: 500M

          terminationGracePeriodSeconds: 0

          nodeName: 192.168.112.10

          nodeSelector:

    注:

    ①   command: ['sh', '-c', 'stress -c 4'] 表示开启4个占用CPU的stress进程

    ②   limits.cpu: 2 对应docker中"CpuQuota": 200000,  "CpuPeriod": 100000默认值

    ③   requests.cpu:1对应docker中"CpuShares": 1024,

    测试一:

    limits.cpu: 4

    requests.cpu: 0.5

     

    结果验证:

    1. 查看docker容器参数值:

    docker inspect e22896246184

     

    512 = 0.5 * 1024

    400000 = 4 * 100000

    2. docker stats查看容器CPU使用率

    由于设置了CPUQuota是CpuPeriod的4倍,所以容器可以使用400% CPU

    3. 使用top查看进程与CPU

    使用top命令查看4个stress进程,每个占用100% CPU,总400%,可以看到有4个CPU被跑满。

    实验二:

    limits.cpu: 6

    requests.cpu: 0.5

    1. 查看docker容器参数值:

     

    512 = 0.5 * 1024

    600000 = 6 * 100000

    2. docker stats查看容器CPU使用率

    容器可以使用600%的CPU,现在只用400%

    3. 使用top查看进程与CPU

    实验三:

    limits.cpu: 1

    requests.cpu: 0.5

    1. 查看docker容器参数值:

    docker inspect e22896246184

     

    512 = 0.5 * 1024

    100000 = 1 * 100000

    2. docker stats查看容器CPU使用率

    使用时间等于CpuPeriod,占用100%

    3. 使用top查看进程与CPU

    从下图可以看到,有4个CPU分别使用25%,加起来是100%。所以limits.cpu:1并不一定表示容器只会占用1个CPU,而表示的是容器最多可以使用的CPU时间的比例。

    实验四:

    limits.cpu: 0.5

    requests.cpu: 0.5

    1. 查看docker容器参数值

    2. docker stats查看容器CPU使用率

    3. 使用top查看进程与CPU

     

    展开全文
  • cpu资源限制4. namespace设置资源限制5. namespace中pod的配额6. namespace的创建、使用和删除7. 清除资源限制和配额 1. k8s容器资源限制 k8s采用request和limit两种限制类型来对资源进行分配 request(资源需求):...

    1. k8s容器资源限制

    k8s采用request和limit两种限制类型来对资源进行分配

    • request(资源需求):即运行pod的节点必须满足运行pod的最基本需求才能运行pod。
    • limit(资源限制):即运行pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额。

    资源类型:

    • CPU的单位是核心数,内存的单位是字节。
    • 一个容器申请0.5各CPU,就相当于申请1个CPU的一半,可以加个后缀m表示千分之一的概念。比如说100m的CPU,100豪的CPU和0.1个CPU都是一样的。

    内存单位:

    • K,M,G,T,P,E #通常是以1000为换算标准的。
    • Ki,Mi,Gi,Ti,Pi,Ei #通常是以1024为换算标准的。

    2. 内存资源限制实例

    [kubeadm@server2 limit]$ cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: memory-demo
    spec:
      containers:
     - name: memory-demo
        image: stress
        args:
        - --vm
        - "1"
        - --vm-bytes
        - 200M           // 容器使用200M
        resources:
          requests:      //资源需求,下限
            memory: 50Mi
          limits:        //资源限制,上限
            memory: 100Mi
    
    [kubeadm@server1 limit]$ kubectl get pod
    NAME                                      READY   STATUS             RESTARTS   AGE
    memory-demo                               0/1     CrashLoopBackOff   3          106s
    

    因为容器需要200M,超出了最大限制100Mi,所以容器无法运行。

    • 如果容器超过其内存限制,则会被终止。如果可重新启动,则与其他所有类型的运行故障一样,kubelet将重新启动它。
    • 如果一个容器超过其内存要求,那么当节点内存不足时,它的pod可能被逐出。

    在这里插入图片描述

    • 当资源限制没冲突的时候正常启动
    [kubeadm@server1 limit]$ vim pod.yaml 
    [kubeadm@server1 limit]$ cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: memory-demo
    spec:
      containers:
      - name: memory-demo
        image: k8s/stress
        args:
        - --vm
        - "1"
        - --vm-bytes
        - 200M
        resources:
          requests:
            memory: 50Mi
          limits:
            memory: 300Mi    //将最大限制改为300mi,容器可以正常运行
    [kubeadm@server1 limit]$
    

    在这里插入图片描述在这里插入图片描述
    资源限制内部机制使用的是cgroup类型
    目录: /sys/fs/cgroup/systemd

    3. cpu资源限制

    [kubeadm@server1 limit]$ cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: cpu-demo
    spec:
      containers:
      - name: cpu-demo
        image: stress
        args:
        - -c
        - "2"            //容器需要2个cpu
        resources:
          requests:           //至少需要5个cpu
            cpu: "5" 
          limits:
            cpu: "10"     //最大限制10个cpu
    
    [kubeadm@server1 limit]$ kubectl apply -f pod.yaml 
    pod/cpu-demo created
    
    [kubeadm@server1 limit]$ kubectl get pod -o wide
    NAME                                      READY   STATUS    RESTARTS   AGE     IP             NODE      NOMINATED NODE   READINESS GATES
    cpu-demo                                  1/1     Running   0          4m58s   10.244.2.124   server4   <none>           <none>
    [root@server4 ~]# top   // server4上的两个cpu跑满了,CPU 使用率过高,不会被杀死
    (top--->1)
    
    top - 16:41:55 up  6:37,  1 user,  load average: 3.77, 2.69, 1.54
    Tasks: 172 total,   4 running, 168 sleeping,   0 stopped,   0 zombie
    %Cpu0  : 98.7 us,  0.3 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.7 hi,  0.3 si,  0.0 st
    %Cpu1  : 98.3 us,  0.7 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.7 hi,  0.3 si,  0.0 st
    KiB Mem :  2045672 total,   784128 free,   293728 used,   967816 buff/cache
    KiB Swap:        0 total,        0 free,        0 used.  1520056 avail Mem 
    
      PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                      
    21204 root      20   0    7312    100      0 R  98.3  0.0   5:29.21 stress                                                                       
    21203 root      20   0    7312    100      0 R  97.0  0.0   5:29.84 stress 
    

    调度失败是因为申请的CPU资源超出集群节点所能提供的资源
    但CPU 使用率过高,不会被杀死
    在这里插入图片描述满足要求

    [kubeadm@server1 limit]$ vim pod.yaml 
    [kubeadm@server1 limit]$ cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: cpu-demo
    spec:
      containers:
      - name: cpu-demo
        image: k8s/stress
        args:
        - -c
        - "2"
        resources:
          requests:
            cpu: "1"
          limits:
            cpu: "2"
    [kubeadm@server1 limit]$
    

    在这里插入图片描述

    4. namespace设置资源限制

    LimitRange资源限制:

    apiVersion: v1
    kind: LimitRange
    metadata:
      name: limitrange-memory
    spec:
      limits:
     - default:            //默认使用0.5个cpu,512mi内存
          cpu: 0.5
          memory: 512Mi
        defaultRequest:       //默认要求0.1个cpu和256mi内存
          cpu: 0.1
          memory: 256Mi
        max:                //最大2个cpu和1gi内存
          cpu: 1
          memory: 1Gi
        min:               //最小0.1个cpu和100mi内存
          cpu: 0.1
          memory: 100Mi
        type: Container
    
    [kubeadm@server1 limit]$ kubectl apply -f limitrange.yaml 
    limitrange/limitrange-memory created
    
    [kubeadm@server1 limit]$ kubectl get limitranges 
    NAME                CREATED AT
    limitrange-memory   2020-05-08T08:52:10Z
    
    [kubeadm@server1 limit]$ kubectl describe limitranges 
    Name:       limitrange-memory
    Namespace:  default
    Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
    ----        --------  ---    ---  ---------------  -------------  -----------------------
    Container   cpu       100m   2    100m             500m           -
    Container   memory    100Mi  1Gi  256Mi            512Mi          -
    

    注意:LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。

    LimitRange - default xx会自动对没有设置资源限制的pod自动添加限制
    在这里插入图片描述ResourceQuota设置配额限制

    [kubeadm@server1 limit]$ cat quota.yaml 
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: mem-cpu-demo
    spec:
      hard:
        requests.cpu: "1"   // 要求cpu1个     即cpu要求不得超过1个cpu
        requests.memory: 1Gi  // 要求内存1gi    即内存要求不得超过1Gi
        limits.cpu: "2"  // cpu限制2个          即cpu限制不得超过2个cpu
        limits.memory: 2Gi // 内存限制2gi       即内存限制不得超过2Gi
    
    [kubeadm@server1 limit]$ kubectl apply -f quota.yaml 
    resourcequota/mem-cpu-demo created
    
    [kubeadm@server1 limit]$ kubectl get resourcequotas 
    NAME           AGE   REQUEST                                     LIMIT
    mem-cpu-demo   13s   requests.cpu: 0/1, requests.memory: 0/1Gi   limits.cpu: 0/2, limits.memory: 0/2Gi
    
    [kubeadm@server1 limit]$ kubectl describe resourcequotas 
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used  Hard
    --------         ----  ----
    limits.cpu       0     2
    limits.memory    0     2Gi
    requests.cpu     0     1
    requests.memory  0     1Gi
    

    在这里插入图片描述一旦设置配额后,后续的容器必须设置请求(4种请求都设置),当然,这只是在rq设置的defult的namespace中

    4种请求:每个容器必须设置内存请求(memory request),内存限额(memory limit),cpu请求(cpu request)和cpu限额(cpu limit

    资源会统计总的namespace中的资源加以限定,不管是之前创建还是准备创建
    创建的ResourceQuota对象将在default名字空间中添加以下限制:

    • 每个容器必须设置内存请求(memory request),内存限额(memory limit),cpu请求(cpu
      request)和cpu限额(cpu limit)。
    • 所有容器的内存请求总额不得超过1 GiB。
    • 所有容器的内存限额总额不得超过2 GiB。
    • 所有容器的CPU请求总额不得超过1 CPU。
    • 所有容器的CPU限额总额不得超过2 CPU。

    5. namespace中pod的配额

    [kubeadm@server1 limit]$ cat podquata.yaml 
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: pod-demo
    spec:
      hard:
        pods: "2"        //2个pod
    

    设置Pod配额以限制可以在namespace中运行的Pod数量。

    [kubeadm@server1 limit]$ kubectl apply -f podquata.yaml 
    resourcequota/pod-demo created
    
    [kubeadm@server1 limit]$ kubectl describe resourcequotas pod-demo // 当前只有一个pod
    Name:       pod-demo
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    pods        1     2
    
    [kubeadm@server1 limit]$ cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: test
    spec:
      containers:
      - name: test
        image: nginx
    
    //创建一个pod
    [kubeadm@server1 limit]$ kubectl apply -f pod.yaml 
    pod/test created
    
    [kubeadm@server1 limit]$ cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: test1
    spec:
      containers:
      - name: test1
        image: nginx
    
    //再创建一个pod时,会发生错误,因为在当前的namespace中限制两个pod
    [kubeadm@server1 limit]$ kubectl apply -f pod.yaml 
    Error from server (Forbidden): error when creating "pod.yaml": pods "test1" is forbidden: exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2
    

    当然,以上设定对应相对的namespace,其它的namespace没有影响

    为了后续不受影响,删除相应的设定

    在这里插入图片描述在这里插入图片描述

    6. namespace的创建、使用和删除

    创建namespace

    kubectl create namespace test  // 创建test的namespace
    

    运行yaml文件时指定namespace

    kubectl apply -f pod.yaml -n test  // 在test的namespace中运行pod.yaml为文件
    

    删除namespace

    kubectl delete namespaces test // 删除名为test的namespace
    

    7. 清除资源限制和配额

    [kubeadm@server1 limit]$ kubectl delete -f limitrange.yaml 
    limitrange "limitrange-memory" deleted
    
    [kubeadm@server1 limit]$ kubectl delete -f podquata.yaml 
    resourcequota "pod-demo" deleted
    
    [kubeadm@server1 limit]$ kubectl delete -f quota.yaml 
    resourcequota "mem-cpu-demo" deleted
    
    展开全文
  • 启动一个受限制的容器 [yeqiang@localhost testproj]$ docker run --rm -it -m 1G --cpus=3 centos /bin/bash 查看内存限制 [root@a2b39516cbf6 /]# cat /sys/fs/cgroup/...查看CPU限制 [root@a2b39516cbf6 .
  • docker的cpu限制方法

    千次阅读 2018-07-26 22:59:24
    http://blog.51cto.com/cyycyy/1931198 http://www.cnblogs.com/sparkdev/p/8052522.html
  • k8s容器资源限制内存限制示例:CPU限制示例:为namespace设置资源限制:为namespace设置资源配额: Kubernetes采用request和limit两种限制类型来对资源进行分配。 request(资源需求):即运行Pod的节点必须满足运行...
  • CPU限制4. 为namespace设置资源限制 1.资源的限制类型 Kubernetes采用request和limit两种限制类型来对资源进行分配。 • request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能 运行Pod。 • limit...
  • CPU占用限制

    2019-01-09 20:54:27
    win7以上可以通过本软件限制单个进程对cpu的使用,不过限制多个进程时要多次操作
  • Docker cpu限制分析

    万次阅读 2016-08-21 16:08:13
    本文测试了,docker容器限制cpu资源使用的几个配置参数。分别使用top和dstat命令分析了资源占有情况。package mainimport ( "flag" "runtime" "fmt" )func main() { cpunum := flag.Int("cpunum", 0, "cpunum") ...
  • Yarn下CGroups对CPU限制的理解

    千次阅读 2018-04-25 20:00:06
    好奇Yarn CGroup限制是怎么样对CPU限制的? CGroup对CPU限制 cpushares隔离: 给我们提供了一种可以按权重比率弹性分配cpu时间资源的手段;当cpu空闲的时候,某一个要占用cpu的cgroup可以完全占用剩余cpu时间...
  • 如果理解kubernetes的cpu限制单位m

    千次阅读 2018-12-27 15:14:33
    https://baijiahao.baidu.com/s?id=1617016837230066138&amp;wfr=spider&amp;for=pc
  • 今天一个会员说亲测修复 金刚电竞 解密去授权 LOL赛事预测电竞游戏比分竞猜源码 修复比赛采集这个源码安装不了,我问他你按照说明安装的mysql8.0根redis了吗,他说...宝塔面板最低内存和最低CPU限制Mysql 5.6 :最低...
  • 今天小编就为大家分享一篇Tensorflow限制CPU个数实例,具有很好的参考价值,希望对大家有所帮助。一起跟随小编过来看看吧
  • docker内存及cpu限制(不断总结中)

    千次阅读 2017-02-08 19:58:52
    在一台物理机上启动了多个docker容器时,就需要对内存及cpu做出相关的限制,以达到容器互不影响的目的限制内存:-m选项注:限制内存后进入容器中(free -m)查看内存,显示的内存为物理机的内存[root@localhost~]#...
  • 该程序能够限制某个选择的进程的cpu占用率,
  • CPU使用限制,某个软件使用的CPU很高,你就可以使用这个软件来限制这个软件的CPU使用。
  • linux下限制CPU使用率的3种方法

    千次阅读 2021-05-10 08:39:41
    linux下限制CPU使用率的3种方法1,apache本身的限制功能(RLimitCPU)引用国外这个帖子Ray03-19-2008, 05:20 AMThe PHP test can be used to show that the problem is evident, but it is not conclusive to prove ...
  • 多处理限制CPU使用

    千次阅读 2021-04-27 11:30:12
    所以这应该会限制我的CPU使用,对吧?我的意思是,按照我的理解,在第11行中设置的,进程/CPU的最大数量应该是[2, number_of_cpus / 10]的最大值。在 尽管如此,当我运行我的代码时,我发现在我启动后不久,所有的...
  • Kubernetes K8S之CPU和内存资源限制详解

    万次阅读 2021-01-04 21:37:07
    Kubernetes K8S之CPU和内存资源限制详解
  • 主要介绍了Python限制内存和CPU的使用量的方法,文中讲解非常细致,代码帮助大家更好的理解和学习,感兴趣的朋友可以了解下
  • 一、背景近日在客户系统运维中发现,有系统在定时脚本执行期间会将Linux系统CPU利用率跑满,导致其他服务受到影响,故查阅资料发现有大神写的CPU利用率限制程序。地址:CPU Usage Limiter for Linux根据此编写脚本,...
  • k8s(十)— 资源限制cpu、memory)

    千次阅读 2022-04-17 22:07:41
    1. k8s容器资源限制
  • iis7.0 cpu 限制

    2011-10-13 18:01:00
    iis中对cpu限制的操作: 限制:10000 (以百分比*1000计算,10000则表示10%) 限制操作:1、noaction 无操作 2、KillW3wp 删除进程 并在限制时间内重新开启新进程 限制间隔(分钟):设置时间限制,多久时间内...
  • CPU使用100%,可用此工具限制下!!可以使你完成当前工作,电脑反应更快
  • 第二个问题是厂家对该机型有CPU限制,因为供电设计的原因不建议使用45W以上的CPU,所以开机需要检查CPU支持列表,想升级的朋友有一定机率遇到unsupported cpu installed提示并自动关机的情况,这并不是微码的问题,...
  • 在之前的一篇文章中,我们已经解释了CPUTool,用于限制和控制 Linux中任何进程的CPU利用率 。 如果CPU /系统负载超出定义的阈值,它允许系统管理员中断进程(或进程组)的执行。 在这里,我们将学习如何使用类似的工具...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 461,670
精华内容 184,668
关键字:

cpu限制