オープンソース・ソフトウエアで構築したシステムのトラブル原因を探り,解決するこのシリーズ,今回と次回は「システムが遅くなる」スローダウン事例の解析方法をご紹介します。今回は(その1)として,LKST(Linux Kernel State Tracer)を使ってタイマー駆動型アプリケーションの遅延原因を調べてみましょう。

 それでは前回に引き続き,若手エンジニアのタカハシくんと,先輩のスズキさんにご登場いただきます。

タ: うーん,なんで飛んでいるんだ?ぶつぶつ…
ス: どうかしたの?
タ: あ,鈴木さん。今度B社に納入予定のシステムの負荷試験なんですが,負荷をかけると肝心なところのデータが採れないんですよ。
ス: あらあら。そりゃ困ったね。何かエラーメッセージは出ているの?
タ: いえ,出ていないですね。
ス: そうか,大変そうだね。あ,もうお昼も過ぎてるから,メシでも食いに行かない。

(昼食中)

ス: それで,肝心なデータって何で見ているの?
タ: ごく普通にsarで負荷状況をモニターしているだけなんですが…負荷が高くなると,そこだけデータが飛ぶんですよ。
ス: それだと負荷試験にならないねえ~
ス: そういえば,IPAから公開された報告書にsarの話で近いのが載っていたかな?帰りに席によってみて。

(スズキさんの席)

ス: えーと,これこれ。3章に,I/O負荷とかCPU負荷とかメモリ負荷で高負荷時の挙動の表(表1)があるでしょう。
sarのほかにiostatとmpstatの様子ものっているね。どれくらい変化するかは,グラフのほうが見やすいかな(図1,図2
タ: へえー,カーネル2.4と2.6でも違うんですね。
ス: 今試験しているのは,どんな負荷タイプになるの?
タ: ディスクI/O負荷がメインなのかな…
ス: あ,もう会議の時間だ。まぁ,もどって良く読んでみて。

表1●高負荷環境における障害状況(資料1 表3.1-3より転載)

図1●CPU高負荷時におけるsarのデータ取得間隔の分布(カーネル2.6)
資料1 図3.1-18より転載)

図1●CPU高負荷時におけるsarのデータ取得間隔の分布(カーネル2.4)
資料1 図3.1-19より転載)

(夕方になって)

タ: スズキさん,ありがとうございました。sarのほうは,さっきの報告書に回避策についても書いてあったのでバッチリ解決です!
ところが,アプリ側でも高負荷でスローダウンがありそうなんですよ。