国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 系統 > Linux > 正文

Linux資源控制-CPU和內存

2024-06-28 13:24:27
字體:
來源:轉載
供稿:網友
linux資源控制-CPU和內存

主要介紹Linux下, 如果對進程的CPU和內存資源的使用情況進行控制的方法。

CPU資源控制

每個進程能夠占用CPU多長時間, 什么時候能夠占用CPU是和系統的調度密切相關的.

Linux系統中有多種調度策略, 各種調度策略有其適用的場景, 也很難說哪種調度策略是最優的.

Linux的調度策略可以參見代碼: include/linux/sched.h

/* * Scheduling policies */#define SCHED_NORMAL        0#define SCHED_FIFO        1#define SCHED_RR        2#define SCHED_BATCH        3/* SCHED_ISO: reserved but not implemented yet */#define SCHED_IDLE        5/* Can be ORed in to make sure the PRocess is reverted back to SCHED_NORMAL on fork */#define SCHED_RESET_ON_FORK     0x40000000

Linux 系統也提供了修改調度策略的命令和系統調用接口.

調用接口請查詢相關文檔, 這里主要介紹一下修改調度策略的命令 - chrt.

# 在一個終端中執行sleep 1000# 打開另一個終端ps -ef | grep sleep  # 找出 sleep 1000 的pid, 這里假設是 1234chrt -p 1234         # 可以查看 pid=1234 的進程的 調度策略, 輸入如下:      pid 1234's current scheduling policy: SCHED_OTHER      pid 1234's current scheduling priority: 0chrt -p -f 10 1234   # 修改調度策略為 SCHED_FIFO, 并且優先級為10chrt -p 1234         # 再次查看調度策略      pid 1234's current scheduling policy: SCHED_FIFO      pid 1234's current scheduling priority: 10

補充:

  1. chrt 也可以直接指定一條命令, 并設置這條命令的優先級的調度策略, 具體查看 chrt --help
  2. 查看一個進程的調度策略, 除了使用 chrt 命令之外, 還可以 cat /proc/<PID>/sched

實時進程的CPU控制

所謂的實時進程, 也就是那些對響應時間要求比較高的進程.

這類進程需要在限定的時間內處理用戶的請求, 因此, 在限定的這段時間內, 需要占用所有CPU資源, 并且不能被其它進程打斷.

在這種情況下, 如果實時進程中出現了類似死循環之類的情況, 就會導致整個系統無響應.

因為實時進程的CPU優先級高, 并且未處理完之前是不會釋放CPU資源的.

所以, 內核中需要有一種方式來限制實時進程的CPU資源占用.

系統整體設置

1. 獲取當前系統的設置

sysctl -n kernel.sched_rt_period_us   # 實時進程調度的單位CPU時間 1 秒1000000sysctl -n kernel.sched_rt_runtime_us  # 實時進程在 1 秒中實際占用的CPU時間, 0.95秒950000

這個設置說明實時進程在運行時并不是完全占用CPU的, 每1秒中有0.05秒的時間可以給其它進程運行.

這樣既不會對實時進程的響應時間造成太大的影響, 也避免了實時進程卡住時導致整個系統無響應.

2. 設置實時進程占用CPU時間

上面的默認設置中, 實時進程占用 95% 的CPU時間. 如果覺得占用的太多或太少, 都是可以調整的.比如:

sysctl -w kernel.sched_rt_runtime_us=900000    # 設置實時進程每1秒中只占0.9秒的CPU時間kernel.sched_rt_runtime_us = 900000sysctl -n kernel.sched_rt_runtime_us 900000

cgroup 中的設置

整體設置是針對整個系統的, 我們也可以通過 cgroup 來對一組進程的CPU資源進行控制.

如果想在 cgroup 中對 sched_rt_period_us 和 sched_rt_runtime_us 進行控制, 需要內核編譯選項 CONFIG_RT_GROUP_SCHED=y

查看當前系統的內核編譯選項方法如下: (debian 7.6 系統)

cat /boot/config-`uname -r`

查看 CONFIG_RT_GROUP_SCHED 是否啟用

cat /boot/config-`uname -r` | grep -i rt_group# CONFIG_RT_GROUP_SCHED is not set

debian 7.6 默認沒有啟動這個選項, 所以掛載cgroup之后, 沒有設置 sched_rt_period_us 和 sched_rt_runtime_us 的文件

