TOP
＞
設計・移行・活用
＞ chatベンチ
OSS適用システムの障害解析ツール
第４回：MIRACLE LINUXによる実践的なLKSTの利用
著者：
ミラクル・リナックス 武田 保真
2005/7/5
前のページ
1
2
3
4
次のページ
chatベンチ
chatベンチは、ネットワークを経由したサーバ／クライアント間のメッセージ交換の性能を測定するためのツールである。今回の計測では、同一サーバ内でサーバとクライアントを起動し、ループバックデバイス（127.0.0.1）経由でメッセージ交換を行い、性能測定を行った。
http://lbs.sourceforge.net/chat/chat-1.0.1.tar.gz
図4はchatベンチの測定結果の実行時間とスループットを表している。
図4：chatベンチの測定結果
dbench
dbenchは、Netbenchが発行するI/O要求を模して、ローカルファイルシステムに対してI/Oを発行してスループットを計測するベンチマークである。さらにdbenchは複数クライアントからの同時接続を想定した負荷を発生させることも可能である。
ftp://ftp.samba.org/pub/tridge/dbench/dbench-3.03.tar.gz
図5：dbenchの測定結果
オーバーヘッドのまとめ
5パターンのベンチマーク結果をまとめると、次の順でオーバーヘッドが増加している。
No LKST ＜ LKST norec ＜ LKST nolock ＜ LKST logtools ＜ LKST ALL
この順番は、LKSTでデータを取得するフックポイントの数の増加と一致している。これはLKSTを組み込むことによるオーバーヘッドが、カーネル内部のフックポイント通過時にイベントを記録することによって生じているためである。そのため、イベントの記録が多くなるほど、オーバーヘッドは増加していく。
Kernelビルドのベンチマーク結果では、"system time"の消費時間のみ増加して、"user time"は増加していない。これは、前述の通りカーネル内部でイベントの記録を行うためである。
また、図3に表したように、Kernelビルドのベンチマークでは、全体の処理時間に対して、LKSTを有効にした際の"system time"の消費時間の増加は非常に小さい。
一方で、chatベンチやdbenchのベンチマーク結果では、Kernelビルドと比較すると、明確なオーバーヘッドが計測されている。これは、chatベンチやdbenchがマイクロ・ベンチマークと呼ばれる種類のベンチマークであり、特定の処理やシステムコールを可能な限り繰り返すため、今回の計測方法において、非常に頻繁にイベントの記録が発生したと考えられる。
これらの結果より、LKST性能評価機能の一般的なアプリケーションに対するオーバーヘッドは、マイクロ・ベンチマークによる計測結果よりは、Kernelビルドの計測結果に近い結果となると考えられる。
LKST利用のテクニック
前述のように、性能評価機能のオーバーヘッドは、取得するイベントの数によって増減する。また、記録したイベントを保存するカーネル内部のバッファは有限であり、バッファが無くなると、古いイベントのデータから上書きされる。
つまり、不要なイベントの記録は、オーバーヘッドの増加、対象イベントの記録数の減少につながり、何の利点も得られない。
そこで、実際の解析でLKSTを使ってデータを取得する際に重要な2つのテクニックを紹介しておく。
前のページ
1
2
3
4
次のページ
著者プロフィール
ミラクル・リナックス株式会社 武田 保真
2001年入社。「MIRACLE LINUX Standard Edition V1.1」から製品開発に携わり今に至る。Samba、Kernelなどのパッケージメンテナンスを経て、最近はAsianuxプロジェクトでの製品開発が主な業務。気になったことにはすぐ手を出すために、一時期はインストーラも担当していたほど、ミラクルの何でも屋担当。
INDEX
第4回：MIRACLE LINUXによる実践的なLKSTの利用
はじめに
LKSTのオーバーヘッド
chatベンチ
フックポイントの絞りこみ
