Cgroup限制CPU、IO、內存以及linux系統中的調度方法

這篇文章主要講解了“Cgroup限制CPU、IO、內存以及linux系統中的調度方法”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Cgroup限制CPU、IO、內存以及linux系統中的調度方法”吧！

一、CPU
1、0核利用
思路： 0核是必須要保護的，否則各種系統命令、喂狗都可能出問題；
       設想是把某個實例，比如SD，綁定到0核，并通過cgroup功能限制CPU負載，比如最多使用80%的0核CPU；
問題： cgroup被裁掉了，需要安裝； 需要分析和測試cgroup是否會影響調度順序；

2、其它核
思路：其它實例，綁定到除0核和dpdk核之外的所有核，也就是允許在這些核上遷移，由操作系統調度；
問題：按照以前的經驗，操作系統調度進行核遷移是不會很快的，在高負載的時候容易瞬間CPU沖頂導致呼損；
          
v4用法：
service cgconfig start     #開啟cgroups服務
chkconfig cgconfig on    #開啟啟動

v5用法
systemctl start  cgconfig.service
systemctl enable cgconfig.service
systemctl is-enable cgconfig.service

v5系統安裝cgroup，安裝libcgroup-0.41-13.el7.x86_64.rpm //v5系統已經安裝
                                        libcgroup-devel-0.41-13.el7.x86_64.rpm
                                        libcgroup-tools-0.41-13.el7.x86_64.rpm
                      
https://segmentfault.com/a/1190000008323952

cgroup.procs：只讀文件，顯示當前cgroup下的所有進程

CFS完全公平調度策略
cpu.cfs_period_us：用來配置時間周期長度，單位是us，取值范圍1000~1000000：1ms ~ 1s
cpu.cfs_quota_us：用來配置當前cgroup在設置的周期長度內所能使用的CPU時間數，單位us，最小值為1000：1ms； t > 1000
tasks中所有任務總CPU占用率 = cpu.cfs_quota_us/cpu.cfs_period_us
只有這兩個文件同時有效，表示cfs限制開啟，此時才能將cfs調度策略的進程寫進tasks中，否則參數無效echo: write error: Invalid argument

RT實時調度策略
cpu.rt_period_us ：統計CPU使用時間的周期，單位us，最小值為1 ，t > 1
cpu.rt_runtime_us：周期內允許任務使用單個CPU核的時間，如果系統中有多個核，則可以使用核倍數的時間，單位us，最小值為0
tasks中所有任務總CPU占用率 = cpu.rt_runtime_us*CPU核數 / cpu.rt_period_us
只有這兩個文件同時有效，表示rt限制開啟，此時才能將rt調度策略的進程寫進tasks中，

如果同時配置RT和CFS有效，A（RT類型線程總和）、B（CFS類型線程總和）兩者分別工作，
對tasks中的對應的線程屬性進行限制
假設RT和CFS均設置CPU占用率為80%，那么A、B均占用80%，
兩者加起來即160%，如果tasks中的線程共核，那么: A + B = 100%
至于A、B的具體值，由于A為RT調度優先搶占CPU，通常是A=80%，B=20%

兩種調度策略均通過配置cgconfig.conf生效

cpu.shares
cpu.stat
notify_on_release
release_agent
tasks

-rw-r--r-- 1 root root 0 Aug 12 17:09 cpu.cfs_period_us
-rw-r--r-- 1 root root 0 Aug 12 17:09 cpu.cfs_quota_us
-rw-r--r-- 1 root root 0 Aug 12 17:09 cpu.rt_period_us
-rw-r--r-- 1 root root 0 Aug 12 17:09 cpu.rt_runtime_us

v4環境：
service sbcd restart ===不要存在/cgroup/cpu/路徑否則service cgconfig restart失敗導致單板重啟

v5環境：
當系統

遺留問題：
1、如何配置cgroup，v5系統設置開機啟動，無法正常啟動
答：已經解決，修改cgconfig.conf需要重啟單板一次才能生效

2、實時調度的cpu.rt_period_us 、cpu.rt_runtime_us參數粒度選??；
   粒度太大，直觀感覺占用cpu過大，系統命令響應變慢
答：寫一個測試程序（兩種調度方式），
    a、觀察在不同粒度下執行相同操作（1w、10w、100w次循環）所需時間
    b、觀察程序的調度次數
     