mkdir /mnt/cgroupmount -t cgroup cgroup /mnt/cgroup/cd /mnt/cgroup/ls -ltotal 0-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.io_merged-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.io_queued-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.io_service_bytes-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.io_serviced-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.io_service_time-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.io_wait_time--w------- 1 root root 0 Aug 28 09:06 blkio.reset_stats-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.sectors-r--r--r-- 1 root root 0 Aug 28 09:06 blkio.time-rw-r--r-- 1 root root 0 Aug 28 09:06 blkio.weight-rw-r--r-- 1 root root 0 Aug 28 09:06 blkio.weight_device-rw-r--r-- 1 root root 0 Aug 28 09:06 cgroup.clone_children--w--w--w- 1 root root 0 Aug 28 09:06 cgroup.event_control-rw-r--r-- 1 root root 0 Aug 28 09:06 cgroup.procs-r--r--r-- 1 root root 0 Aug 28 09:06 cpuacct.stat-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuacct.usage-r--r--r-- 1 root root 0 Aug 28 09:06 cpuacct.usage_percpu-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.cpu_exclusive-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.cpus-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.mem_exclusive-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.mem_hardwall-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.memory_migrate-r--r--r-- 1 root root 0 Aug 28 09:06 cpuset.memory_pressure-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.memory_pressure_enabled-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.memory_spread_page-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.memory_spread_slab-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.mems-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.sched_load_balance-rw-r--r-- 1 root root 0 Aug 28 09:06 cpuset.sched_relax_domain_level-rw-r--r-- 1 root root 0 Aug 28 09:06 cpu.shares--w------- 1 root root 0 Aug 28 09:06 devices.allow--w------- 1 root root 0 Aug 28 09:06 devices.deny-r--r--r-- 1 root root 0 Aug 28 09:06 devices.list-rw-r--r-- 1 root root 0 Aug 28 09:06 net_cls.classid-rw-r--r-- 1 root root 0 Aug 28 09:06 notify_on_release-rw-r--r-- 1 root root 0 Aug 28 09:06 release_agent-rw-r--r-- 1 root root 0 Aug 28 09:06 tasks

果然, 只有cpu.share, 沒有 cpu.sched_rt_period_us 和 cpu.sched_rt_runtime_us

沒辦法, 重新編譯內核, 編譯內核的具體方法參見: 編譯Linux內核

為了節約時間, 我們用 make localmodconfig 來創建 .config 文件, 然后修改其中的 CONFIG_RT_GROUP_SCHED=y

下載源碼等等參見: 編譯Linux內核, 主要步驟如下:

cd /path/to/linux-source-3.2make localmodconfigvim .config   # 設置 CONFIG_RT_GROUP_SCHED=y 并保存makemake modules_installmake installreboot      # 重啟之前看看 /boot/grub/grub.cfg 中, 默認啟動的是不是新安裝的內核

啟動到新內核, 再次查看內核選項 CONFIG_RT_GROUP_SCHED 是否啟用

cat /boot/config-`uname -r` | grep -i rt_groupCONFIG_RT_GROUP_SCHED=y       # 已啟用

再次掛載 cgroup 文件系統, 發現多了2個配置文件, cpu.rt_period_us 和 cpu.rt_runtime_us

