Linux Cgroup 入門教程:cpuset
這是 Cgroup 系列的第四篇,往期回顧:
Linux Cgroup 入門教程:基本概念
Linux Cgroup 入門教程:CPU
Linux Cgroup 入門教程:記憶體
通過上篇文章的學習,我們學會了如何檢視目前 cgroup 的資訊,如何通過操作 /sys/fs/cgroup 目錄來動态設定 cgroup,也學會了如何設定 CPU shares 和 CPU quota 來控制 slice 内部以及不同 slice 之間的 CPU 使用時間。本文将繼續探讨對 CPU 使用時間的限制。
對于某些 CPU 密集型的程式來說,不僅需要擷取更多的 CPU 使用時間,還要減少工作負載在節流時引起的上下文切換。現在的多核系統中每個核心都有自己的緩存,如果頻繁的排程程序在不同的核心上執行勢必會帶來緩存失效等開銷。那麼有沒有方法針對 CPU 核心進行隔離呢?準确地說是把運作的程序綁定到指定的核心上運作。雖然對于作業系統來說,所有程式生而平等,但有些程式比其他程式更平等。
對于那些更平等的程式來說,我們需要為它配置設定更多的 CPU 資源,畢竟人都是很偏心的。廢話少說,我們來看看如何使用 cgroup 限制程序使用指定的 CPU 核心。
-
檢視 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
physical id : 2
physical id : 4
如果 physical id 和 core id 皆相同的 processor 出現了兩次,就可以斷定開啟了超線程。顯然我的伺服器沒有開啟。
-
NUMA 架構
這裡需要涉及到一個概念叫 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 上。
-
isolcpus
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 核心上。
-
建立 cgroup
将程式綁到指定的核心其實很簡單,隻需設定好 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
-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
-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
目前 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,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
1
$ 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
當然,你也可以将容器綁到多個 CPU 核心上運作,這裡我就不贅述了。下篇文章将會介紹如何通過 cgroup 來限制 BlockIO。
原文位址
https://www.cnblogs.com/ryanyangcs/p/12604382.html