4、調度方式發生改變
   背景：發現會修改SD下線程的調度方式 5號（mspe），9號（mpe）機均出現
         Q1:sbc中線程的調度策略,有什么決定
   原因：sd繼承shell進程，將任務默認寫進/sys/fs/cgroup/cpu/user.slice
              user.slice分組中rt=0，導致SD中設置線程調度屬性失?。╯ched_setscheduler接口返回 -1）
   解決方法：1、裁剪或訂制user.slice、system.slice，經試驗user.slice.rt + system.slice.rt < 90%可行
                          進一步論證：user.slice.rt + system.slice.rt +test.rt < 100
                     2、在代碼中實現，先進行寫文件設置，后進行調度屬性設置，實驗可行

5、通過配置cgconfig.conf ，/cgconfig.d/test.conf，可以解決調度策略發生改變問題
   Q1：systemctl restart cgconfig.service 命令失敗

測試問題收尾：

1、實時調度的cpu.rt_period_us 、cpu.rt_runtime_us參數粒度選??；
   粒度太大，直觀感覺占用cpu過大，系統命令響應變慢
解決方案:寫一個測試程序（cfs調度，系統命令也cfs調度方式）
         1、觀察程序的調度次數
sbc占用80%,linux_endless占用20%

粒度小cpu.rt_period_us=100000 cpu.rt_runtime_us=20000        
粒度大cpu.rt_period_us=1000000 cpu.rt_runtime_us=200000

相同時間：
粒度大sbc調用次數 > 粒度小sbc調用次數
粒度大linux_endless調用次數 < 粒度小linux_endless調用次數

因此，選擇粒度小的cpu參數，要優先保證操作系統調度
#總核數 = 物理CPU個數 * 每個物理CPU的核數
#總邏輯CPU數 = 總核數 * 超線程數

 #查看物理CPU個數
 cat /proc/cpuinfo | grep "physical id" |sort | uniq |wc -l
 
 #查看每個物理CPU中的core的個數
 cat /proc/cpuinfo | grep "cpu cores" | uniq
 
 #查看邏輯CPU個數
 cat /proc/cpuinfo | grep "processor" | wc -l
 
 #查看超線程是否打開判斷
  cat /proc/cpuinfo | grep "sibling" | uniq ，cat /proc/cpuinfo | grep "cpu cores" | uniq
  如果"siblings"和"cpu cores"一致，則說明不支持超線程，或者超線程未打開；
  如果"siblings"是"cpu cores"的兩倍，則說明支持超線程，并且超線程已打開

 #查看CPU是32還是64位運行模式
  getconf LONG_BIT 
  執行結果：64 
  注意：如果結果是32，代表是運行在32位模式下，但不代表CPU不支持64bit。4.CPU是32還是64位運行模式

注意：如果結果是32，代表是運行在32位模式下，但不代表CPU不支持64bit。
 一般情況：邏輯CPU的個數 = 物理CPU個數 * 每個cpu的核數。如果不相等的話，則表示服務器的CPU支持超線程技術

1、物理CPU：實際Server中插槽上的CPU個數
物理cpu數量，可以數不重復的 physical id 有幾個：cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l

2、cpu核數：一塊CPU上面能處理數據的芯片組的數量、比如現在的i5 760,是雙核心四線程的CPU、而 i5 2250 是四核心四線程的CPU
   cpu核數查看方法：cat /proc/cpuinfo | grep "cpu cores" | uniq

3、邏輯CPU：/proc/cpuinfo 這個文件是用來存儲cpu硬件信息的（信息內容分別列出了processor 0 – n 的規格。而這里的n是邏輯cpu數量）
  一個cpu可以有多核，加上intel的超線程技術(HT), 可以在邏輯上再分一倍數量的cpu core出來，所以：
   cat /proc/cpuinfo| grep "processor"| wc -l
   邏輯CPU數量 = 物理cpu數量 * cpu cores 這個規格值 * 2(如果支持并開啟ht)  
   注意：Linux下top查看的CPU也是邏輯CPU個數
   