mount -t cgroup cgroup /mnt/cgroup/cd /mnt/cgroup/ls -ltotal 0-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.io_merged-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.io_queued-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.io_service_bytes-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.io_serviced-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.io_service_time-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.io_wait_time--w------- 1 root root 0 Aug 28 09:53 blkio.reset_stats-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.sectors-r--r--r-- 1 root root 0 Aug 28 09:53 blkio.time-rw-r--r-- 1 root root 0 Aug 28 09:53 blkio.weight-rw-r--r-- 1 root root 0 Aug 28 09:53 blkio.weight_device-rw-r--r-- 1 root root 0 Aug 28 09:53 cgroup.clone_children--w--w--w- 1 root root 0 Aug 28 09:53 cgroup.event_control-rw-r--r-- 1 root root 0 Aug 28 09:53 cgroup.procs-r--r--r-- 1 root root 0 Aug 28 09:53 cpuacct.stat-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuacct.usage-r--r--r-- 1 root root 0 Aug 28 09:53 cpuacct.usage_percpu-rw-r--r-- 1 root root 0 Aug 28 09:53 cpu.rt_period_us-rw-r--r-- 1 root root 0 Aug 28 09:53 cpu.rt_runtime_us-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.cpu_exclusive-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.cpus-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.mem_exclusive-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.mem_hardwall-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.memory_migrate-r--r--r-- 1 root root 0 Aug 28 09:53 cpuset.memory_pressure-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.memory_pressure_enabled-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.memory_spread_page-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.memory_spread_slab-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.mems-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.sched_load_balance-rw-r--r-- 1 root root 0 Aug 28 09:53 cpuset.sched_relax_domain_level-rw-r--r-- 1 root root 0 Aug 28 09:53 cpu.shares--w------- 1 root root 0 Aug 28 09:53 devices.allow--w------- 1 root root 0 Aug 28 09:53 devices.deny-r--r--r-- 1 root root 0 Aug 28 09:53 devices.list-rw-r--r-- 1 root root 0 Aug 28 09:53 net_cls.classid-rw-r--r-- 1 root root 0 Aug 28 09:53 notify_on_release-rw-r--r-- 1 root root 0 Aug 28 09:53 release_agent-rw-r--r-- 1 root root 0 Aug 28 09:53 taskscat cpu.rt_period_us 1000000cat cpu.rt_runtime_us 950000

通過配置 cpu.rt_period_us 和 cpu.rt_runtime_us 就可以對 cgroup 中的進程組中的實時進程進行 CPU使用時間的控制.

資源控制實例

上面主要介紹資源的一些理論基礎, 下面通過一些實例演示如果通過 cgroup 來控制進程所使用的 CPU和內存 資源.

Linux對CPU 和 內存的控制有對應的 cgroup 子系統 cpuset 和 memory

實例: cgroup 中對其中 *子cgroup* 的CPU資源控制

對各個 *子cgroup* 的CPU占用率進行控制主要依靠每個 *子cgroup* 的 cpu.shares 文件

直接用實驗過程來說話, 其中加入了一些注釋.

# 安裝需要的軟件apt-get install stress     # 讓CPU達到 100% 的壓力工具apt-get install sysstat    # 查看系統CPU, 內存, 磁盤, 網絡等資源使用情況的工具

實例1 - 默認情況, A 和 B 各占CPU總資源的 1/2
  1. 掛載 cgroup 文件系統 (注意加上 -o cpu 的選項)
  2. 在 cgroup中創建 2個子cgroup A 和 B
  3. 默認情況下, cgroup A 和 cgroup B 中的 cpu.shares 中的數值都是 1024
  4. 在 A 和 B 中用 stress 工具使其 CPU占用率達到 100%
  5. top 命令查看 A 和 B 中進程分別占用的 CPU (應該都是 50%)

