前回に引き続いて、dstat その二です。

Linux には、kernel 2.6.20 以降から、IO Accounting という機能が組み込まれています。この機能は、簡単に言ってしまうと、各プロセスごとの IO 情報をカウントしてくれる機能です。この機能があると、プロセスごとの I/O が分かるので、どのプロセスが原因で I/O が重いとかが分かるようになります。

普段使っている CentOS 5.x 系は kernel 2.6.18 系なのですが、RHEL 5.4 のリリースノートをよく見てみると、次のような記述がありました。

・ストレージ/ファイルシステム関連のアップデート:
BlktraceによりブロックIOレイヤでのトレース機構を提供します。I/O accountingによりプロセスごとの実際のIOのアカウンティングが可能になりました。一般ユーザーが独自のファイルシステムを作成できるFUSE (Filesystems in user space) のカーネル基盤とユーティリティを提供します。

ということで、最新リリースである CentOS 5.4 でも対応しているようです。

前回紹介した dstat では、バージョン 0.6.7 以降から、dstat_topio という拡張プラグインが組み込まれて、この IO Accounting の機能にアクセスことができます。

CentOS で、公式で提供されているのはバージョン 0.6.6 なので、この機能を利用することはできません。なので、ソースコードをダウンロードして RPM を作ります。

$ wget http://dag.wieers.com/home-made/dstat/dstat-0.6.9.tar.bz2

$ rpmbuild -ta dstat-0.6.9.tar.bz2

dstat の tarball には、SPEC ファイルが含まれているので RPM をすぐに作成することができます。RPM を作成したら、CentOS 5.4 の環境にアップグレードするかインストールします。

次に dstat_topio という拡張プラグインを使うには、次のように実行します。

$dstat -M topio -d -M topbio

—-most-expensive—- -dsk/total- —-most-expensive—-
i/o process                   | read  writ        |  block i/o process
init        275k:1490k    | 396k 3375k    |  init         62k:1380k
mysqld       84k:  46k  |  96k  792k      |   kjournald     0 : 132k
mysqld      107k:  30k | 192k  232k      |  mysqld       48k:  24k
mysqld       95k:  29k  | 192k  272k     |  mysqld       80k:  36k

このように各プロセスごとの I/O 情報を取得することができます。

ちなみに、CentOS 5.3 の環境では、次のようなエラー表示になります。

$ dstat -M topio -d -M topbio

Module topio failed to load. (Kernel has no I/O accounting, use at least 2.6.20)
Module topbio failed to load. (Kernel has no I/O accounting, use at least 2.6.20)
-dsk/total-
read  writ
58k  442k
0    24k
0     0
0   528k

ということで、必ず CentOS 5.4 の環境で使う必要があります。

この機能を使うことで、IO がボトルネックの場合、どのプロセスに原因があるのかを調査することができるので便利になりますね。

ちなみに、sar コマンドで有名な sysstat にも、バージョン 9.0 から pidstat というコマンドで同様の情報を取得することができますので、必要な人は導入してみるといいでしょう。

dstat という vmstat, iostat, netstat, nfsstat, ifstat 用の置き換えとして使える多機能ツールがあることを知ったので、CentOS でさっそく試してみました。

まず、インストール方法ですが、公式に dstat パッケージが提供されているので yum 一発でインストールすることができます。

$ sudo yum install dstat

/usr/bin/dstat にインストールされます。

dsat は多機能ツールですが、使い方は dstat –help するとたくさん表示されます。

まず、オプションを指定しないで実行してみます。

$ /usr/bin/dstat
—-total-cpu-usage—- -dsk/total- -net/total- —paging– —system–
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
2   0  96   1   0   0|  58k  441k|   0     0 | 188B  176B| 206  1473
0   0 100   0   0   0|   0     0 |3780B  974B|   0     0 |1068  2916
0   0 100   0   0   0|   0     0 |8356B 2943B|   0     0 |1070  2865

CPU、ハードディスク、ネットワーク、ページング、システム、それぞれの状態が1秒ごとにまとめてカラー表示されます。これは、なかなか分かりやすい表示です。

次に、CPU の使用率のみを表示してみます。

$ /usr/bin/dstat –cpu

—-total-cpu-usage—-
usr sys idl wai hiq siq
2   0  96   1   0   0
3   0  96   0   0   0
1   0  99   0   0   0

