Linux サーバの CPU やメモリリソースの管理について 運⽤本部 吉川 開発運⽤研修2019 2019-07-03 

本研修の⽬的 ▌計算資源としてのCPUとメモリの特徴を知る ▌プログラムによるリソース消費の仕⽅を知る ▌Linuxサーバでのリソース制御の仕組みを知る 

CPU ▌計算機のプログラム実⾏処理の中⼼となるユニット ▌ALUによる単純な算術演算だけではない n MMUによるページング n 各種キャッシュ（TLB, L1, L2, …） n KVMの使う仮想化⽀援機能 

計算資源としてみたCPUのイメージ ▌CPU使⽤率 n 「サーバのCPU使⽤率が⾼い」 ▌CPU時間 n 「プロセスAによるCPU時間の消費が激しい」 

CFSによるマルチタスキング ▌CFS (Completely Fair Scheduler) n Linuxのタスクスケジューラ ▌各タスクを公平に仮想的に分割されたCPUの上で実⾏ n 周期的に細かく実⾏タスクを切り替え（応答性にも配慮） n コンテキスト切り替えのオーバーヘッドあり（キャッシュも含め） CFS basically models an "ideal, precise multi-tasking CPU" on real hardware. https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt 

マルチコア環境でのタスクの並列実⾏ ▌複数コアを搭載したCPUの上でのタスクの並列実⾏ n 仮想的な時分割マルチタスキングと違い物理的に並列実⾏ ▌同時刻に実⾏可能なタスクが複数存在する場合に活⽤ n 無関係なプロセスでも同⼀アプリ内のスレッドでも良い 

スレッド数のチューニングについて ▌CPUを回せる状態のタスクの数をコア数に対して適切に n I/Oの完了待ち（%iowait）のタスクはCPUを他に譲る n 負荷のピーク時のコンテキスト切り替えのオーバーヘッドを考慮 n ワーキングセットが⼩さければロードアベレージが⾼くても問題ない場合あり n アプリのスレッドプールのスレッドを使い切っている状態での応答性を考慮 

仮想マシンのスケジューリング ▌KVMの仮想マシンはVCPUスレッドをスケジューリング n 仮想CPUの数だけホスト上でVCPUスレッドが起動 n VCPUスレッドがスケジュールされるとCPUがゲスト実⾏⽤のモードに n Intelの場合は VMX non-root モード n ゲストモードの間はゲストカーネルを含むゲスト命令を実⾏ n ゲストカーネルはゲスト内のタスクをスケジュールして実⾏ 

コンテナのスケジューリング ▌ホストカーネルの管理するプロセスグループとしてスケジューリング n 実態はcgroupで管理されたプロセスグループ n グループとしてcgroupのコントローラで制御可能 n 例︓コンテナAにコンテナBの倍くらいCPUを使わせる n ホスト上の top などでもCPU使⽤率を確認可能 n PID などは namespace により内外で⾒え⽅が違う 

CPUのオーバーコミットについて ▌仮想マシンもコンテナもオーバーコミットは可能 n 全仮想マシンのVCPUスレッド数の総和 > CPUのコア数 n 全コンテナのプロセス数の総和 > CPUのコア数 ▌同時に全ての環境が⾼負荷にならないように注意 n コンテナの場合は通常のロードアベレージ⾼騰と同じ n VCPUはアイドル度合いによる 

メモリ ▌主記憶装置、RAM ▌CPUの処理で命令やデータが置かれる n プログラムをロードしたり処理するデータを保持したり ▌記憶階層の中でCPUキャッシュと⼆次記憶（ディスク）の間 n 遅いか速いかは相対的なもの CPUキャッシュのヒット率を⾼める性能最適化（メモリにアクセスさせたら負け）もあるし、 オンメモリでの処理を増やす最適化（ディスクにアクセスさせたら負け）もある。 

CPUキャッシュ [07/02 23:30]takuya_yoshikawa@devboot-3:~$ lscpu … CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 2 Core(s) per socket: 10 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 63 Model name: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz Stepping: 2 CPU MHz: 1313.710 CPU max MHz: 3300.0000 CPU min MHz: 1200.0000 BogoMIPS: 5201.50 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 25600K … 

ヒュージページ（ラージページ）の活⽤話 ▌仮想アドレスから物理アドレスへの変換もメモリを消費する n ページテーブルは他のデータと同様にメモリに保存されている n TLB というアドレス変換専⽤のキャッシュもある n ページテーブル⽤のページも読み込むとデータキャッシュに n ページの単位を4KBから2MBや1GBにすると消費量が減る 

Linuxサーバのメモリ⽤途 ▌Anonymous メモリ（無名メモリ） n プログラムのヒープやスタックなど n ファイルシステム上のデータと紐づかない（代わりにスワップ） ▌ページキャッシュ n ファイルを読んだ際にメモリ上にキャッシュする場所 

