溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“linux對CPU使用時間的限制是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“linux對CPU使用時間的限制是什么”吧!
對于某些 CPU 密集型的程序來說，不僅需要獲取更多的 CPU 使用時間，還要減少工作負載在節流時引起的上下文切換。現在的多核系統中每個核心都有自己的緩存，如果頻繁的調度進程在不同的核心上執行勢必會帶來緩存失效等開銷。那么有沒有方法針對 CPU 核心進行隔離呢？準確地說是把運行的進程綁定到指定的核心上運行。雖然對于操作系統來說，所有程序生而平等，但有些程序比其他程序更平等。
對于那些更平等的程序來說，我們需要為它分配更多的 CPU 資源，畢竟人都是很偏心的。廢話少說，我們來看看如何使用 cgroup 限制進程使用指定的 CPU 核心。
CPU 核心的編號一般是從 0 開始的，4 個核心的編號范圍是 0-3。我們可以通過查看 /proc/cpuinfo 的內容來確定 CPU 的某些信息：
$ cat /proc/cpuinfo ... processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU X5650 @ 2.67GHz stepping : 4 microcode : 0x1f cpu MHz : 2666.761 cache size : 12288 KB physical id : 6 siblings : 1 core id : 0 cpu cores : 1 apicid : 6 initial apicid : 6 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm ssbd ibrs ibpb stibp tsc_adjust arat spec_ctrl intel_stibp flush_l1d arch_capabilities bogomips : 5333.52 clflush size : 64 cache_alignment : 64 address sizes : 43 bits physical, 48 bits virtual
processor : 表示核心的編號，但這不是物理 CPU 的核心，更確切地可以稱之為**邏輯核編號。
physical id : 表示當前邏輯核所在的物理 CPU 的核心，也是從 0 開始編號，這里表示這個邏輯核在第 7 個 物理 CPU 上。
core id : 如果這個值大于 0，你就要注意了，你的服務器可能開啟了超線程。如果啟用了超線程，每個物理 CPU 核心會模擬出 2 個線程，也叫邏輯核（和上面的邏輯核是兩回事，只是名字相同而已）。如果你想確認服務器有沒有開啟超線程，可以通過下面的命令查看：
$ cat /proc/cpuinfo | grep -e "core id" -e "physical id" physical id : 0 core id : 0 physical id : 2 core id : 0 physical id : 4 core id : 0 physical id : 6 core id : 0
如果 physical id 和 core id 皆相同的 processor 出現了兩次，就可以斷定開啟了超線程。顯然我的服務器沒有開啟。
這里需要涉及到一個概念叫 NUMA（Non-uniform memory access），即非統一內存訪問架構。如果主機板上插有多塊 CPU，那么就是 NUMA 架構。每塊 CPU 獨占一塊面積，一般都有獨立風扇。
一個 NUMA 節點包含了直連在該區域的 CPU、內存等硬件設備，通信總線一般是 PCI-E。由此也引入了 CPU 親和性的概念，即 CPU 訪問同一個 NUMA 節點上的內存的速度大于訪問另一個節點的。
可以通過下面的命令查看本機的 NUMA 架構：
$ numactl --hardware available: 1 nodes (0) node 0 cpus: 0 1 2 3 node 0 size: 2047 MB node 0 free: 1335 MB node distances: node 0 0: 10
可以看出該服務器并沒有使用 NUMA 架構，總共只有一個 NUMA 節點，即只有一塊 CPU，4 個邏輯核心均在此 CPU 上。
Linux 最重要的職責之一就是調度進程，而進程只是程序運行過程的一種抽象，它會執行一系列指令，計算機會按照這些指令來完成實際工作。從硬件的角度來看，真正執行這些指令的是中央處理單元，即 CPU。默認情況下，進程調度器可能會將進程調度到任何一個 CPU 核心上，因為它要根據負載來均衡計算資源的分配。
為了增加實驗的明顯效果，可以隔離某些邏輯核心，讓系統默認情況下永遠不會使用這些核心，除非我指定某些進程使用這些核心。要想做到這一點，就要使用到內核參數 isolcpus 了，例如：如果想讓系統默認情況下不使用邏輯核心 2，3 和 4，可以將以下內容添加到內核參數列表中：
isolcpus=1,2,3 # 或者 isolcpus=1-3
對于 CnetOS 7 來說，可以直接修改 /etc/default/grub：
$ cat /etc/default/grub GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet isolcpus=1,2,3" GRUB_DISABLE_RECOVERY="true"
然后重新構建 grub.conf：
$ grub2-mkconfig -o /boot/grub2/grub.cfg
重啟系統之后，系統將不再使用邏輯核心 2，3 和 4，只會使用核心 1。找個程序把 CPU 跑滿（上篇文章用的程序），使用命令 top 查看 CPU 的使用狀況：
執行
top命令后，在列表頁按數字 1 鍵，就可以看到所有 CPU 了。
可以看到系統只使用了核心 1，下面我們來看看如何將程序綁到特定的 CPU 核心上。
將程序綁到指定的核心其實很簡單，只需設置好 cpuset 控制器就行了。 systemctl 可以管理受其控制資源的 cgroup 控制器，但只能管理有限的控制器（CPU、內存和 BlockIO），不能管理 cpuset 控制器。雖然 systemd 不支持 cpuset，但是相信以后會支持的，另外，現在有一個略顯笨拙，但是可以實現同樣的目標的方法，后面會介紹。
cgroup 相關的所有操作都是基于內核中的 cgroup virtual filesystem，使用 cgroup 很簡單，掛載這個文件系統就可以了。文件系統默認情況下都是掛載到 /sys/fs/cgroup 目錄下，查看一下這個目錄：
$ ll /sys/fs/cgroup 總用量 0 drwxr-xr-x 2 root root 0 3月 28 2020 blkio lrwxrwxrwx 1 root root 11 3月 28 2020 cpu -> cpu,cpuacct lrwxrwxrwx 1 root root 11 3月 28 2020 cpuacct -> cpu,cpuacct drwxr-xr-x 2 root root 0 3月 28 2020 cpu,cpuacct drwxr-xr-x 2 root root 0 3月 28 2020 cpuset drwxr-xr-x 4 root root 0 3月 28 2020 devices drwxr-xr-x 2 root root 0 3月 28 2020 freezer drwxr-xr-x 2 root root 0 3月 28 2020 hugetlb drwxr-xr-x 2 root root 0 3月 28 2020 memory lrwxrwxrwx 1 root root 16 3月 28 2020 net_cls -> net_cls,net_prio drwxr-xr-x 2 root root 0 3月 28 2020 net_cls,net_prio lrwxrwxrwx 1 root root 16 3月 28 2020 net_prio -> net_cls,net_prio drwxr-xr-x 2 root root 0 3月 28 2020 perf_event drwxr-xr-x 2 root root 0 3月 28 2020 pids drwxr-xr-x 4 root root 0 3月 28 2020 systemd
可以看到 cpuset 控制器已經默認被創建并掛載好了。看一下 cpuset 目錄下有什么：
$ ll /sys/fs/cgroup/cpuset 總用量 0 -rw-r--r-- 1 root root 0 3月 28 2020 cgroup.clone_children --w--w--w- 1 root root 0 3月 28 2020 cgroup.event_control -rw-r--r-- 1 root root 0 3月 28 2020 cgroup.procs -r--r--r-- 1 root root 0 3月 28 2020 cgroup.sane_behavior -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.cpu_exclusive -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.cpus -r--r--r-- 1 root root 0 3月 28 2020 cpuset.effective_cpus -r--r--r-- 1 root root 0 3月 28 2020 cpuset.effective_mems -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.mem_exclusive -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.mem_hardwall -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.memory_migrate -r--r--r-- 1 root root 0 3月 28 2020 cpuset.memory_pressure -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.memory_pressure_enabled -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.memory_spread_page -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.memory_spread_slab -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.mems -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.sched_load_balance -rw-r--r-- 1 root root 0 3月 28 2020 cpuset.sched_relax_domain_level -rw-r--r-- 1 root root 0 3月 28 2020 notify_on_release -rw-r--r-- 1 root root 0 3月 28 2020 release_agent -rw-r--r-- 1 root root 0 3月 28 2020 tasks
該目錄下只有默認的配置，沒有任何 cgroup 子系統。接下來我們來創建 cpuset 子系統并設置相應的綁核參數：
$ mkdir -p /sys/fs/cgroup/cpuset/test $ echo "3" > /sys/fs/cgroup/cpuset/test/cpuset.cpus $ echo "0" > /sys/fs/cgroup/cpuset/test/cpuset.mems
首先創建了一個 cpuset 子系統叫 test，然后將核心 4 綁到該子系統，即 cpu3。對于 cpuset.mems 參數而言，每個內存節點和 NUMA 節點一一對應。如果進程的內存需求量較大，可以把所有的 NUMA 節點都配置進去。這里就用到了 NUMA 的概念。出于性能的考慮，配置的邏輯核和內存節點一般屬于同一個 NUMA 節點，可用 numactl --hardware 命令獲知它們的映射關系。很顯然，我的主機沒有采用 NUMA 架構，只需將其設為節點 0 就好了。
查看 test 目錄：
$ cd /sys/fs/cgroup/cpuset/test $ ll 總用量 0 -rw-rw-r-- 1 root root 0 3月 28 17:07 cgroup.clone_children --w--w---- 1 root root 0 3月 28 17:07 cgroup.event_control -rw-rw-r-- 1 root root 0 3月 28 17:07 cgroup.procs -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.cpu_exclusive -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.cpus -r--r--r-- 1 root root 0 3月 28 17:07 cpuset.effective_cpus -r--r--r-- 1 root root 0 3月 28 17:07 cpuset.effective_mems -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.mem_exclusive -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.mem_hardwall -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.memory_migrate -r--r--r-- 1 root root 0 3月 28 17:07 cpuset.memory_pressure -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.memory_spread_page -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.memory_spread_slab -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.mems -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.sched_load_balance -rw-rw-r-- 1 root root 0 3月 28 17:07 cpuset.sched_relax_domain_level -rw-rw-r-- 1 root root 0 3月 28 17:07 notify_on_release -rw-rw-r-- 1 root root 0 3月 28 17:07 tasks $ cat cpuset.cpus 3 $ cat cpuset.mems 0
目前 tasks 文件是空的，也就是說，還沒有進程運行在該 cpuset 子系統上。需要想辦法讓指定的進程運行在該子系統上，有兩種方法：
將已經運行的進程的 PID 寫入 tasks 文件中；
使用 systemd 創建一個守護進程，將 cgroup 的設置寫入 service 文件中（本質上和方法 1 是一樣的）。
先來看看方法 1，首先運行一個程序：
$ nohup sha1sum /dev/zero & [1] 3767
然后將 PID 寫入 test 目錄的 tasks 中：
$ echo "3767" > /sys/fs/cgroup/cpuset/test/tasks
查看 CPU 使用情況：
可以看到綁核生效了，PID 為 3767 的進程被調度到了 cpu3 上。
下面再來看看方法 2，雖然目前 systemd 不支持使用 cpuset 去指定一個 Service 的 CPU，但我們還是有一個變相的方法，Service 文件內容如下：
$ cat /etc/systemd/system/foo.service [Unit] Description=foo After=syslog.target network.target auditd.service [Service] ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/cpuset/testset ExecStartPre=/bin/bash -c '/usr/bin/echo "2" > /sys/fs/cgroup/cpuset/testset/cpuset.cpus' ExecStartPre=/bin/bash -c '/usr/bin/echo "0" > /sys/fs/cgroup/cpuset/testset/cpuset.mems' ExecStart=/bin/bash -c "/usr/bin/sha1sum /dev/zero" ExecStartPost=/bin/bash -c '/usr/bin/echo $MAINPID > /sys/fs/cgroup/cpuset/testset/tasks' ExecStopPost=/usr/bin/rmdir /sys/fs/cgroup/cpuset/testset Restart=on-failure [Install] WantedBy=multi-user.target
啟動該服務，然后查看 CPU 使用情況：
該服務中的進程確實被調度到了 cpu2 上。
最后我們回到 Docker，Docker 實際上就是將系統底層實現的 cgroup 、 namespace 等技術集成在一個使用鏡像方式發布的工具中，于是形成了 Docker，這個想必大家都知道了，我就不展開了。對于 Docker 來說，有沒有辦法讓容器始終在一個或某幾個 CPU 上運行呢？其實還是很簡單的，只需要利用 --cpuset-cpus 參數就可以做到！
下面就來演示一下，指定運行容器的 CPU 核心編號為 1：
???? → docker run -d --name stress --cpuset-cpus="1" progrium/stress -c 4
查看主機 CPU 的負載：
只有 Cpu1 達到了 100%，其它的 CPU 并未被容器使用。
如果你看過該系列的第一篇文章，應該知道，在新的使用 systemd 實現 init 的系統中（比如 ConetOS 7），系統默認創建了 3 個頂級 slice：System, User 和 Machine，其中 machine.slice 是所有虛擬機和 Linux 容器的默認位置，而 Docker 其實是 machine.slice 的一個變種，你可以把它當成 machine.slice 。
如果系統中運行的是 Kubernetes，machine.slice 就變成了 kubepods：
為了便于管理 cgroup，systemd 會為每一個 slice 創建一個子系統，比如 docker 子系統：
然后再根據容器的設置，將其放入相應的控制器下面，這里我們關心的是 cpuset 控制器，看看它的目錄下有啥：
查看 docker 目錄：
可以看到 Docker 為每個容器創建了一個子目錄，7766.. 對應的就是之前我們創建的容器：
???? → docker ps|grep stress 7766580dd0d7 progrium/stress "/usr/bin/stress --v…" 36 minutes ago Up 36 minutes stress
我們來檢驗一下該目錄下的配置：
$ cd /sys/fs/cgroup/cpuset/docker/7766580dd0d7d9728f3b603ed470b04d0cac1dd923f7a142fec614b12a4ba3be $ cat cpuset.cpus 1 $ cat cpuset.mems 0 $ cat tasks 6536 6562 6563 6564 6565 $ ps -ef|grep stress root 6536 6520 0 10:08 ? 00:00:00 /usr/bin/stress --verbose -c 4 root 6562 6536 24 10:08 ? 00:09:50 /usr/bin/stress --verbose -c 4 root 6563 6536 24 10:08 ? 00:09:50 /usr/bin/stress --verbose -c 4 root 6564 6536 24 10:08 ? 00:09:50 /usr/bin/stress --verbose -c 4 root 6565 6536 24 10:08 ? 00:09:50 /usr/bin/stress --verbose -c 4
到此，相信大家對“linux對CPU使用時間的限制是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