また、CPU の特定のコアを指定することもできます。-C オプションになるので注意してください。

$ /usr/bin/dstat -C 0,2,total
Terminal width too small, trimming output.
——-cpu0-usage————–cpu2-usage———–total-cpu-usage—->
usr sys idl wai hiq siq:usr sys idl wai hiq siq:usr sys idl wai hiq siq>
2   0  98   0   0   0:  3   0  91   5   0   0:  2   0  96   1   0   0>
2   0  98   0   0   0:  0   0 100   0   0   0:  1   0  99   0   0   0>
10   0  90   0   0   0:  3   0  97   0   0   0:  3   1  96   0   0   0

-C オプションを使うと特定のコアに偏っていないかチェックすることができます。

次に、ハードディスクの状態を表示してみます。

$ /usr/bin/dstat –disk
-dsk/total-
read  writ
58k  441k
0     0
0   700k

ディスクへの読み書きの割合が表示されます。さらに特定のハードディスクの使用状態もみることができます。

$ /usr/bin/dstat -D total,sda
—-total-cpu-usage—- –dsk/sda– -net/total- —paging– —system–
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw
2   0  96   1   0   0|  58k  441k|   0     0 | 188B  176B| 206  1473
6   1  85   9   0   1|   0  1980k|  58k   28k|   0     0 |1871  3351
5   0  70  24   0   0|   0  4868k|  49k   19k|   0     0 |2356  3511

通常の表示に加えて、各ハードディスクごとの状態を表示することができます。

次にロードアベレージを表示してみます。

$ /usr/bin/dstat –load

—load-avg—
1m   5m  15m
0.1  0.1  0.1
0.1  0.1  0.1
0.1  0.1  0.1

その他にもさまざまなリソースの状態を表示することができます。

ヘルプを翻訳すると、次のようになります。

使い方: dstat [-afv] [options..] [delay [count]]

-c, --cpu          CPU 状態表示を有効にします
  -C 0,3,total       CPU0 と CPU3 と合計を含めます
-d, --disk         ディスクの状態表示を有効にします
  -D total,hda       /dev/hda と合計を含めます
-g, --page         ページの状態表示を有効にします
-i, --int          割り込みの状態表示を有効にします
  -I 5,eth2          int5 と eht2 によって使われている割り込みを含めます