# 掛載 cgroup 文件系統mount -t cgroup -o cpu cgroup /mnt/cgroup/cd /mnt/cgroupls -ltotal 0-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.io_merged-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.io_queued-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.io_service_bytes-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.io_serviced-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.io_service_time-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.io_wait_time--w------- 1 root root 0 Aug 28 11:29 blkio.reset_stats-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.sectors-r--r--r-- 1 root root 0 Aug 28 11:29 blkio.time-rw-r--r-- 1 root root 0 Aug 28 11:29 blkio.weight-rw-r--r-- 1 root root 0 Aug 28 11:29 blkio.weight_device-rw-r--r-- 1 root root 0 Aug 28 11:29 cgroup.clone_children--w--w--w- 1 root root 0 Aug 28 11:29 cgroup.event_control-rw-r--r-- 1 root root 0 Aug 28 11:29 cgroup.procs-r--r--r-- 1 root root 0 Aug 28 11:29 cpuacct.stat-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuacct.usage-r--r--r-- 1 root root 0 Aug 28 11:29 cpuacct.usage_percpu-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.cpu_exclusive-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.cpus-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.mem_exclusive-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.mem_hardwall-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.memory_migrate-r--r--r-- 1 root root 0 Aug 28 11:29 cpuset.memory_pressure-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.memory_pressure_enabled-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.memory_spread_page-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.memory_spread_slab-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.mems-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.sched_load_balance-rw-r--r-- 1 root root 0 Aug 28 11:29 cpuset.sched_relax_domain_level-rw-r--r-- 1 root root 0 Aug 28 11:29 cpu.shares--w------- 1 root root 0 Aug 28 11:29 devices.allow--w------- 1 root root 0 Aug 28 11:29 devices.deny-r--r--r-- 1 root root 0 Aug 28 11:29 devices.list-rw-r--r-- 1 root root 0 Aug 28 11:29 net_cls.classid-rw-r--r-- 1 root root 0 Aug 28 11:29 notify_on_release-rw-r--r-- 1 root root 0 Aug 28 11:29 release_agent-rw-r--r-- 1 root root 0 Aug 28 11:29 tasks# 創建 子cgroup A 和 Bmkdir {A,B}cat A/cpu.shares 1024cat B/cpu.shares 1024# 在 A 和 B 中分別通過 stress 工具使其CPU使用率達到 100%echo $$ > A/tasks  # 將當前的 SHELL 加入到 cgroup A中stress -c 2    # 這里-c 2 是因為測試機器是雙核, 要在2個核上都產生 100% 的CPU 占用率# 另外打開一個 shell 窗口, 并將這個shell 加入到 cgroup B中echo $$ > B/tasks  # 將當前的 SHELL 加入到 cgroup B中stress -c 2    # 在2個核上都產生 100% 的CPU 占用率# 再打開一個 shell 窗口, 用top命令查看 CPU占用情況toptop - 14:10:32 up 43 min,  3 users,  load average: 2.31, 1.24, 0.62Tasks:  78 total,   5 running,  73 sleeping,   0 stopped,   0 zombie%Cpu(s):100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem:   1887872 total,   114744 used,  1773128 free,    10472 buffersKiB Swap:  3982332 total,        0 used,  3982332 free,    45068 cached PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                      3350 root      20   0  6524   92    0 R  49.9  0.0   0:08.73 stress                                                                                                                       3351 root      20   0  6524   92    0 R  49.9  0.0   0:08.67 stress                                                                                                                       3353 root      20   0  6524   92    0 R  49.9  0.0   0:07.35 stress                                                                                                                       3354 root      20   0  6524   92    0 R  49.9  0.0   0:07.36 stress                    # 查看這 4 個stress 進程是否分別屬于 A 和 Bcat /mnt/cgroup/A/tasks 294533493350   <-- stress 進程3351   <-- stress 進程cat /mnt/cgroup/B/tasks 299633523353   <-- stress 進程3354   <-- stress 進程

可以看出, A和B組中的 2個stress 進程的CPU使用率相加都是 100%,

由于我測試的電腦是雙核, top所看到的CPU最大使用率是 200%, 所以和預期一致, A和B組各占CPU總資源的 1/2

實例2 - A group 占用整體CPU資源的 2/3, B group 占用整體CPU資源的 1/3
  1. 環境同 實例1, 不再重新掛載 cgroup 文件系統, 也不在重建 A 和 B
  2. A group 的 cpu.shares 文件不變, 值為 1024
  3. B group 的 cpu.shares 文件中的值改為 512, 這樣, 相當于B占用CPU總資源的 1/3 (因為 512 / (512+1024) = 1/3)
  4. 同實例1, 通過2個shell窗口, 分別是 A 和 B 的CPU使用率達到 100%, 然后通過 top 查看CPU使用情況

# 在 B 中shell 窗口執行以下命令cat B/cpu.shares 1024echo 512 > B/cpu.shares cat B/cpu.shares 512stress -c 2# 在 A 中 shell 窗口執行以下命令stress -c 2# 在第3個 shell 窗口, 也就是 非A, 非B 的那個 shell 窗口, 用 top 查看cpu使用情況toptop - 14:13:18 up 46 min,  3 users,  load average: 2.24, 1.92, 1.01Tasks:  78 total,   5 running,  73 sleeping,   0 stopped,   0 zombie%Cpu(s):100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem:   1887872 total,   114744 used,  1773128 free,    10488 buffersKiB Swap:  3982332 total,        0 used,  3982332 free,    45068 cached PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                      3376 root      20   0  6524   88    0 R  66.6  0.0   0:06.29 stress                                                                                                                       3377 root      20   0  6524   88    0 R  66.6  0.0   0:06.30 stress                                                                                                                       3373 root      20   0  6524   88    0 R  33.3  0.0   0:04.33 stress                                                                                                                       3374 root      20   0  6524   88    0 R  33.3  0.0   0:04.32 stress               # 查看這 4 個stress 進程是否分別屬于 A 和 Bcat /mnt/cgroup/A/tasks 294533753376    <-- stress 進程3377    <-- stress 進程cat /mnt/cgroup/B/tasks 299633723373    <-- stress 進程3374    <-- stress 進程

