hibomaのはてなダイアリー このページをアンテナに追加 RSSフィード

 

2014::04::08

CentOS6.5 の libcgroup のバグレポートを出した

CentOS6.5 の libcgroup の template 記法にバグがあったのを、再現方法をまとめて CentOS Bug Tracker に報告してみました。

どんな形式でレポートしたら受理されやすいのか空気が分からないのですが、問題はシンプルで libcgroup を新しくするだけで直るものなのです。何かしらのレスポンスがあるといいなぁと期待しています

VirtualBox + CentOS6.5 + Mac で 仮想CPUの数を増やすと SSHシェル操作が遅い - その3

前回の続きです 。 clocksource を変えるとシェルのキーボート操作が改善したのが前回の話でした。

デフォルトクロックソース (acpi_pm) で 1秒ごとに date を実行するシェルコマンドを試した所、ときおり秒数が飛んでいます。不安定なのが分かります

[vagrant@vagrant-centos65 ~]$ while true; do date; sleep 1; done;
Tue Apr  8 13:17:51 UTC 2014
Tue Apr  8 13:17:52 UTC 2014
Tue Apr  8 13:17:53 UTC 2014  
Tue Apr  8 13:17:55 UTC 2014  # 次は1秒後と思ったら2秒後だった。ポルナレフもびっくり
Tue Apr  8 13:17:56 UTC 2014
^C

acpi_pm 関連で VirtualBox のチケットを探していたら https://www.virtualbox.org/ticket/3135 が見つかりました。随分と古いオープンされているチケットで一応クローズされていますが まだ解決しとらんというコメントが追加されています。

チケットの中には ↓ をカーネルブートオプションに入れると諸症状が改善したとあります。確かによい感じ

divider=10 nolapic_timer

だいぶ根が深い問題なようですね

2014::04::06

libcgroup-0.40.rc1-5.el6_5.1.x86_64 の template 記法バグ の続き

http://d.hatena.ne.jp/hiboma/20140406/1396715760 の続きです


git リポジトリからバグを探す

git clone git://git.code.sf.net/p/libcg/libcg してバグが修正されたコミットを探していました。

どうやら下記のコミットで修正されたようです (このコミットの前後で serverspec の挙動が変わる)

  • tempalte の記法で %u %g %p と大文字の %U %G %P のフォーマットが使えるのだが
  • それぞれが逆に取り違えて実装されていた ...
commit 83248a9edad920e1ceb879bc26ef155a9554617c
Author: Peter Schiffer <pschiffe@redhat.com>
Date:   Mon Oct 14 08:43:24 2013 +0200

    Templates letter case is switched
    
    Man page cgrules.conf(5) says:
         %u     username, uid if name resolving fails
         %U     uid
         %g     group name, gid if name resolving fails
         %G     gid
         %p     process name, pid if name not available
         %P     pid
    
    However, in cgroup_change_cgroup_flags() function, the letter case is switched.
    This patch fixes the problem.
    
    Signed-off-by: Peter Schiffer <pschiffe@redhat.com>
    Acked-by: Ivana Hutarova Varekova <varekova@redhat.com>