-l, --load         ロードアベレージの状態表示を有効にします
-m, --mem          メモリの状態表示を有効にします
-n, --net          ネットワークの状態表示を有効にします
-N eth1,total      eth1 と合計を含めます
-p, --proc         プロセスの状態表示を有効にします
-s, --swap         スワップの状態表示を有効にします
-t, --time         日時のカウント表示を有効にします
-y, --sys          システムの状態表示を有効にします
--ipc              IPC(Inter-Process Communication、プロセス間通信）の状態表示を有効にします
--lock             （ファイル）ロックの状態表示を有効にします
--raw              raw の状態表示を有効にします
--tcp              TCP の状態表示を有効にします
--udp              UDP の状態表示を有効にします
--unix             UNIX の状態表示を有効にします

-M stat1,stat2     外部ステータスの表示を有効にします
   --mods stat1,stat2

-a, --all          -cdngy と同じです（デフォルト）
-f, --full         -D, -I と -N のリストを拡張します
-v, --vmstat       -pmgdsc -D total と同じです

--integer          整数値を表示します
--nocolor          カラー表示を無効にします
--noheaders        ヘッダー表示を無効にします
--noupdate         仲介更新を無効にします
--output file      出力結果を CSV ファイルに書き出します

delay は更新間隔の秒数です
count は終了するまでに表示する回数です
デフォルトの delay は 1 秒で、count は無制限です

dstat を使えば、かなり分かりやすくシステムリソースの使用状況が分かるツールなので、かなり重宝する定番のツールになりそうです。

Xen をがんがん利用してサーバを構築していますが、Xen Dom0/DomU のメモリを、次のように確保したところ、Dom0 のメモリが 356MB くらいになっていました。サーバの搭載メモリ容量は、8GB です。

• Dom0: 512MB
• DomU 1: 1024MB
• DomU 2: 6656MB

先日の Xen の話題でコメントをいただいた xm info をコマンドを実行してみると、free memory の欄が 0 になっていました。どうやらこれが原因で、Dom0 の貴重なメモリが減らされていたようです。

DomU のメモリ容量を調整する前に、xm info コマンドを実行しまくって、毎回確認するのがめんどうなので簡単なシェルスクリプトを作成しました。

このシェルスクリプトでは、xm info の total memory（物理搭載メモリ容量）と xen DomU の設定からメモリ容量を取得して差分を取得するだけという単純なシェルスクリプトです。8GB だと、512MB でもけっこう貴重になるので調査したところ、2048MB くらいになると free memory が 1388 くらいになって、DomU を二つ起動しても Dom0 のメモリは 512MB のままになりました。Dom0 は、512MB メモリなので、さらに 1.5GB メモリを余分に必要かと思うと、すこしもったいない気がしますが、Xen を利用するメリットの方が格段に大きいので仕方がありません。

DomU のメモリ容量を変更にするには、動的に変更する方法と、静的に変更する方法があります。
動的に変更するには、次のコマンドを実行します。

$ sudo xm mem-set <ID> <メモリ容量（MB）>

静的に変更するには、/etc/xen/<仮想マシン名> の maxmem と memory の値を変更して、DomU を shutdown / start します。

Xen をがんがん使っていますがあまり詳しくはないので、もっと勉強しなければなりません。

RPM のビルド環境を整えるとき、先日紹介した rpmdevtools を使うと、とても簡単に RPM のビルド環境を作ることができます。

具体的には、rpmdevtools に含まれている rpmdev-setuptree というコマンドを実行するだけです。

$ /usr/bin/rpmdev-setuptree

そうすると、$HOME/rpmbuild ディレクトリが作成され、次のような $HOME/.rpmmacros ファイルが作成されます。

次のファイルは、CentOS 5.3 x86_64 のときに作成される .rpmmacros です。

%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags  -j3
%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot

この設定で RPM をビルドすると、RPM を作成する直前に rpmdevtools に含まれている  check-rpaths と check-buildroot というコマンドが実行されるようになっています。

自分で RPM をビルドしてみると、パッケージによって次のようなエラーが発生することがあります。

ERROR   0004: file ‘/usr/libexec/tcawmgr.cgi’ contains an insecure rpath ‘.’ in [/lib:/usr/lib:/usr/lib64:/home/neoad/lib:/usr/local/lib:/usr/lib64:.]
error: Bad exit status from /var/tmp/rpm-tmp.4888 (%install)

このエラーは、check_rpath という実行ファイルやシェルスクリプトなどに含まれているパスをチェックするプログラムですが、このプログラムの実行でエラーになってしまいます。

例えば、次のようなエラーが表示されます。

「WARNING: ‘check-rpaths’ detected a broken RPATH and will cause ‘rpmbuild’」

このエラーを回避する方法を調べたところ、Packaging Guidelines : Fedora というページに書かれていました。このページによれば、/etc/ld.so.conf.d に自分専用の設定ファイルを作成して、その中にパスを記述するように説明がありました。さっそくやってみたのですが、エラーを回避することができませんでした。

check-rpath のエラーをよく見てみると、次のように実行すればよいという説明がありました。

$ QA_RPATHS=$[ 0x0001|0x0010 ] rpmbuild -ba $HOME/rpmbuild/SPECS/foo.spec

QA_RPATHS という変数に指定されたビットマスク値を指定すると回避できるようです。QA_RPATHS のビットマスク値は、次のような意味になります。

0×0001: 標準の RPATH（例えば /usr/lib) を含めます

0×0002: 無効な RPATH を許可します、これはセキュリティ的なリスクを含みます

0×0004: セキュアでない RPATH を許可します、これはセキュリティ的なリスクを含みます

0×0008: 特別な $ORIGIN で指定された RPATH を末尾に追加します

0×0010: RPATH を空にします

0×0020: ‘..’ のような相対パスを許可します

どうも、check-rpath というのは RPM をビルドする前にプログラムで指定されているパスをチェックして不正なパスがないかどうかチェックするプログラムのようです。

さきほどのエラーを回避するには、次のようなコマンドを実行します。

$ QA_RPATHS=$[ 0x0001|0x0002|0x0004 ] rpmbuild -ba $HOME/rpmbuild/SPECS/foo.spec