Linuxサーバのメモリ⽤途（細かい分類） $ cat /proc/meminfo MemTotal: 22037764 kB MemFree: 255308 kB MemAvailable: 1874180 kB Buffers: 28 kB Cached: 1526748 kB SwapCached: 7320 kB Active: 952824 kB Inactive: 665616 kB Active(anon): 41616 kB Inactive(anon): 61908 kB Active(file): 911208 kB Inactive(file): 603708 kB Unevictable: 3652 kB Mlocked: 3652 kB SwapTotal: 8386556 kB SwapFree: 8212768 kB Dirty: 80 kB Writeback: 0 kB AnonPages: 91688 kB Mapped: 24156 kB Shmem: 9436 kB Slab: 323564 kB SReclaimable: 265396 kB SUnreclaim: 58168 kB KernelStack: 7136 kB PageTables: 3344 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 19405436 kB Committed_AS: 1153936 kB VmallocTotal: 34359738367 kB VmallocUsed: 0 kB VmallocChunk: 0 kB HardwareCorrupted: 0 kB AnonHugePages: 0 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 105852 kB DirectMap2M: 14049280 kB DirectMap1G: 9437184 kB プログラムが確保したメモリ、ファイルキャッシュ、ファイルシステムやネットワーク関連の処理が 発⽣した時に増加しやすいカーネルの使うスラブくらいの粒度では理解しておくべき 

使⽤するプログラミング⾔語によるメモリ使⽤特性に注意 ▌Javaアプリのメモリ使⽤量はサーバ管理者には⾒積もりやすい n JVMのヒープという形でまとめて確保されるので n ただしJVMのGCの特性について把握する必要あり ▌動的メモリ確保に依存したアプリをサーバで使⽤する際は注意 n サーバ管理者は重要度の⾼くないアプリ起因でのOOMに注意 n サーバ⽤のアプリ開発者は他のプロセスに迷惑をかけないように 

DBMSのメモリ管理 ▌Oracle, MySQL, PostgreSQL などのメモリ管理は独特 n カーネルのメモリ管理に⼲渉されたがらない n しかし半分利⽤したりもする（PostgreSQL のダブルバッファリング） ▌Forest の MySQL は InnoDB のバッファプールに強く依存 n データ読み込みがほぼ完全にバッファにヒットするように設計 

cgroup ▌control group ▌プロセスをグループ化して管理する Linux の機能 n プロセスを階層的にグループ化 n ユーザ空間からはファイルシステムのインタフェースを利⽤して管理 n グループに各種コントローラを適⽤可能 n サービスやコンテナの全体で使⽤可能なリソースの制御など 

CPU のリソース制御 ▌CFS のクォータベースでの制御 n プロセスグループが⼀定周期内で使⽤可能なCPU時間を制限 n CFS の時分割をグループ単位に拡張して制御している感じ ▌cpuset による使⽤可能なコアの制御 n cpuset は NUMA のリソース制御に使えるもの n CPU に関してはプロセスグループが使⽤可能なコアを静的指定可能 参考︓CFS Bandwidth Control と cpuset https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt 

メモリのリソース制御 ▌Memory Resource Controller による上限設定 ▌cpuset による使⽤可能な NUMA ノードの指定 参考︓Memory Resource Controller https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt [07/03 01:18]takuya_yoshikawa@devboot-3:~$ numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 node 0 size: 96582 MB node 0 free: 90187 MB node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 node 1 size: 96756 MB node 1 free: 94185 MB node distances: node 0 1 0: 10 21 1: 21 10 [07/03 01:18]takuya_yoshikawa@devboot-3:~$ 

Systemd の cgroup 利⽤ ▌Systemd のサービスに属するプロセスは cgroup でまとめてある n Systemd の設定でコントローラによる制御も可能 [07/03 01:22]takuya_yoshikawa@devboot-3:~$ ls /sys/fs/cgroup/systemd/system.slice/goma.service/ cgroup.clone_children cgroup.procs notify_on_release tasks [07/03 01:22]takuya_yoshikawa@devboot-3:~$ cat /sys/fs/cgroup/systemd/system.slice/goma.service/tasks 119620 119693 119694 119695 119697 119698 119699 119707 [07/03 01:24]takuya_yoshikawa@devboot-3:~$ 参考︓systemd.resource-control https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html 

コンテナのリソース制御の実践例 ▌Forest のログ基盤の lxc コンテナを cpuset で制御中 

Docker や Kubernetes のリソース制御の話 ▌cgroup のコントローラが内部で使われる ▌応答性を重視するかなどで使⽤するコントローラは変えるべき n CFS によるクォータ制御の場合はコンテキスト切り替えに注意 n cpuset による静的コア指定は問題なし（柔軟な運⽤には△） https://docs.docker.com/config/containers/resource_constraints/ https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/ https://kubernetes.io/blog/2018/07/24/feature-highlight-cpu-manager/