一、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中設定執行緒排程屬性失敗（sched_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 的最大記憶體使用量。

參考文獻：
https://blog.csdn.net/bingqingsuimeng/article/details/52084184 

https://segmentfault.com/a/1190000008125359?utm_source=tag-newest
-----------------