很明顯, A 組中的2個進程占用了CPU總量的 2/3 左右, B組中的2個進程占用了CPU總量的 1/3 左右.

實例3 - 物理CPU的控制

上面的實例中, 雖然能夠控制每個組的CPU的總體占用率, 但是不能控制某個組的進程固定在某個物理CPU上運行.

要想將 cgroup 綁定到某個固定的CPU上, 需要使用 cpuset 子系統.

首先, 查看系統是否支持 cpuset 子系統, 也就是看內核編譯選項 CONFIG_CPUSETS 是否設為y

cat /boot/config-`uname -r` | grep -i cpusetsCONFIG_CPUSETS=y

我的測試系統是支持的, 如果你的系統不支持, 就需要重新編譯內核了.......

然后, 用下面的例子演示將 A 和 B中的 stress 都指定到1個CPU上后的情況

  1. 卸載當前的 cgroup
  2. 再次掛載 cgroup 文件系統, 并指定 -o cpuset
  3. 指定 A 的物理CPU為 0 (雙核CPU的每個核編號分別是 CPU0, CPU1)
  4. 指定 B 的物理CPU也為 0
  5. 重復 實例1 中的步驟, 觀察發生的變化

umount /mnt/cgroupmount -t cgroup -o cpuset cgroup /mnt/cgroup/cd /mnt/cgroupls -ltotal 0-rw-r--r-- 1 root root 0 Aug 28 14:39 cgroup.clone_children--w--w--w- 1 root root 0 Aug 28 14:39 cgroup.event_control-rw-r--r-- 1 root root 0 Aug 28 14:39 cgroup.procs-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.cpu_exclusive-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.cpus    <-- 這個就是設置關聯物理CPU的文件-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.mem_exclusive-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.mem_hardwall-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.memory_migrate-r--r--r-- 1 root root 0 Aug 28 14:39 cpuset.memory_pressure-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.memory_pressure_enabled-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.memory_spread_page-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.memory_spread_slab-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.mems-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.sched_load_balance-rw-r--r-- 1 root root 0 Aug 28 14:39 cpuset.sched_relax_domain_level-rw-r--r-- 1 root root 0 Aug 28 14:39 notify_on_release-rw-r--r-- 1 root root 0 Aug 28 14:39 release_agent-rw-r--r-- 1 root root 0 Aug 28 14:39 tasks# 創建子cgroup A 和 Bmkdir {A,B}cat A/cpuset.cpus            <--  默認是空的echo 0 > A/cpuset.cpuscat A/cpuset.cpus 0echo 0 > B/cpuset.cpus   # 同樣, 設置B組也綁定到CPU0# 當前Shell加入到 A組echo $$ > /mnt/cgroup/A/tasks -bash: echo: write error: No space left on device