これで check-rpath でエラーを回避することはできたのですが、この方法ではそもそも check-rpath を使うように設定している意味もないので、$HOME/.rpmmacros を次のように書き換えて check-rpath を実行しないようにしました。ついでにデバッグ情報付きの RPM も作成しないように設定してあります。

— .rpmmacros-orig    2009-10-14 21:18:24.000000000 +0900
+++ .rpmmacros  2009-10-14 21:37:04.000000000 +0900
@@ -1,3 +1,4 @@
%_topdir      %(echo $HOME)/rpmbuild
%_smp_mflags  -j3
-%__arch_install_post   /usr/lib/rpm/check-rpaths   /usr/lib/rpm/check-buildroot
+%__arch_install_post   /usr/lib/rpm/check-buildroot
+%debug_package %{nil}

実はこの設定変更を前に行ったことを忘れていて、新しいサーバに RPM のビルド環境を作ったのですが、かなりはまったので備忘録として残しておきます。

# 2009.11.9 追記

• 具体的なエラーメッセージを追加しました

DELL の DRAC(DELL Remote Access Controller) という、DELL 製の IPMI カードを使っているとき、その都度 DRAC を手動で設定するのはめんどうです。

DRAC は、IP アドレスなどを設定すると、ssh や telnet でログインして DRAC の専用コマンドで設定することができます。

そこで、自動的に設定するようなシェルスクリプトを作成してみました。

このシェルスクリプトでは、次のような設定を expect を使って自動的に行います。

• DNS サーバ 1 と 2 を設定する
• DRAC の名前とドメインを設定する
• 管理者ユーザ用の E メールとカスタムメッセージを設定する
• 送信メールサーバとファームウェアアップデート用の TFTP サーバを設定する
• E メール通知を有効にする
• IPMI のシリアル通信速度を 57600bps にする
• IPMI シリアルハードウェアフロー制御を有効にする
• TELNET 接続を許可する（わざわざ TELNET 接続を許可している理由は、DRAC4 という古い DRAC の場合 SSH 接続がかなり不安定になるためです）
• SOL(Serial Over LAN) を有効にする

もちろん、実際に使うときには最初の変数を定義してから使ってください。

DRAC の制御コマンドについては、このあたりの公式ドキュメントを読むとよいと思います。

こうした IPMI カードの設定も設定方法を wiki などにまとめるだけでなくて、なるべく自動的に設定するのがとても大事だと思います。

サーバ1台あるいは、サービス全体で、いったいどのくらいのパフォーマンスがあるのかについて計測することは、とても重要なことです。

僕が管理しているサービスは、最初にサービスをはじめるときはある程度の規模感を想像しながらまとまめてサーバなどを調達しましたが、サービスを開始してすこしたってきたところで今後の投資計画をたてたいため、月ごとのトラフィックを予測して、いつごろにどのくらいのサーバなどが必要か情報を調査して計画を立てることになりました。もちろん、最初からちゃんとベンチマークを行って計測してサーバを調達したほうがいいのですが、小さい会社では最初はサービスの開発に注力したいため、なかなかそういった時間をとれないのもまた事実です。

ということで、現状のサービスのパフォーマンスを測定するために必要な CentOS 上で動作するコンソールベースのオープンソースなベンチマークツールについて調べてみました。

まずは、HTTP のベンチマークツール。

• ab: Apache HTTP Server に付属しているベンチマークツールです。これは誰もが使ったことがあると思います。シングルスレッドで動作して、同時リクエスト数と並列のリクエスト数などを指定することができます。Basic 認証や SSL もサポートされています。HTTP のベンチマークツールとしては、もっとも手頃なツールですが、あまり並列のリクエスト数を指定すると、テストサーバの負荷がかかりやすい、出力結果をファイルに出力できない、などの短所があります。
• http_load: thttpd で有名な  ACME Labs が公開しているツールです。計測対象の URL が書かれたファイルを指定することによってベンチマークを行ってくれます。2006 年とかなり古いツールですが、これも ab と同様のツールです。
• httperf: もともとは HP Labs で開発したツールですが、現在は sourceforge に移行しているようです。使い方は、このページに添付されている資料に詳しく書かれています。特徴は、同時に二つのホストに対してテストができることです。
• autobench: perl で書かれた httperf を使ったベンチマークツールです。指定された同時リクエストの範囲でテストを行って、その結果を TSV/CSV で出力して、その結果を gnuplot でグラフとして表示することができます。autobench_adimin /autobenchd を使うことによって、複数のクライアントから同時にテストを実行することができます。
• Siege: ab と同様に Basic 認証、SSL に対応したベンチマークツールです。

