給大家分享一個事情。背景是這樣的，我們要測試某個第三方 SDK 運(yùn)行性能，這是個 CPU 密集型的服務(wù)。我想評估一下它運(yùn)行一遍到底有多吃 CPU，以便評估上線后我們需要部署多少臺服務(wù)器。

我們是在一臺 16 物理核的機(jī)器上測試的，我們的想法是把它啟動起來，然后執(zhí)行一遍。用耗時乘以 16 核那就是總的 CPU 耗時開銷。不過不巧的是我們發(fā)現(xiàn)這個貨在并發(fā)上做的并不是特別好，運(yùn)行的前半段里只能打滿一個核，而后半段可以把整臺機(jī)器上所有 16 核都打滿。這樣就沒法準(zhǔn)確估算它的 CPU 消耗了。

最先我想到的方案是將這個 SDK 進(jìn)行 numa 綁定。但是 nuam 綁定只能將 cpu 限制在一個 node 上，我的機(jī)器上 一個 node 里有 8 個核。問題仍然存在，還是不能精確控制 cpu 的用量。

所以我接著又想到了 cgroup 。假如我能從始至終都限制這個 SDK 只使用一個核，且把一個核全部打滿，這樣我就能準(zhǔn)確地評估它的 CPU 耗時。

說干就干。Cgroup 這玩意兒聽起來復(fù)雜，沒想到用起來那是超級的簡單。首先我找到了 cpu,cpuacct 這個 group。在它下面創(chuàng)建一個子 group，一行 mkdir 就能搞定。

# cd /sys/fs/cgroup/cpu,cpuacct
# mkdir test
# cd test

這時候 cgroup 已經(jīng)在 test 這個目錄下幫我們創(chuàng)建好了一些文件，通過修改這些文件可以控制進(jìn)程的 CPU 消耗的。

# ls -l
total 0
-rw-r--r-- 1 root root 0 Sep 23 11:38 cgroup.procs
-rw-r--r-- 1 root root 0 Sep 23 11:37 cpu.cfs_period_us
-rw-r--r-- 1 root root 0 Sep 23 11:37 cpu.cfs_quota_us
......

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【891587639】整理了一些個人覺得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實戰(zhàn)項目及代碼)? ??

為了簡便，我們只關(guān)注上面幾個文件。其中 cfs_period_us 用來配置時間周期長度，cfs_quota_us ?用來配置當(dāng)前 cgroup 在設(shè)置的周期長度內(nèi)所能使用的 CPU 時間。這兩個文件配合起來就可以設(shè)置 CPU 的使用上限。

比如我想控制我的進(jìn)程最多只能使用 1 個核，那么就這樣。

# echo 500000 > cpu.cfs_quota_us // 500ms 
# echo 500000 > cpu.cfs_period_us // 500ms 

每 500ms 能使用 500ms的 CPU 時間，即將 cpu 使用限制在 1 個核以內(nèi)。（如果想要限制只用兩個核，那就把 cpu.cfs_quota_us 改成 1000000 即可）

這個時候，還缺關(guān)鍵的一步。把要限制的進(jìn)程加進(jìn)來。這個也簡單，修改 cgroup.procs 把要限制的進(jìn)程 pid 添加進(jìn)去就行了。

這里有個細(xì)節(jié)，那就是加入一個進(jìn)程后，這個進(jìn)程創(chuàng)建的子進(jìn)程都將默認(rèn)加到這個 cgroup 的限制中。雖然我們不知道我們將要啟動的進(jìn)程的 pid 是多少，但是我們可以查到當(dāng)前 bash 進(jìn)程的 pid，只要把它加進(jìn)來就行了。這樣后面通過控制臺啟動進(jìn)程的時候，都將自動進(jìn)入 cgroup 限制中。

# echo $$
16403
sh -c "echo 16403 > cgroup.procs"

這個時候我們使用一個簡單的工具 ，stress。用它來模擬開篇 sdk 的 cpu 密集型工作。通過 -c 指定開啟幾個進(jìn)程，然后每個進(jìn)程都反復(fù)不停的計算隨機(jī)數(shù)的平方根，盡最大努力消耗 cpu。

# stress -c 4

另外啟動一個控制臺，觀察 cpu 消耗。發(fā)現(xiàn)總量確實是控制住了。stress 及其子進(jìn)程加起來都只使用了 1 核。

不過我發(fā)現(xiàn)了一個不滿意的地方。雖然 cpu 用量是控制住了，但是 cpu 消耗是分散在各個 cpu 核上的，而且還是飄來飄去的。我想要的效果是限制它在某一個核上運(yùn)行。

回來查看了一下 cgroup 目錄下的文件。猛然看到了一個叫 cpuset 的 group。第六感告訴我，它一定可以！

# ll /sys/fs/cgroup/
total 0
drwxr-xr-x 2 root root ?0 Sep 15 17:43 blkio
lrwxrwxrwx 1 root root 11 Sep 15 17:43 cpu -> cpu,cpuacct
lrwxrwxrwx 1 root root 11 Sep 15 17:43 cpuacct -> cpu,cpuacct
drwxr-xr-x 4 root root ?0 Sep 15 17:43 cpu,cpuacct
drwxr-xr-x 3 root root ?0 Sep 15 17:43 cpuset ?// 就是它！
......

于是乎，我先是廢棄了剛剛的 test 配置，直接刪除即可（rm -rf /sys/fs/cgroup/cpu,cpuacct）。再我搜了一下這個 cpuset 怎么用，開始新的配置。

# cd /sys/fs/cgroup/cpuset
# mkdir test && cd test
# echo "0" > cpuset.cpus //限制在第 0 號核上
# echo 0 > cpuset.mems
# echo $$ > cgroup.procs

繼續(xù)開始施加 cpu 壓力。

# stress -c 4

在另外一個控制臺上查看效果。

完美！這次不但將 cpu 用量控制在了一個核，而且也將 CPU 消耗牢牢地釘在了 cpu0 上。這就是我想要的效果！

基于這個方法，我們就非常準(zhǔn)確地完成了對那個第三方 sdk 的 cpu 消耗用量的測試。也評估出來未來上線后需要幾臺服務(wù)器。