如果出現上述錯誤, 只需要再設置 /mnt/cgroup/A/cpuset.mems 即可. (參考: http://serverfault.com/questions/579555/cgroup-no-space-left-on-device)

# 同時設置 A 的 cpuset.cpus 和 cpuset.memsecho 0 > A/cpuset.cpusecho 0 > A/cpuset.mems# B組也同樣設置echo 0 > B/cpuset.cpusecho 0 > B/cpuset.mems# 將當前 shell 加入到 A組echo $$ > /mnt/cgroup/A/tasks   <-- 設置過 cpuset.mems 后, 就沒有出錯了stress -c 2# 再打開一個Shell窗口, 并加入到 B組echo $$ > /mnt/cgroup/B/tasksstress -c 2# 再打開第3個 shell 窗口, 用top命令查看CPU使用情況toptop - 15:13:29 up  1:46,  3 users,  load average: 1.01, 0.24, 0.12Tasks:  78 total,   5 running,  73 sleeping,   0 stopped,   0 zombie%Cpu(s): 50.0 us,  0.0 sy,  0.0 ni, 50.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem:   1887872 total,   117216 used,  1770656 free,    11144 buffersKiB Swap:  3982332 total,        0 used,  3982332 free,    47088 cached PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                      3830 root      20   0  6524   92    0 R  25.0  0.0   0:04.96 stress                                                                                                                       3831 root      20   0  6524   92    0 R  25.0  0.0   0:04.97 stress                                                                                                                       3834 root      20   0  6524   92    0 R  25.0  0.0   0:03.56 stress                                                                                                                       3833 root      20   0  6524   92    0 R  24.6  0.0   0:03.56 stress

從上面的結果可以看出, 雖然 stress 命令指定了 -c 2(意思是在2個CPU上運行), 但是由于A和B都只綁定了CPU0,

所以雖然是雙核的機器, 它們所占用的CPU總量卻只有 100%, 而不是實例1 中的 200%.

如果將B組的物理CPU綁定到CPU1, 那么應該所有 stress 的進程都占用 50%, CPU資源的總量變為 200%.

下面將B組的物理CPU綁定為CPU1, 看看結果是否和我們的預期一樣.

# 在 B組的 shell 窗口中執行以下命令echo 1 > /mnt/cgroup/B/cpuset.cpuscat /mnt/cgroup/B/cpuset.cpus1stress -c 2# 在 A組的 shell 窗口中執行以下命令stress -c 2# 在第3個shell窗口中用top命令查看執行結果toptop - 15:20:07 up  1:53,  3 users,  load average: 0.38, 0.83, 0.56Tasks:  78 total,   5 running,  73 sleeping,   0 stopped,   0 zombie%Cpu(s):100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem:   1887872 total,   117340 used,  1770532 free,    11168 buffersKiB Swap:  3982332 total,        0 used,  3982332 free,    47088 cached  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                       3854 root      20   0  6524   88    0 R  49.9  0.0   0:03.76 stress                                                                                                                        3857 root      20   0  6524   92    0 R  49.9  0.0   0:02.29 stress                                                                                                                        3858 root      20   0  6524   92    0 R  49.9  0.0   0:02.29 stress                                                                                                                        3855 root      20   0  6524   88    0 R  49.6  0.0   0:03.76 stress

果然, 和預期一致. A組中的 stress 和 B組中的 stress 在各自的物理CPU上都占用了 100% 左右的CPU使用率.

實例4 - cgroup 對使用的內存的控制

cgroup 對內存的控制也很簡單, 只要掛載cgroup時, 指定 -o memory

# 首先之前掛載的 cpuset 子系統umount /mnt/cgroup# 掛載cgroup 文件系統, 指定 -o memeorymount -o memory -t cgroup memcg /mnt/cgroup/mount: special device memcg does not exist

出現以上錯誤的原因可能是因為debian系統中, 默認沒有啟動 cgroup 的memory子系統. 可以通過以下方法確認:

cat /proc/cgroups #subsys_name    hierarchy    num_cgroups    enabledcpuset    0    1    1cpu    0    1    1cpuacct    0    1    1memory    1    1    0              <-- 這里的 enabled 是 0devices    0    1    1freezer    0    1    1net_cls    0    1    1blkio    0    1    1perf_event    0    1    1

為了默認啟用memory子系統, 可以設置 grub選項

vim /etc/default/grub# 修改 GRUB_CMDLINE_LINUX=""  ==> GRUB_CMDLINE_LINUX="cgroup_enable=memory"# 保存后, 更新grub.cfgupdate-grubreboot

重啟之后, 發現 /proc/cgroups 中的memory已經 enabled, 并且也可以掛載 memcg了

cat /proc/cgroups #subsys_name    hierarchy    num_cgroups    enabledcpuset    0    1    1cpu    0    1    1cpuacct    0    1    1memory    1    1    1devices    0    1    1freezer    0    1    1net_cls    0    1    1blkio    0    1    1perf_event    0    1    1# 掛載cgroup 的memory子系統mount -t cgroup -o memory memcg /mnt/cgroupls -l /mnt/cgroup/   <-- 可以看到有很多 memory 相關的配置total 0-rw-r--r-- 1 root root 0 Aug 28 15:54 cgroup.clone_children--w--w--w- 1 root root 0 Aug 28 15:54 cgroup.event_control-rw-r--r-- 1 root root 0 Aug 28 15:54 cgroup.procs-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.failcnt--w------- 1 root root 0 Aug 28 15:54 memory.force_empty-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.limit_in_bytes   <-- 限制內存使用的配置文件-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.max_usage_in_bytes-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.move_charge_at_immigrate-r--r--r-- 1 root root 0 Aug 28 15:54 memory.numa_stat-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.oom_control-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.soft_limit_in_bytes-r--r--r-- 1 root root 0 Aug 28 15:54 memory.stat-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.swappiness-r--r--r-- 1 root root 0 Aug 28 15:54 memory.usage_in_bytes-rw-r--r-- 1 root root 0 Aug 28 15:54 memory.use_hierarchy-rw-r--r-- 1 root root 0 Aug 28 15:54 notify_on_release-rw-r--r-- 1 root root 0 Aug 28 15:54 release_agent-rw-r--r-- 1 root root 0 Aug 28 15:54 tasks

開始實驗:

  1. 重啟系統 (為了保證內存的干凈)
  2. 掛載 memcg
  3. 在掛載的 /mnt/cgroup 中創建 組A
  4. 將當前shell 加入到 組A
  5. 不限制組A的內存, 壓縮內核源碼包, 并觀察壓縮前后內存的變化
  6. 重復步驟 1 ~ 4
  7. 限制組A的內存為 10MB, 再次壓縮內核源碼包, 并觀察壓縮前后內存的變化

# 重啟系統reboot# 掛載 memcgmount -t cgroup -o memory memcg /mnt/cgroup# 創建 組Amkdir /mnt/cgroup/A# 將當前 shell 加入到組Aecho $$ > /mnt/cgroup/A/tasks# 測試不限制內存時, 內存的使用情況, 這里不用linux源碼也可以, 但最好用個大點的文件夾來壓縮, 以便更容易看出內存的變化.free -m; tar czvf linux-source-3.2.tar.gz /path/to/linux-source-3.2/ > /dev/null; free -m;             total       used       free     shared    buffers     cachedMem:          1843        122       1721          0          9         43-/+ buffers/cache:         68       1774Swap:         3888          0       3888             total       used       free     shared    buffers     cachedMem:          1843       1744         99          0         26       1614-/+ buffers/cache:        104       1739Swap:         3888          0       3888# 重啟系統reboot# 掛載 memcgmount -t cgroup -o memory memcg /mnt/cgroup# 創建 組Amkdir /mnt/cgroup/A# 將當前 shell 加入到組Aecho $$ > /mnt/cgroup/A/tasks# 限制 組A 的內存使用量最大為 10MBecho 10M > /mnt/cgroup/A/memory.limit_in_bytes# 測試限制內存為 10MB 時, 內存的使用情況.rm -rf linux-source-3.2.tar.gzfree -m; tar czvf linux-source-3.2.tar.gz /path/to/linux-source-3.2/ > /dev/null; free -m;             total       used       free     shared    buffers     cachedMem:          1843        122       1721          0         10         43-/+ buffers/cache:         68       1774Swap:         3888          0       3888             total       used       free     shared    buffers     cachedMem:          1843        194       1649          0         14         48-/+ buffers/cache:        131       1712Swap:         3888          0       3888

從上面的結果可以看出限制內存是起了作用的.

不限制內存時, tar 壓縮前后 buffer + cache 內存從 (9MB + 43MB) ==> (26MB + 1614MB) 增大了 1588MB

限制內存后, tar 壓縮前后 buffer + cache 內存從 (10MB + 43MB) ==> (14MB + 48MB) 增大了 9MB

總結

簡單的實驗就發現 cgroup 如此強大的控制能力(而且配置也很簡單), 這也就難怪LXC等容器技術能如此強大, 如此流行.

cgroup 的配置文件很多, 上面的實例中只簡單使用了其中的幾個配置文件, 如果想深入了解 cgroup, 更好的利用cgroup的話,

還得找個介紹cgroup配置文件的文檔來研究一下, 這篇博客提供的內容還遠遠不夠.


發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 九龙县| 曲靖市| 来宾市| 广平县| 大新县| 河北省| 黄浦区| 新津县| 湖南省| 读书| 固安县| 德令哈市| 仁布县| 平陆县| 宁化县| 临清市| 湘阴县| 韶关市| 凉城县| 原平市| 大安市| 屯留县| 冀州市| 福清市| 敖汉旗| 香河县| 南康市| 福州市| 阳朔县| 广德县| 嘉鱼县| 泾川县| 且末县| 明光市| 莎车县| 呼图壁县| 呼伦贝尔市| 金华市| 扶风县| 金坛市| 贵阳市|