摘要:原文鏈接深入理解系列一基本概念是的一項功能它是在一個系統中運行的層級制進程組,你可對其進行資源分配如時間系統內存網絡帶寬或者這些資源的組合。
原文鏈接:深入理解 Linux Cgroup 系列(一):基本概念
Cgroup 是 Linux kernel 的一項功能:它是在一個系統中運行的層級制進程組,你可對其進行資源分配(如 CPU 時間、系統內存、網絡帶寬或者這些資源的組合)。通過使用 cgroup,系統管理員在分配、排序、拒絕、管理和監控系統資源等方面,可以進行精細化控制。硬件資源可以在應用程序和用戶間智能分配,從而增加整體效率。
cgroup 和 namespace 類似,也是將進程進行分組,但它的目的和 namespace 不一樣,namespace 是為了隔離進程組之間的資源,而 cgroup 是為了對一組進程進行統一的資源監控和限制。
cgroup 分 v1 和 v2 兩個版本,v1 實現較早,功能比較多,但是由于它里面的功能都是零零散散的實現的,所以規劃的不是很好,導致了一些使用和維護上的不便,v2 的出現就是為了解決 v1 中這方面的問題,在最新的 4.5 內核中,cgroup v2 聲稱已經可以用于生產環境了,但它所支持的功能還很有限,隨著 v2 一起引入內核的還有 cgroup namespace。v1 和 v2 可以混合使用,但是這樣會更復雜,所以一般沒人會這樣用。
1. 為什么需要 cgroup在 Linux 里,一直以來就有對進程進行分組的概念和需求,比如 session group, progress group 等,后來隨著人們對這方面的需求越來越多,比如需要追蹤一組進程的內存和 IO 使用情況等,于是出現了 cgroup,用來統一將進程進行分組,并在分組的基礎上對進程進行監控和資源控制管理等。
2. 什么是 cgroup術語 cgroup 在不同的上下文中代表不同的意思,可以指整個 Linux 的 cgroup 技術,也可以指一個具體進程組。
cgroup 是 Linux 下的一種將進程按組進行管理的機制,在用戶層看來,cgroup 技術就是把系統中的所有進程組織成一顆一顆獨立的樹,每棵樹都包含系統的所有進程,樹的每個節點是一個進程組,而每顆樹又和一個或者多個 subsystem 關聯,樹的作用是將進程分組,而 subsystem 的作用就是對這些組進行操作。cgroup 主要包括下面兩部分:
subsystem : 一個 subsystem 就是一個內核模塊,他被關聯到一顆 cgroup 樹之后,就會在樹的每個節點(進程組)上做具體的操作。subsystem 經常被稱作 resource controller,因為它主要被用來調度或者限制每個進程組的資源,但是這個說法不完全準確,因為有時我們將進程分組只是為了做一些監控,觀察一下他們的狀態,比如 perf_event subsystem。到目前為止,Linux 支持 12 種 subsystem,比如限制 CPU 的使用時間,限制使用的內存,統計 CPU 的使用情況,凍結和恢復一組進程等,后續會對它們一一進行介紹。
hierarchy : 一個 hierarchy 可以理解為一棵 cgroup 樹,樹的每個節點就是一個進程組,每棵樹都會與零到多個 subsystem 關聯。在一顆樹里面,會包含 Linux 系統中的所有進程,但每個進程只能屬于一個節點(進程組)。系統中可以有很多顆 cgroup 樹,每棵樹都和不同的 subsystem 關聯,一個進程可以屬于多顆樹,即一個進程可以屬于多個進程組,只是這些進程組和不同的 subsystem 關聯。目前 Linux 支持 12 種 subsystem,如果不考慮不與任何 subsystem 關聯的情況(systemd 就屬于這種情況),Linux 里面最多可以建 12 顆 cgroup 樹,每棵樹關聯一個 subsystem,當然也可以只建一棵樹,然后讓這棵樹關聯所有的 subsystem。當一顆 cgroup 樹不和任何 subsystem 關聯的時候,意味著這棵樹只是將進程進行分組,至于要在分組的基礎上做些什么,將由應用程序自己決定,systemd 就是一個這樣的例子。
3. 將資源看作一塊餅在 CentOS 7 系統中(包括 Red Hat Enterprise Linux 7),通過將 cgroup 層級系統與 systemd 單位樹捆綁,可以把資源管理設置從進程級別移至應用程序級別。默認情況下,systemd 會自動創建 slice、scope 和 service 單位的層級(具體的意思稍后再解釋),來為 cgroup 樹提供統一結構。可以通過 systemctl 命令創建自定義 slice 進一步修改此結構。
如果我們將系統的資源看成一塊餡餅,那么所有資源默認會被劃分為 3 個 cgroup:System, User 和 Machine。每一個 cgroup 都是一個 slice,每個 slice 都可以有自己的子 slice,如下圖所示:
下面我們以 CPU 資源為例,來解釋一下上圖中出現的一些關鍵詞。
如上圖所示,系統默認創建了 3 個頂級 slice(System, User 和 Machine),每個 slice 都會獲得相同的 CPU 使用時間(僅在 CPU 繁忙時生效),如果 user.slice 想獲得 100% 的 CPU 使用時間,而此時 CPU 比較空閑,那么 user.slice 就能夠如愿以償。這三種頂級 slice 的含義如下:
system.slice —— 所有系統 service 的默認位置
user.slice —— 所有用戶會話的默認位置。每個用戶會話都會在該 slice 下面創建一個子 slice,如果同一個用戶多次登錄該系統,仍然會使用相同的子 slice。
machine.slice —— 所有虛擬機和 Linux 容器的默認位置
控制 CPU 資源使用的其中一種方法是 shares。shares 用來設置 CPU 的相對值(你可以理解為權重),并且是針對所有的 CPU(內核),默認值是 1024。因此在上圖中,httpd, sshd, crond 和 gdm 的 CPU shares 均為 1024,System, User 和 Machine 的 CPU shares 也是 1024。
假設該系統上運行了 4 個 service,登錄了兩個用戶,還運行了一個虛擬機。同時假設每個進程都要求使用盡可能多的 CPU 資源(每個進程都很繁忙)。
system.slice 會獲得 33.333% 的 CPU 使用時間,其中每個 service 都會從 system.slice 分配的資源中獲得 1/4 的 CPU 使用時間,即 8.25% 的 CPU 使用時間。
user.slice 會獲得 33.333% 的 CPU 使用時間,其中每個登錄的用戶都會獲得 16.5% 的 CPU 使用時間。假設有兩個用戶:tom 和 jack,如果 tom 注銷登錄或者殺死該用戶會話下的所有進程,jack 就能夠使用 33.333% 的 CPU 使用時間。
machine.slice 會獲得 33.333% 的 CPU 使用時間,如果虛擬機被關閉或處于 idle 狀態,那么 system.slice 和 user.slice 就會從這 33.333% 的 CPU 資源里分別獲得 50% 的 CPU 資源,然后均分給它們的子 slice。
如果想嚴格控制 CPU 資源,設置 CPU 資源的使用上限,即不管 CPU 是否繁忙,對 CPU 資源的使用都不能超過這個上限。可以通過以下兩個參數來設置:
cpu.cfs_period_us = 統計CPU使用時間的周期,單位是微秒(us) cpu.cfs_quota_us = 周期內允許占用的CPU時間(指單核的時間,多核則需要在設置時累加)
systemctl 可以通過 CPUQuota 參數來設置 CPU 資源的使用上限。例如,如果你想將用戶 tom 的 CPU 資源使用上限設置為 20%,可以執行以下命令:
$ systemctl set-property user-1000.slice CPUQuota=20%
在使用命令 systemctl set-property 時,可以使用 tab 補全:
$ systemctl set-property user-1000.slice
AccuracySec= CPUAccounting= Environment= LimitCPU= LimitNICE= LimitSIGPENDING= SendSIGKILL=
BlockIOAccounting= CPUQuota= Group= LimitDATA= LimitNOFILE= LimitSTACK= User=
BlockIODeviceWeight= CPUShares= KillMode= LimitFSIZE= LimitNPROC= MemoryAccounting= WakeSystem=
BlockIOReadBandwidth= DefaultDependencies= KillSignal= LimitLOCKS= LimitRSS= MemoryLimit=
BlockIOWeight= DeviceAllow= LimitAS= LimitMEMLOCK= LimitRTPRIO= Nice=
BlockIOWriteBandwidth= DevicePolicy= LimitCORE= LimitMSGQUEUE= LimitRTTIME= SendSIGHUP=
這里有很多屬性可以設置,但并不是所有的屬性都是用來設置 cgroup 的,我們只需要關注 Block, CPU 和 Memory。
如果你想通過配置文件來設置 cgroup,service 可以直接在 /etc/systemd/system/xxx.service.d 目錄下面創建相應的配置文件,slice 可以直接在 /run/systemd/system/xxx.slice.d 目錄下面創建相應的配置文件。事實上通過 systemctl 命令行工具設置 cgroup 也會寫到該目錄下的配置文件中:
$ cat /run/systemd/system/user-1000.slice.d/50-CPUQuota.conf [Slice] CPUQuota=20%
查看對應的 cgroup 參數:
$ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user-1000.slice/cpu.cfs_period_us 100000 $ cat /sys/fs/cgroup/cpu,cpuacct/user.slice/user-1000.slice/cpu.cfs_quota_us 20000
這表示用戶 tom 在一個使用周期內(100 毫秒)可以使用 20 毫秒的 CPU 時間。不管 CPU 是否空閑,該用戶使用的 CPU 資源都不會超過這個限制。
{{% notice note %}} CPUQuota 的值可以超過 100%,例如:如果系統的 CPU 是多核,且 CPUQuota 的值為 200%,那么該 slice 就能夠使用 2 核的 CPU 時間。 {{% /notice %}}
4. 總結本文主要介紹了 cgroup 的一些基本概念,包括其在 CentOS 系統中的默認設置和控制工具,以 CPU 為例闡述 cgroup 如何對資源進行控制。下一篇文章將會通過具體的示例來觀察不同的 cgroup 設置對性能的影響。
5. 參考資料Linux Cgroup系列(01):Cgroup概述
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/7207.html
摘要:一般的硬件虛擬化方法給出的方法是,而給出的方法是,更細一點講就是。在中,并不能像硬件虛擬化方案一樣能夠定義能力,但是能夠定義輪轉的優先級,因此具有較高優先級的進程會更可能得到運算。 本文簡單介紹docker使用到的部分核心技術,但不做深入探究,因為每一個技術都是一個獨立的項目,有機會再分別詳細介紹。 來源地址:http://www.infoq.com/cn/articles/docke...
摘要:本系列教程翻譯自,系列共有九篇,本文譯自第一篇。,一種新的容器化技術,因為輕量級和便攜化而受到廣泛關注。本篇文章是系列教程的第一篇。鏡像只讀的容器模板,簡言之就是系統鏡像文件。首先,向發出請求創建一個鏡像并且指定容器內要運行的命令。 本系列教程翻譯自 Flux7 Docker Tutorial Series,系列共有九篇,本文譯自第一篇 Part 1: An Introduction。...
摘要:本系列教程翻譯自,系列共有九篇,本文譯自第一篇。,一種新的容器化技術,因為輕量級和便攜化而受到廣泛關注。本篇文章是系列教程的第一篇。鏡像只讀的容器模板,簡言之就是系統鏡像文件。首先,向發出請求創建一個鏡像并且指定容器內要運行的命令。 本系列教程翻譯自 Flux7 Docker Tutorial Series,系列共有九篇,本文譯自第一篇 Part 1: An Introduction。...
閱讀 774·2023-04-25 16:55
閱讀 2803·2021-10-11 10:59
閱讀 2070·2021-09-09 11:38
閱讀 1782·2021-09-03 10:40
閱讀 1485·2019-08-30 15:52
閱讀 1125·2019-08-30 15:52
閱讀 953·2019-08-29 15:33
閱讀 3493·2019-08-29 11:26