查看每個邏輯cpu當前的占用率 top ,然后按下數字 1；
top -H -p xxxx //看xxx進程下的線程CPU占用率
perf top -Cx // 看具體函數的在CPUx占用率
綁定進程到CPU核上：taskset -cp  cpu_id pid
查看進程位于哪個cpu核上：taskset -p pid
查看進程的調度策略：ps -eo class,cmd 
                      TS  SCHED_OTHER
                      FF  SCHED_FIFO
                      RR  SCHED_RR
                      B   SCHED_BATCH
                      ISO SCHED_ISO
            
            
systemctl list-unit-files | grep enabled //v5系統執行服務命令systemctl
查看掛載cgroup
lssubsys -am

手工掛載cpu
mount -t cgroup -o cpu,cpuacct cpu /cgroup/cpu

[root@localhost cgroup]# systemctl status cgconfig.service
● cgconfig.service - Control Group configuration service
   Loaded: loaded (/usr/lib/systemd/system/cgconfig.service; disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2018-08-09 10:22:51 UTC; 19min ago
  Process: 4076 ExecStart=/usr/sbin/cgconfigparser -l /etc/cgconfig.conf -L /etc/cgconfig.d -s 1664 (code=exited, status=101)
 Main PID: 4076 (code=exited, status=101)
Aug 09 10:22:51 localhost.localdomain systemd[1]: Starting Control Group configuration service...
Aug 09 10:22:51 localhost.localdomain cgconfigparser[4076]: /usr/sbin/cgconfigparser; error loading /etc/cgconfig.conf: Cgroup mounting failed
Aug 09 10:22:51 localhost.localdomain systemd[1]: cgconfig.service: main process exited, code=exited, status=101/n/a
Aug 09 10:22:51 localhost.localdomain cgconfigparser[4076]: Error: cannot mount cpu,cpuacct to /cgroup/cpu: Device or resource busy
Aug 09 10:22:51 localhost.localdomain systemd[1]: Failed to start Control Group configuration service.
Aug 09 10:22:51 localhost.localdomain systemd[1]: Unit cgconfig.service entered failed state.
Aug 09 10:22:51 localhost.localdomain systemd[1]: cgconfig.service failed.
[root@localhost cgroup]# cgclear

ps -ef | grep sleep  # 找出 sleep 1000 的pid, 這里假設是 1234
chrt -p 1234         # 可以查看 pid=1234 的進程的 調度策略, 輸入如下:
      pid 1234's current scheduling policy: SCHED_OTHER
      pid 1234's current scheduling priority: 0
chrt -p -f 10 1234   # 修改調度策略為 SCHED_FIFO, 并且優先級為10
chrt -p 1234         # 再次查看調度策略
      pid 1234's current scheduling policy: SCHED_FIFO
      pid 1234's current scheduling priority: 10
      
chrt -p -r 10 4572  # 修改調度策略為 SCHED_RR, 并且優先級為10
chrt -p  4572
pid 4572's current scheduling policy: SCHED_RR
pid 4572 的當前調度優先級：10
      
chrt -p -o 0  1234 在修改為SCHED_OTHER      

輸入chrt 列出可選參數

獲取系統實時進程調度配置
sysctl -n kernel.sched_rt_period_us  #實時進程調度的單位CPU時間 1 秒
sysctl -n kernel.sched_rt_runtime_us #實時進程在 1 秒中實際占用的CPU時間, 0.95秒

設置實時進程占用CPU時間

上面的默認設置中, 實時進程占用 95% 的CPU時間. 如果覺得占用的太多或太少, 都是可以調整的.比如:
sysctl -w kernel.sched_rt_runtime_us=900000    # 設置實時進程每1秒中只占0.9秒的CPU時間
kernel.sched_rt_runtime_us = 900000
sysctl -n kernel.sched_rt_runtime_us 
900000
 
cgroup 中的設置
整體設置是針對整個系統的, 我們也可以通過 cgroup 來對一組進程的CPU資源進行控制.
如果想在 cgroup 中對 sched_rt_period_us 和 sched_rt_runtime_us 進行控制, 需要內核編譯選項 CONFIG_RT_GROUP_SCHED=y

cat /boot/config-`uname -r`
查看 CONFIG_RT_GROUP_SCHED 是否啟用

/*其他模塊*/

1、blkio模塊、相關參數及其含義：

1.1. 權重比例

blkio.weight
設定默認使用的權重比例，取值范圍：100—1000。此值會被blkio.weight_device值覆蓋。
echo 500 > blkio.weight

blkio.weight_device
設定指定設備的使用的權重比例，取值范圍：100—1000。此值會覆蓋blkio.weight設定值。該值的格式為：major:minor weight，即，主設備號：次設備號 權重。例如：設定硬盤sda的訪問權重為500.

ps：
# ll /dev/sda
brw-rw---- 1 root disk 8, 0 Aug 15 15:42 /dev/sda
主設備號為8，次設備號為0.
echo 8:0 500 > blkio.weight_device //測試發現此設備填非0，寫失敗

echo 3 > /proc/sys/vm/drop_caches //清文件系統緩存，很重要，否則可能看到io的讀取速率為0

cgexec -g "blkio:test1" dd bs=1M count=4096 if=file1 of=/dev/null

cgexec -g "blkio:test2" dd bs=1M count=4096 if=file2 of=/dev/null //注意：讀取設備不能相同，否則無法看見速率差異

1.2. I/O 使用上限

blkio.throttle.read_bps_device / blkio.throttle.write_bps_device
指定 cgroup 中某設備每秒鐘讀/寫數據的字節上限。其格式為 major:minor bytes_per_second。

blkio.throttle.read_iops_device / blkio.throttle.write_iops_device
指定 cgroup 中某設備每秒鐘可以執行的讀/寫請求數上限。其格式為major:minor operations_per_second。

測試：

1、echo '8:0 1000000' > blkio.throttle.read_bps_device  //設置分組讀取數據為1M/s

2、echo 3 > /proc/sys/vm/drop_caches //清文件系統緩存，很重要

3、dd if=/dev/sda of=/dev/null &

4、iotop -p  cmd2_pid //查看進程讀取磁盤速率

5、將cmd2_pid加入task分組查看速率變化

//C代碼只需要調用系統接口read讀取磁盤設備即可

1.3. 統計參數
        blkio.reset_stats：向該文件中寫入一個整數，可以重置該 cgroup 中的統計計數。
        blkio.time          ：統計 cgroup 對具體設備的 I/O 訪問時間。單位為毫秒(ms)
        blkio.sectors      ：統計 cgroup 對具體設備的扇區讀寫數。

blkio.io_serviced：統計 cgroup 對具體設備的讀寫操作數。內容有四個字段：major, minor,operation (read, write, sync, or async)和 number（表示操作的次數）。

blkio.io_service_bytes：統計 cgroup對具體設備的讀寫字節數。內容有四個字段：major, minor, operation (read, write, sync, or async)和 bytes（表示傳輸的字節數）。

blkio.io_service_time：統計 cgroup 對指定設備的 I/O 操作發送請求和完成請求之間的時間。條目有四個字段：major, minor, operation 和 time，其中 time 的單位為納秒(ns)。

blkio.io_wait_time：統計 cgroup 對具體設備的 I/O 操作在隊列調度中等待的時間。內容有四個字段：major,minor, operation 和 time，其中 time 的單位為納秒(ns)，這意味著對于ssd硬盤也是有意義的。

blkio.io_merged：統計 cgroup 將 BIOS 請求合并到 I/O 操作請求的次數。內容有兩個字段：number和 operation。

blkio.io_queued：統計I/O 操作排隊的請求數。內容有兩個字段：number 和 operation(read, write, sync, or async)。

blkio.throttle.io_serviced：統計 cgroup 對具體設備的讀寫操作數。blkio.io_serviced 與blkio.throttle.io_serviced的不同之處在于，CFQ 調度請求隊列時，前者不會更新。
內容有四個字段：(read, write, sync, or async)和 number（表示操作的次數）。

blkio.throttle.io_service_bytes：統計 cgroup對具體設備的讀寫字節數。blkio.io_service_bytes 與blkio.throttle.io_service_bytes 的不同之處在于，CFQ 調度請求隊列時，前者不會更新。內容有四個字段：(read, write, sync, or async)和 bytes（表示傳輸的字節數）。

2、memory模塊、相關參數及其含義：
 2.1、參數概要：
cgroup.event_control #用于eventfd的接口
memory.usage_in_bytes #顯示當前已用的內存
memory.limit_in_bytes #設置/顯示當前限制的內存額度
memory.failcnt #顯示內存使用量達到限制值的次數
memory.max_usage_in_bytes #歷史內存最大使用量
memory.soft_limit_in_bytes #設置/顯示當前限制的內存軟額度
memory.stat #顯示當前cgroup的內存使用情況
memory.use_hierarchy #設置/顯示是否將子cgroup的內存使用情況統計到當前cgroup里面
memory.force_empty #觸發系統立即盡可能的回收當前cgroup中可以回收的內存
memory.pressure_level #設置內存壓力的通知事件，配合cgroup.event_control一起使用
memory.swappiness #設置和顯示當前的swappiness
memory.move_charge_at_immigrate #設置當進程移動到其他cgroup中時，它所占用的內存是否也隨著移動過去
memory.oom_control #設置/顯示oom controls相關的配置
memory.numa_stat #顯示numa相關的內存

2.2、屬性限制

memory.force_empty ：當向memory.force_empty文件寫入0時（echo 0 > memory.force_empty），將會立即觸發系統盡可能的回收該cgroup占用的內存。該功能主要使用場景是移除cgroup前（cgroup中沒有進程），先執行該命令，可以盡可能的回收該cgropu占用的內存，這樣遷移內存的占用數據到父cgroup或者root cgroup時會快些。

memory.swappiness ：該文件的值默認和全局的swappiness（/proc/sys/vm/swappiness）一樣，修改該文件只對當前cgroup生效，其功能和全局的swappiness一樣

有一點和全局的swappiness不同，那就是如果這個文件被設置成0，就算系統配置的有交換空間，當前cgroup也不會使用交換空間。

memory.use_hierarchy:該文件內容為0時，表示不使用繼承，即父子cgroup之間沒有關系；當該文件內容為1時，子cgroup所占用的內存會統計到所有祖先cgroup中。

如果該文件內容為1，當一個cgroup內存吃緊時，會觸發系統回收它以及它所有子孫cgroup的內存。
注意: 當該cgroup下面有子cgroup或者父cgroup已經將該文件設置成了1，那么當前cgroup中的該文件就不能被修改。

memory.soft_limit_in_bytes:有了hard limit（memory.limit_in_bytes），為什么還要soft limit呢？hard limit是一個硬性標準，絕對不能超過這個值，而soft limit可以被超越，既然能被超越，要這個配置還有啥用？先看看它的特點當系統內存充裕時，soft limit不起任何作用當系統內存吃緊時，系統會盡量的將cgroup的內存限制在soft limit值之下（內核會盡量，但不100%保證）

從它的特點可以看出，它的作用主要發生在系統內存吃緊時，如果沒有soft limit，那么所有的cgroup一起競爭內存資源，占用內存多的cgroup不會讓著內存占用少的cgroup，這樣就會出現某些cgroup內存饑餓的情況。如果配置了soft limit，那么當系統內存吃緊時，系統會讓超過soft limit的cgroup釋放出超過soft limit的那部分內存（有可能更多），這樣其它cgroup就有了更多的機會分配到內存。所以，這其實是系統內存不足時的一種妥協機制，給次等重要的進程設置soft limit，當系統內存吃緊時，把機會讓給其它重要的進程。

注意： 當系統內存吃緊且cgroup達到soft limit時，系統為了把當前cgroup的內存使用量控制在soft limit下，在收到當前cgroup新的內存分配請求時，就會觸發回收內存操作，所以一旦到達這個狀態，就會頻繁的觸發對當前cgroup的內存回收操作，會嚴重影響當前cgroup的性能。

memory.oom_control：內存超限之后的 oom 行為控制。

        查看oom killer設置，不能用vi編輯，只能用echo，但是根路徑下的memory.oom_control無法設置

[root@localhost test]# echo 1 > memory.oom_control
[root@localhost test]# cat memory.oom_control
oom_kill_disable 1
under_oom 0 //只讀字段

 
       關閉oom killer：

設置 oom_kill_disable 為 1。（0 為開啟）當觸發oom時，但是開關關閉時，對應的線程仍然無法調度，出現D狀態

cgroup.event_control：實現OOM的通知，當OOM發生時，可以收到相關的事件

 memory.move_charge_at_immigrate：當一個進程從一個cgroup移動到另一個cgroup時，默認情況下，該進程已經占用的內存還是統計在原來的cgroup里面，不會占用新cgroup的配額，但新分配的內存會統計到新的cgroup中（包括swap out到交換空間后再swap in到物理內存中的部分）。我們可以通過設置memory.move_charge_at_immigrate讓進程所占用的內存隨著進程的遷移一起遷移到新的cgroup中。

方法：

enable： echo 1 > memory.move_charge_at_immigrate

disable：echo 0 > memory.move_charge_at_immigrate
注意: a、就算設置為1，但如果不是thread group的leader，這個task占用的內存也不能被遷移過去。換句話說，如果以線程為單位進行遷移，必須是進程的第一個線程，如果以進程為單位進行                  遷移，就沒有這個問題。
               當memory.move_charge_at_immigrate為0時，就算當前cgroup中里面的進程都已經移動到其它cgropu中去了，由于進程已經占用的內存沒有被統計過去，當前cgroup有可能還占用很                多內存，當移除該cgroup時，占用的內存需要統計到誰頭上呢？答案是依賴memory.use_hierarchy的值，如果該值為0，將會統計到root cgroup里；如果值為1，將統計到它的父cgroup               里面。

b、當前進程分組時，如果進程使用的內存(memory.usage_in_bytes)大于目標分組的內存限制（memory.limit_in_bytes），則遷移失敗

[root@localhost memory]# echo 5750 > test_1/tasks
[root@localhost memory]# cat test_1/memory.usage_in_bytes
106496
[root@localhost memory]# cat test_2/memory.usage_in_bytes
0
[root@localhost memory]# cd test_2
[root@localhost test_2]# cat memory.limit_in_bytes
9223372036854771712
[root@localhost test_2]# echo 10240 > memory.limit_in_bytes
[root@localhost test_2]# echo 5750 > tasks
-bash: echo: 寫錯誤: 無法分配內存
[root@localhost test_2]# echo 1024000 > memory.limit_in_bytes
[root@localhost test_2]# echo 5750 > tasks
[root@localhost test_2]# cat memory.usage_in_bytes
106496

c、當進程正在申請內存時，遷移分組，已經申請內存統計不會遷移

2.3、內存限制

memory.memsw.limit_in_bytes：內存＋swap空間使用的總量限制。
memory.limit_in_bytes：內存使用量限制。

memory.memsw.limit_in_bytes 必須大于或等于 memory.limit_in_byte。
要解除內存限制，把對應的值設為 -1 即可。

這種方式限制進程內存占用會有個風險。當進程試圖占用的內存超過限制時，會觸發 oom ，導致進程直接被殺，從而造成可用性問題。即使關閉控制組的 oom killer，在內存不足時，進程雖然不會被殺，但是會長時間進入 D 狀態（等待系統調用的不可中斷休眠），并被放到 OOM-waitqueue 等待隊列中， 仍然導致服務不可用。因此，用 memory.limit_in_bytes 或 memory.memsw.limit_in_bytes 限制進程內存占用僅應當作為一個保險，避免在進程異常時耗盡系統資源。如，預期一組進程最多會消耗 1G 內存，那么可以設置為 1.5G 。這樣在發生內存泄露等異常情況時，可以避免造成更嚴重問題。

注意：如果當前分組下已經存在task任務，修改memory.limit_in_bytes的值必須大于memory.usage_in_bytes的值，否則修改失敗

[root@localhost test_2]# cat memory.usage_in_bytes
106496
[root@localhost test_2]# echo 106494 > memory.limit_in_bytes
-bash: echo: 寫錯誤: 設備或資源忙
[root@localhost test_2]# echo 106498 > memory.limit_in_bytes
[root@localhost test_2]# cat memory.limit_in_bytes
106496 //數值不一定精確寫入
[root@localhost test_2]#

2.4、內存資源審計

memory.memsw.usage_in_bytes:當前 cgroup 的內存＋ swap 的使用量。

memory.usage_in_bytes:當前 cgroup 的內存使用量。

memory.max_usage_in_bytes:cgroup 最大的內存＋ swap 的使用量。

memory.memsw.max_usage_in_bytes:cgroup 的最大內存使用量。

感謝各位的閱讀，以上就是“Cgroup限制CPU、IO、內存以及linux系統中的調度方法”的內容了，經過本文的學習后，相信大家對Cgroup限制CPU、IO、內存以及linux系統中的調度方法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！