diff --git a/src/api.c b/src/api.c
index ba97768..38314fb 100644
--- a/src/api.c
+++ b/src/api.c
@@ -2933,11 +2933,11 @@ int cgroup_change_cgroup_flags(uid_t uid, gid_t gid,
 				available = FILENAME_MAX - j - 2;
 				/* Substitution */
 				switch(tmp->destination[++i]) {
-				case 'u':
+				case 'U':
 					written = snprintf(newdest+j, available,
 						"%d", uid);
 					break;
-				case 'U':
+				case 'u':
 					user_info = getpwuid(uid);
 					if(user_info) {
 						written = snprintf(newdest + j,
@@ -2948,11 +2948,11 @@ int cgroup_change_cgroup_flags(uid_t uid, gid_t gid,
 							available, "%d", uid);
 					}
 					break;
-				case 'g':
+				case 'G':
 					written = snprintf(newdest + j,
 						available, "%d", gid);
 					break;
-				case 'G':
+				case 'g':
 					group_info = getgrgid(gid);
 					if(group_info) {
 						written = snprintf(newdest + j,
@@ -2963,11 +2963,11 @@ int cgroup_change_cgroup_flags(uid_t uid, gid_t gid,
 							available, "%d", gid);
 					}
 					break;
-				case 'p':
+				case 'P':
 					written = snprintf(newdest + j,
 						available, "%d", pid);
 					break;
-				case 'P':
+				case 'p':
 					if(procname) {
 						written = snprintf(newdest + j,
 							available, "%s",

単純だけど厄介なバグですね

libcgroup-0.40.rc1-5.el6_5.1.x86_64 の template 記法バグ

CentOS6.5 の libcgroup-0.40.rc1-5.el6_5.1.x86_64 で、 /etc/cgconfig.conf と /etc/cgrules.conf に template 記法 を使ってみたところ意図しない挙動になりました。どうもバグがあるようです

template についての詳細は man cgconfig.conf もしくは man cgrules.conf でご確認ください :)


/etc/cgconfig.conf

下記のように設定しています

  • template 記法を使用
  • /cgroup/{cpu,cpuset,memory}/vagrant/ に制限を入れる
mount {
        cpuset  = /cgroup/cpuset;
        cpu     = /cgroup/cpu;
        cpuacct = /cgroup/cpuacct;
        memory  = /cgroup/memory;
        devices = /cgroup/devices;
        freezer = /cgroup/freezer;
        net_cls = /cgroup/net_cls;
        blkio   = /cgroup/blkio;
}

template %u {
    cpu {
        cpu.cfs_quota_us = 50000;
    }
    cpuset {
        cpuset.mems = 0;
        cpuset.cpus = 0;
    }
    memory {
        memory.limit_in_bytes       = 104857600;
        memory.memsw.limit_in_bytes = 104857600;
    }
}

/etc/cgrules.conf

下記のように設定しています

  • template 記法を使用
  • vagrant ユーザは /cgroup/{cpuset,cpu,memory}/vagrant/ で制限を課す
  • 他のユーザは特に何もしない
# /etc/cgrules.conf
#The format of this file is described in cgrules.conf(5)
#manual page.
#
# Example:
#<user>         <controllers>   <destination>
vagrant         cpuset,cpu,memory  %u
*               *                  default

yum install した libcgroup-0.40.rc1-5.el6_5.1.x86_64 で動作させた場合

うーん 設定ファイルに指定した値と違いますね

[vagrant@vagrant-centos65 ~]$ cat /cgroup/cpu/vagrant/cpu.cfs_quota_us
-1

[vagrant@vagrant-centos65 ~]$ cat /cgroup/memory/vagrant/memory.limit_in_bytes
9223372036854775807

[vagrant@vagrant-centos65 ~]$ cat /cgroup/memory/vagrant/memory.memsw.limit_in_bytes
9223372036854775807

libcgroup-0.41 で動作させた場合

libcgroupの現時点の最新バージョンは 0.41 なので、設定ファイルは変えずに libcgroup だけアップグレードしてみます (方法は後述)

[vagrant@vagrant-centos65 ~]$ cat /cgroup/cpu/vagrant/cpu.cfs_quota_us
50000
[vagrant@vagrant-centos65 ~]$ cat /cgroup/memory/vagrant/memory.limit_in_bytes
104857600
[vagrant@vagrant-centos65 ~]$ cat /cgroup/memory/vagrant/mmemory.memsw.limit_in_bytes
104857600

おお 変わった!あんれー それじゃ libcgroup のバグなのかな ...


バグの検証方法

Vagrantfile と serverspec を用意していますので、下記の手順に従うと再現できます

また spec 以下に serverspec を用意していて、cgroup が設定ファイルに記述した値になっているかどうかをテストします

  • vagrant のセットアップ
git clone https://github.com/hiboma/vagrant-inspect-libcgroup.git
cd vagrant-inspect-libcgroup
bundle install
vagrant up

  • libcgroup-0.40.rc1-5.el6_5.1.x86_64 での動作確認
# yum install した libcgroup でセットアップ + serverspec する
vagrant provision && bundle exec rake spec

sererspec のテストがコケるはずです


  • libcgroup-0.41 での動作確認
# libcgroup-0.41 でセットアップ + serverspec する
LIBCGROUP_VERSION=0.41 vagrant provision && bundle rake spec

0.41 をインストールして使います。serverspec のテストが通るはずです。


イマココ

ということで、どこで挙動が変わったのかコミットログを追っています

このエントリに記述した結果とは違う結果になった、もしくはお前の設定の記述に不備があるんじゃね!?等ありましたらコメントお待ちしています


感想

rc 付きのバージョンをパッケージとして出しちゃまずいのかなと思いました。ディストリビューションに詳しい方のご意見をうかがってみたい!

2014::03::30

VirtualBox + CentOS6.5 + Mac で 仮想CPUの数を増やすと SSHシェル操作が遅い - その2

前回の続きエントリ です

https://blogs.oracle.com/LetTheSunShineIn/entry/running_perf_top_on_virtualbox に書かれていた設定にすると smp_affinity を変えなくてもシェルプロンプトのキー操作のレスポンスが改善しました

I thought high kernel CPU was caused by "acpi_pm_read". I googled and got some hints and
shut down the VM and changed the setting.

$ vboxmanage modifyvm Node01 --hpet on
$ vboxmanage modifyvm Node01 --acpi off

カーネルクロックソースACPI から HPET にするとのことです。


Vagrantfile だとどう書くの?

Vagrantfile だと下記のように設定します

  config.vm.provider :virtualbox do |vb|
    vb.customize ["modifyvm", :id, "--cpus", 4]      # 適当に CPU 増やす
    vb.customize ["modifyvm", :id, "--hpet", "on"]   # ↑ のブログに書いてある
    vb.customize ["modifyvm", :id, "--acpi", "off"]  # ↑ のブログに書いてある
  end

上記ブログの内容は、私が調べているのとはまた別の問題のようですが ボトルネックの原因はおんなじなのかなー。HPET と ACPI の説明は 本の虫: 100ナノ秒ぐらいの分解能をもつクロック実装 が分かりやすいなと思いました。


perf で調べてみてます

この設定によってどんな風にボトルネックが解消されたのかを perf で調べてみてるのですが 難しくて分かりません ... https://gist.github.com/hiboma/9865994 に perf の結果をつらつらと並べています 。何か分かったら続きを書きます


追記

/sys/devices/system/clocksource/clocksource0/current_clocksource でクロックソースを確認できるのを思い出したので調べてみました


hpet on + acpi off

オラクルブログさんに書いてあった hpet on + acpi off 設定ではクロックソースが jiffies になってますね。aれー hpet であるべきだと思うんだけど、これでいいんだろうか?

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
jiffies

hpet on + acpi on

試しに hpet on + acpi on にしてみると hpet になりました。キー操作は快適です

$ echo hpet | sudo tee /sys/devices/system/clocksource/clocksource0/current_clocksource 
hpet

hpet on + acpi on の時は acpi_pm も使えるようです。available_clocksource で選択できるクロックソースを確認できます

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
hpet acpi_pm 

acpi_pm に変えると、もたつくような … perf で計測せねばー

$ echo acpi_pm | sudo tee /sys/devices/system/clocksource/clocksource0/current_clocksource 
acpi_pm

デフォルトでは acpi_pm がもっさりの原因

Vagrantfile で特に何もいじらない場合デフォルトで hept off + acpi on となっており、クロックソースは acpi_pm となります(デフォルト)。これがもっさり原因のようです。

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
acpi_pm

acpi_pm だとなんで駄目なんかなー