このチュートリアルでは、Alibaba Cloud ECS上でDockerコンテナのリソース制限機能を利用した実践的な体験ができます。
本ブログは英語版からの翻訳です。オリジナルはこちらからご確認いただけます。一部機械翻訳を使用しております。翻訳の間違いがありましたら、ご指摘いただけると幸いです。
--cpuset-cpus Sysbenchを使う
構文:
実行を許可する CPU 数 (0-3, 0, 1)
両方のCPUを使ってベンチテストを行います。
docker run -it --rm --name mybench --cpuset-cpus 0,1 centos:bench /bin/sh -c 'time sysbench --threads=2 --events=4 --cpu-max-prime=800500 --verbosity=0 cpu run'
real 0m1.957s
user 0m3.813s
sys 0m0.025s
CPU 0を使用してベンチテストを行います。
docker run -it --rm --name mybench --cpuset-cpus 0 centos:bench /bin/sh -c 'time sysbench --threads=2 --events=4 --cpu-max-prime=800500 --verbosity=0 cpu run'
real 0m3.789s
user 0m3.740s
sys 0m0.029s
CPU 1 を使用してベンチテストを行います。
docker run -it --rm --name mybench --cpuset-cpus 1 centos:bench /bin/sh -c 'time sysbench --threads=2 --events=4 --cpu-max-prime=800500 --verbosity=0 cpu run'
real 0m3.809s
user 0m3.761s
sys 0m0.025s
結果: 2 つの CPU の方が 1 つよりも高速です。
サーバーに 2 つ以上の CPU がある場合は、cpuset-CPUs の組み合わせを使って、より多くのテストを実行することができます。
ただ、 --threads= の設定はテストする CPU の数と同じでなければならないことに注意してください: 各 CPU は個別のスレッドワークロードを持つ必要があります。
もし本当に高速にしたいのであれば、max-prime の数を 100 倍に減らすことを検討してください。しかし、以下に示すように、このような短いランタイムでは、起動時の CPU 処理のオーバーヘッドが非常に多く、実際のウォールクロックの経過時間は、2 つの CPU が 1 つの 2 倍の速さであることを明確には示していません。したがって、テストの実行時間を短くしすぎないようにしてください。
docker run -it --rm --name mybench --cpuset-cpus 0,1 centos:bench /bin/sh -c 'time sysbench --threads=2 --events=4 --cpu-max-prime=8005 --verbosity=0 cpu run'
real 0m0.053s
user 0m0.023s
sys 0m0.017s
上のCPU2個対下のCPU1個。
docker run -it --rm --name mybench --cpuset-cpus 0 centos:bench /bin/sh -c 'time sysbench --threads=2 --events=4 --cpu-max-prime=8005 --verbosity=0 cpu run'
real 0m0.066s
user 0m0.025s
sys 0m0.023s
Docker --cpuset-cpusのトレーニングが完了しました。
sysbenchのトレーニングを開始しました: centos:benchコンテナに実行し、sysbench --helpを実行してトレーニングを継続します。
--cpu-shares Sysbenchを使う
先ほど、2つのスレッドを使用して0.277秒で動作することを確認しました。
docker run -it --rm --name mybench --cpus 1 centos:bench /bin/sh -c 'time sysbench --threads=2 --events=4 --cpu-max-prime=100500 --verbosity=0 cpu run'
相対的なCPU時間の共有比率だけをテストしたいので、1スレッドで十分です。
相対的な CPU 時間の共有率をテストしたいだけなので、1 CPU で十分です。
実行1：別のシェルを起動して実行します。
for var in `seq 1 20`; do docker stats --no-stream ; done
オリジナルのシェル:
docker run -d --name mybench100 --cpus 1 --cpu-shares=100 centos:bench /bin/sh -c 'for var in `seq 1 10`; do time sysbench --threads=1 --events=4 --cpu-max-prime=50500 --verbosity=0 cpu run ; done'
docker run -d --name mybench500 --cpus 1 --cpu-shares=500 centos:bench /bin/sh -c 'for var in `seq 1 10`; do time sysbench --threads=1 --events=4 --cpu-max-prime=50500 --verbosity=0 cpu run ; done'
docker run -d --name mybench1024 --cpus 1 --cpu-shares=1024 centos:bench /bin/sh -c 'for var in `seq 1 10`; do time sysbench --threads=1 --events=4 --cpu-max-prime=50500 --verbosity=0 cpu run ; done'
docker stats は 1 つのコンテナの実行をキャッチしていません。
さらに重要なのは、share=500 が起動する前に shares=100 が終了してしまったことです。3つのコンテナを同時に実行させることを考えています。-cpu-shares - 各コンテナの設定に基づいて、比例して CPU を共有するようにしたいのです。
新しいアプローチ: 各コンテナを同じ時間までスリープさせ、その後、すべてのコンテナが同時にベンチマークを実行します。以下の sleep コマンドに注意してください。
実行 2: 別のシェルを起動して実行します。
for var in `seq 1 20`; do docker stats --no-stream ; done
直後のオリジナルシェル:
docker run -d --name mybench100 --cpu-shares=100 centos:bench /bin/sh -c 'sleep 4; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench200 --cpu-shares=200 centos:bench /bin/sh -c 'sleep 3; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench300 --cpu-shares=300 centos:bench /bin/sh -c 'sleep 2; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench600 --cpu-shares=600 centos:bench /bin/sh -c 'for var in `seq 1 4`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
これは2秒だけの有用な出力を提供しています。
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
d3744f5a52ee mybench600 94.14% 1.23MiB / 985.2MiB 0.12% 508B / 0B 13.1MB / 0B 0
5c694381ef2f mybench300 50.96% 1.34MiB / 985.2MiB 0.14% 508B / 0B 12.4MB / 0B 0
8894176a9b72 mybench200 34.10% 1.215MiB / 985.2MiB 0.12% 508B / 0B 12.4MB / 0B 0
8b783befba46 mybench100 15.71% 1.223MiB / 985.2MiB 0.12% 578B / 0B 12.4MB / 0B 0
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
d3744f5a52ee mybench600 93.73% 1.348MiB / 985.2MiB 0.14% 578B / 0B 13.1MB / 0B 0
5c694381ef2f mybench300 55.25% 1.219MiB / 985.2MiB 0.12% 578B / 0B 13.1MB / 0B 0
8894176a9b72 mybench200 33.25% 1.223MiB / 985.2MiB 0.12% 578B / 0B 12.4MB / 0B 0
8b783befba46 mybench100 16.21% 1.227MiB / 985.2MiB 0.12%
CPU % は指定した --cpu-shares と一致します。
--cpu-shares はコンテナの CPU リソースを利用可能なすべての CPU サイクルに対して優先的に使用します。上記のテストでは、テスト実行中に200% = ALL CPUリソースを使用しています。8コアや16コアのサーバーを使用している場合は、このようなことはしたくないでしょう。
実行3の目的: テスト実行を1つのCPUに限定する。サーバー構成に基づいて、任意のCPU番号を選択してください。
run 3: 別のシェルを起動して実行します。
for var in `seq 1 20`; do docker stats --no-stream ; done
直後のオリジナルシェル:
docker run -d --name mybench100 --cpuset-cpus 0 --cpu-shares=100 centos:bench /bin/sh -c 'sleep 4; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench200 --cpuset-cpus 0 --cpu-shares=200 centos:bench /bin/sh -c 'sleep 3; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench300 --cpuset-cpus 0 --cpu-shares=300 centos:bench /bin/sh -c 'sleep 2; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench600 --cpuset-cpus 0 --cpu-shares=600 centos:bench /bin/sh -c 'for var in `seq 1 4`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
期待される出力:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
61a4f3d31614 mybench600 49.88% 1.215MiB / 985.2MiB 0.12% 648B / 0B 13.1MB / 0B 0
199ee60e6e1d mybench300 24.92% 1.348MiB / 985.2MiB 0.14% 648B / 0B 13.1MB / 0B 0
ee9b719a6d88 mybench200 16.77% 1.23MiB / 985.2MiB 0.12% 648B / 0B 12.4MB / 0B 0
016fc5d86d68 mybench100 8.26% 1.227MiB / 985.2MiB 0.12% 648B / 0B 12.4MB / 0B 0
成功しました。全体的に100%のCPUパワーを使用しました(2つのCPUのうち1つは200%)。
実行4：
別のアプローチ：コンテナのCPUパワーを10%に制限し、その中でCPUシェアを指定通りに分配させたいと思います。以下の出力を参照してください。
残念ながら、これはうまくいきません。
docker run -d --name mybench100 --cpus .1 --cpu-shares=100 centos:bench /bin/sh -c 'sleep 2; for var in `seq 1 4`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench200 --cpus .1 --cpu-shares=200 centos:bench /bin/sh -c 'sleep 2; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench300 --cpus .1 --cpu-shares=300 centos:bench /bin/sh -c 'sleep 1; for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
docker run -d --name mybench600 --cpus .1 --cpu-shares=600 centos:bench /bin/sh -c 'for var in `seq 1 3`; do time sysbench --threads=1 --events=4 --cpu-max-prime=500500 --verbosity=0 cpu run ; done'
--cpus .1 は --CPU-shares の設定を上書きします。各コンテナは10%のCPUを使用します。
docker stats --no-stream output
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
d1efffa6b398 mybench600 9.98% 1.223MiB / 985.2MiB 0.12% 648B / 0B 13.1MB / 0B 0
e5761b1fd9ae mybench300 9.94% 1.227MiB / 985.2MiB 0.12% 648B / 0B 13.1MB / 0B 0
d25746948b3d mybench200 9.95% 1.348MiB / 985.2MiB 0.14% 648B / 0B 13.1MB / 0B 0
9003482281bd mybench100 9.94% 1.227MiB / 985.2MiB 0.12%
––cpuset-mems
Opterons や Nelahem Xeons などの NUMA アーキテクチャを持つサーバーでのみ動作します。
実行を許可するメモリノード (MEM) を指定します (0-3, 0, 1)
私はハイエンドサーバを持っていないので、これらのオプションは使えませんでした。基本的にcpusetは以下のように使えます。
- --cpuset-cpusは非NUMAサーバで使用します。
- NUMAサーバでは --cpuset-mems を使用します。
ストレスベンチツールを使用した––memory と--memory-swap (スワップ不可)
コンテナを実行し、RAMを制限: --memory=20m --memory-swap=20m
dockerコンテナの実行 -ti --rm --memory=20m --memory-swap=20m --name memtest centos:bench /bin/sh
sh-4.2# シェルプロンプトに示すようにコマンドを入力します。
構文は以下の通りです。
stress --vm 1 --vm-bytes 18M
- 1人のvmワーカーを割り当てます。
- 18 MB の RAM を割り当てます。
sh-4.2# stress --vm 1 --vm-bytes 18M
stress: info: [50] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
これは、指定された --memory=20m の制限内にあるので動作します。
CTRL-cを押してストレステストを終了します。
sh-4.2# stress --vm 1 --vm-bytes 19M
stress: info: [53] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: FAIL: [53](415) <-- worker 54 got signal 9
stress: WARN: [53](417) now reaping child worker processes
stress: FAIL: [53](451) failed run completed in 0s
コンテナがRAM切れのため、19MB RAMの割り当てに失敗しました。( コンテナ自体がいくつかの起動時のオーバーヘッド RAM を使用しています)
ストレスヘルプを読む。
sh-4.2# stress
--vm-hang N sleep N secs before free (default none, 0 is inf)
現在、RAMを割り当てると、高速ループで割り当てられ、CPU時間を100%消費します。この vm-hang オプションを使用して、stress が xxx 秒ごとに RAM を割り当てるようにすることができます。
残念ながら、以前のクラッシュでは一部のRAMを使用していたため、18Mのテストでも同様にクラッシュしてしまいました。
そのため、17 MB の RAM 割り当てを使用してください。
sh-4.2# stress --vm 1 --vm-bytes 17M
stress: info: [64] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
別のシェルを開いて、RESまたはSHRでソートを実行すると、100% CPUを使用してリストの一番上の近くにストレスを見つけることができるはずです。
ここで実行します。
sh-4.2# stress --vm 1 --vm-bytes 17M --vm-hang 3
stress: info: [70] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
トップでは、CPU使用量が大幅に減少しています。
最終テスト:
sh-4.2# stress --vm 1 --vm-bytes 30M --vm-hang 3
stress: info: [72] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: FAIL: [72](415) <-- worker 73 got signal 9
stress: WARN: [72](417) now reaping child worker processes
stress: FAIL: [72](451) failed run completed in 0s
sh-4.2# exit
このコンテナには20MBのRAMしかないので、ストレスで失敗します。
--memoryと--memory-swapは同じ意味でスワップは許可されていないので、ストレスは失敗します。
まとめ : コンテナを制限するために --memory = --memory-swap を設定 : スワップは許可されない
ベンチツールを使ってDockerイメージを作成してしまえば、これらのテストをいかに簡単に素早く行うことができるかに注目してください。
ストレスベンチツールを使用した --memory と --memory-swap (スワップ可能)
コンテナを実行し、RAMを制限: --memory=20m --memory-swap=30m
上記のオプションでは、コンテナのスワップを10MBに制限しています。
docker container run -ti --rm --memory=20m --memory-swap=30m --name memtest centos:bench /bin/sh
sh-4.2# シェルプロンプトに表示されているようにコマンドを入力します。
sh-4.2# stress --vm 1 --vm-bytes 25M --vm-hang 3
stress: info: [9] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
25 MB の割り当てがうまくいく - 5 MB 以上のスワップを使用しています。
別のシェルで top を使用します。swap列を表示します。スワップを使ったストレスに注意。
Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.3 us, 4.9 sy, 0.0 ni, 83.5 id, 11.1 wa, 0.0 hi, 0.2 si, 0.0 st
MiB Mem : 985.219 total, 460.227 free, 166.090 used, 358.902 buff/cache
MiB Swap: 1499.996 total, 1492.684 free, 7.312 used. 636.930 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND SWAP
2565 root 20 0 32.3m 18.0m S 9.0 1.8 0:24.97 stress 7.1m
CTRL-cでストレスランを終了します。
sh-4.2# stress --vm 1 --vm-bytes 35M --vm-hang 3
stress: info: [11] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: FAIL: [11](415) <-- worker 12 got signal 9
stress: WARN: [11](417) now reaping child worker processes
stress: FAIL: [11](451) failed run completed in 0s
sh-4.2# exit
RAMを全体的に確保しようとすると、予想通りに失敗します。
--memory=20m --memory-swap=30m
予想通り、10MBのスワップ制限内でRAMを割り当てても問題ありません。
––memory-swap 未設定
memory-swap が未設定で --memory が設定されている場合、ホストコンテナにスワップメモリが設定されている場合、コンテナは --memory 設定の 2 倍のスワップを使用することができます。例えば、--memory="300m" で --memory-swap が設定されていない場合、コンテナは 300m のメモリと 600m のスワップを使用することができます。
実際に見てみましょう。
コンテナを実行し、RAMを制限: --memory=20m --memory-swap UNSET
ドキュメントに基づいて、私たちのコンテナは、tpにアクセスできるようにする必要があります。
docker container run -ti --rm --memory=20m --memory-swap=30m --name memtest centos:bench /bin/sh
sh-4.2# シェルプロンプトに表示されているようにコマンドを入力します。
sh-4.2# stress --vm 1 --vm-bytes 35M --vm-hang 3
stress: info: [9] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
^C
上記：メモリ設定の2倍以下の割り当てが動作します。
sh-4.2# stress --vm 1 --vm-bytes 38M --vm-hang 3
stress: info: [11] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
stress: FAIL: [11](415) <-- worker 12 got signal 9
stress: WARN: [11](417) now reaping child worker processes
stress: FAIL: [11](451) failed run completed in 1s
上記: メモリ設定の2倍以上の割り当ては失敗します。重要: コンテナの他のRAMオーバーヘッドを考慮してください。
sh-4.2# stress --vm 1 --vm-bytes 37M --vm-hang 3
stress: info: [13] dispatching hogs: 0 cpu, 0 io, 1 vm, 0 hdd
^C
上記: メモリを2回に分けて確保する設定が動作しますが、既に確保されている他のRAM(この場合は3MB)を考慮すると、2回に分けて確保した方が良いでしょう。
sh-4.2# exit
読み出し/書き込み : IOレート制限
これらの設定により、コンテナのIOレートを制限することができます。
- --デバイスからの読み取り速度（毎秒バイト）を制限します。
- --device-read-iops デバイスからの読み取り速度を制限する (IO per second)
- --device-writebps デバイスへの書き込み速度を制限する (bytes per second)
- --device-write-iops デバイスへの書き込み速度を制限する (IO per second)
- --io-maxbandwidth システムドライブの最大IO帯域幅制限 (Windowsのみ)
- --io-maxiops システムドライブの最大IOps制限 (Windowsのみ) 見ての通り、最後の2つはWindows専用です。ここでは、デバイス書き込みbpsに適用されているのと同じ原理を使って簡単にテストできるので、ここでは取り上げません。
構文:
--dev-write-bps /dev/your-device:IO-rate-limit (例: 1mb)
このチュートリアルでは、名前付きボリュームは使用しません。事前に固定された割り当て済みのデバイス名を用意しておけば、もう少し簡単になるでしょう。
残念ながら、レート制限を設定する前に、コンテナのデバイスマッパー論理デバイス番号を決定する必要があります。しかし、この番号を取得できるのはコンテナが起動してからです。
Dockerはデバイスマッパー論理デバイス番号をアノンボリュームに順次割り当てます。
そのため、コンテナを起動し、その番号を覗いてからコンテナを終了しなければなりません。
そして、再度コンテナを起動することができます - 今度は --device-write-bps の設定でこの番号を使用します。
このようにするとわかりやすくなります。
実行:
df -h
リストの一番下を観察してください。
実行:
docker run -it --rm alpine:3.8 /bin/sh
これで、新しい dm 番号が割り当てられたコンテナが稼働しています。
別のシェルで実行します。
df -h
割り当てられた新しいdm番号をリストの一番下に見つけられますか？それはあなたが必要とする番号です。
前のシェルに戻って、コンテナを終了するには exit を入力します。rm はコンテナが自動的に自爆することを意味します。
9999を自分の番号に置き換えてください。
私はCentOS 7をイメージとして使用しています。おそらく、すでにダウンロードしたDebian / Ubuntuのイメージを使うことができます。
Alpineは使えません - ddコマンドはoflagオプションをサポートしていません。
docker run -it --rm --dev-write-bps /dev/dm-9999:1mb centos:7 /bin/sh
表示されているようにddコマンドを入力します。
sh-4.2# time dd if=/dev/zero of=test.out bs=1M count=10 oflag=direct
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 10.0027 s, 1.0 MB/s
real 0m10.009s
user 0m0.001s
sys 0m0.015s
sh-4.2# exit
exit
dd コマンドは、10 MB のゼロを test.out ( if = 入力ファイル、of = 出力ファイル ) にコピーします。
実数は壁時計の時間で、1MB/s×10秒＝10MBをコピーしています。
--device-write-bpsは動作します。データ書き込み速度は指定した通りに制限されます。
コンポーズファイルのリソース制限
このチュートリアルでは、簡単なRUNコマンドの設定を使ってCPUとRAMのリソース制限を体験していただいただけです。
コンポーズファイルのリソース制限については、ドキュメントを参照してください。
https://docs.docker.com/compose/compose-file/#resources
https://docs.docker.com/compose/compose-file/compose-file-v2/#cpu-and-other-resources
--cap-add=sys_nice
構文:
renice [-n] priority process-pid
reniceは、1つ以上の実行中のプロセスのスケジューリングの優先度を変更します。
最初の引数は使用する優先度の値です。
他の引数はプロセスIDとして解釈されます。
コンテナ内のプロセスは、デフォルトでは優先度を変更することができません。というエラーメッセージが表示されます。
sh-4.2# renice -n -10 1
renice: failed to set priority for 1 (process ID): Permission denied
コンテナを --cap-add=sys_nice で実行すると、スケジューリングの優先度を変更できるようになります。
docker run -it --rm --name mybench --cap-add=sys_nice centos:bench /bin/sh
sh-4.2# renice -n -10 1
1 (process ID) old priority 0, new priority -10
sh-4.2# renice -n -19 1
1 (process ID) old priority -10, new priority -19
sh-4.2# renice -n 19 1
1 (process ID) old priority -19, new priority 19
sh-4.2# exit
exit
上記の構文に基づいて、pid = 1でプロセスのスケジューリング優先度を変更しています。
reniceの後に別のシェルでtopを使用します。優先度の列でソートします。変更された優先度のshプロセスを簡単に見つけることができるはずです。
幸いなことに、私たちのコンテナはCPU集約的な作業をしていないので、優先度を弄っても開発サーバを使っている他の人には何の影響もありません。
結論
このチュートリアルシリーズでは、様々なDockerのリソース制限コマンドを探索し、実験してきました。これらのツールは再現性のある結果が得られるように特別に設計されているので、sysbenchや stressなどの実際のLinuxベンチマークツールを使うべきです。
あとは、コンテナ化された本番アプリケーションのために定義したい正しいCPU、RAM、IO制限を決定するのはあなた次第です。良好に動作するアプリケーションに制限をかける必要はありません。実績のあるリソース・ホグスを制限することに努力を集中してください。
アリババクラウドは日本に２つのデータセンターを有し、世界で60を超えるアベラビリティーゾーンを有するアジア太平洋地域No.1(2019ガートナー)のクラウドインフラ事業者です。
アリババクラウドの詳細は、こちらからご覧ください。
アリババクラウドジャパン公式ページ