いつかあったのですが、この中では複数のクライアントから実行できる点、結果が TSV/CSV で出力できる点が便利な autobench を使ってみることにしました。

次に MySQL のベンチマークツール。

• DBT-2: TPC-C ライクな負荷を作り出して、細かい更新系の処理を計測したいときに使われるツールです。
• Sysbench: CPU/Memory/Thread/OLTP の各種テストができるベンチマークツールです。OLTP では、秒間あたりの処理できたトランザクション数を計測することができます。つい最近 Facebook の中の人がSysbench を拡張していました。
• skyload: tmaesaka さんが開発した、mysqlslap に比べて簡単に使えることを目的にしたツールです。

次にネットワーク間のベンチマークツール。

• netperf: IPv4/6 に対応した TCP/UDP のスループット計測ツールです。計測対象のサーバにデーモンを起動して、別のサーバからネットワークスループットを計測します。
• iperf:  netperf と同様のツールです。iperf の特徴は帯域幅が分かるところです。
• ttcp:  これも netperf と同様のツールです。

どのツールでもよさそうですが、いずれもあまり使ったことがないので全部試して、どのツールを使うか検討したいと思います。

だんだんとレイヤーが下がっていきますが、次のハードディスクのベンチマークツール。

• hdparm: -t オプションで、シーケンシャルリードの性能を測定することができます。ほとんどの Linux ディストリビューションには入っていると思います。
• dd コマンド:  dd if=/dev/zero of=/tmp/hoge.tmp ibs=1M obs=1M count=1024 などとすることにより 1GB のファイルを作成して、その時間を計測することにより、シーケンシャルライトの性能を測定することができます。
• bonnie++: シーケンシャル／ランダムのリード／ライトを測定することができます。まとめて計測することができるので便利ですが、パッチをあててコンパイルする必要があったりします。

bonnie++ で決まりですが、計測結果を TSV/CSV などに出力してもらいものですね。と思ったら、bonnie++ の書き直した実験的なリリースバージョンである 1.96（同様にパッチをあてる必要がありそうですが）では CVS が標準出力に表示されて、bon_csv2html なるプログラムで CVS から、次のような HTML に変換することができます。

最後に回線のパフォーマンスを計測しなければならないのですが、これは別のエントリにしたいと思います。

あわせて、それぞれのベンチマークツールの詳細も、別のエントリにしたいと思います。

ただし、どんなにベンチマークを計測しても、実際のリクエストとは異なるということです。仮にモバイル向けのサービスであるならば、各携帯キャリアのゲートウェイを通じてのリクエストは発生していないですし、実際の携帯でアクセスしたときのパフォーマンスとは異なるということです。とはいっても、ベンチマークをとることで、おおよその目安がつくといてどの程度サーバなどを調達すればよいのかが分かるというのは、とても重要なことです。

ベンチマークを計測するときに重要だと思っている項目をまとめておきます。

• 何をベンチマークするのか、事前に明確にしておく
• ベンチマークした結果に対して、具体的なパフォーマンス指標となる値を目標に決める
• パフォーマンスを向上させるとき、どの施策に効果があったか分かるように一つずつ施策を行い、その効果を確かめる

先日紹介した「The Art of Capacity Planning」には、次の格言がありましたので紹介しておきます。

Measure, Measure, Measure（計測せよ、計測せよ、計測せよ）

さらに冒頭には、次のようには一言がありました。

To my father, James W.Allspaw, who taught me that engineering is about getting things done, not just thinking things up.（エンジニアリングとは物事を考え出すことではなく物事を成し遂げることだということを、私に教えてくれた父、James W.Allspaw へ捧げる）

また、サーバ/インフラ本には、次の格言がありました。

推測するな、計測せよ。

どちらもすばらしい格言ですし、先日の Velocity でも施策の効果について具体的な数字で説明されていました。

この言葉を心にとめてベンチマークをとっていきたいと思います。

Happy Benchmarking!