CentOSのリソースを制御するためにcgroupを検証した話

経緯

最近読んでいる「プロのためのLinuxシステム・10年効く技術」にRedhat6以降からcgroupというリソース制御の仕組みが利用できるようになったのを拝見しました。

また、ペパボ福岡支社のインフラエンジニアの方の「次世代ホスティングの話し」にもcgroupのことが書かれていたので、せっかくなので検証してみることにしました。

 

パッケージのインストール

# yum install libcgroup

# chkconfig cgconfig on

# service cgconfig start

 

事前確認

ddでチェックしてみます。2GBのファイルを作成してみます。oflag=directでキャッシュを無効にしています。

# dd if=/dev/zero of=test.img bs=1K count=2000000 oflag=direct

# top <–別シェルで実行
Tasks: 127 total, 3 running, 124 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 2.4%sy, 0.0%ni, 0.0%id, 94.0%wa, 2.4%hi, 1.2%si, 0.0%st
Mem: 1020176k total, 305056k used, 715120k free, 6540k buffers
Swap: 1036284k total, 0k used, 1036284k free, 128060k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2175 root 20 0 102m 720 608 R 27.6 0.1 0:10.50 dd

私の環境ではデフォルトの結果として、CPU使用率は27%前後でした。

設定

# cp -p /etc/cgconfig.conf  /etc/cgconfig.conf.`date +%Y%m%d`

# vim /etc/cgconfig.conf

group yes {
cpu {
cpu.cfs_quota_us = 50000;
cpu.cfs_period_us = 1000000;
}
cpuacct {
}
}

グループ名のyesはyesコマンドでテストするためにそのようにしましたが、特に意味は無いです。

cpu.cfs_period_usの値はマイクロ秒のようで、1000000分の50000に制限するという設定です。

実行する際は、

# cgexec -g cpu:yes コマンド

っていう感じで実行します。

 

テスト

“cgexec -g cpu:yes yes”を別のシェルを4つ立ち上げて、それぞれで実行し、計4つ実行させてみました。

そして、同時にddを同じように再実行します。

[結果]
Tasks: 149 total, 7 running, 142 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.0%us, 5.4%sy, 0.0%ni, 0.0%id, 92.6%wa, 0.3%hi, 0.7%si, 0.0%st
Mem: 1020176k total, 323256k used, 696920k free, 7052k buffers
Swap: 1036284k total, 0k used, 1036284k free, 129924k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2251 root 20 0 102m 724 608 R 1.0 0.1 0:01.89 dd
2288 root 20 0 98.5m 604 516 R 1.0 0.1 0:00.43 yes
2289 root 20 0 98.5m 600 516 R 1.0 0.1 0:00.40 yes
2290 root 20 0 98.5m 600 516 R 1.0 0.1 0:00.38 yes
2327 root 20 0 98.5m 604 516 R 1.0 0.1 0:00.17 yes

 

CPUを全体の5%の中で分けあって使ってることがわかります。

このようにさっくり設定しても簡単に制御できました。

設定する値は、CPU以外にメモリや帯域、IOなども制御出来るようなので幅広い用途で使用できそうです。

特に色々記事をみていると、dockerなどで活用している事例があるようです。

実際は各サーバーやサービスなどにあわせて設定しなければいけないので、かなり検証した上で値を決定したほうが良いとは思いますが、一つ覚えておくと便利かなと思いました。

 

以上

 

CentOS6はresolv.confに「options single-request-reopen」をつけるべき?

ちょっとVagrantのことで調べ物していたところ、こんな記事を見つけました。
http://www.kunitake.org/chalow/2012-11-02-1.html

まとめると、CentOS5系の名前解決とCentOS6系からの名前解決のIPv4とIPv6の結果について、応答の順番が変わることで、名前解決に時間がかかる場合があるということです。
CentOS5系はAAAAレコード(IPv6)の要求を実行して、応答結果を受けて、その後にAレコード(IPv4)の要求->応答だったようです。
しかしCentOS6系からはAレコードとAAAAレコードを投げて、その後にそれぞれの要求が返ってくるようです。
しかし、Firewallの中には同じポートのクエリを同じセッションとみなして、IPv6が設定されていないサーバーへの応答ができないことで、IPv4の応答も返さず、Aレコードのクエリを再送するということらしいです。

なにはともわれ、検証してみることにします。

◆オプションをつける前
# cat /etc/redhat-release <–CentOS6系であることを確認
CentOS release 6.7 (Final)
# cat /etc/resolv.conf <–まずはオプション無し
nameserver 8.8.8.8
nameserver 8.8.4.4
# yum clean all <–キャッシュを削除
# time yum search php54 –enablerepo=epel,repo <–PHPを検索

※3回ともyum clean allを実施
[1回目]
real 0m9.618s
user 0m2.430s
sys 0m0.215s

[2回目]
real 0m6.825s
user 0m2.435s
sys 0m0.244s

[3回目]
real 0m9.713s
user 0m2.430s
sys 0m0.209s

◆オプションをつけた後
# echo “options single-request-reopen” >> /etc/resolv.conf
# cat /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
options single-request-reopen

[1回目]
real 0m9.984s
user 0m2.462s
sys 0m0.191s

[2回目]
real 0m9.751s
user 0m2.452s
sys 0m0.199s

[3回目]
real 0m9.676s
user 0m2.465s
sys 0m0.205s

残念ながら上記検証では効果は得られませんでした。

いくつかサイトを見たところ、juniper配下のサーバーでこの事象に遭遇したと記載があるので、juniper相手などには効果があるかもしれません。

また、さくらのVPSではデフォルトでオンになっていました。
# cat /etc/resolv.conf
# Generated by NetworkManager
search sakura.ne.jp
nameserver 210.224.163.3
options single-request-reopen

入れてデメリットになることは少ないと思うので、CentOS6以降は標準で設定すると良いかもしれません。