 |
|
|
| 前のページ 1 2 3 4
|
|
| 評価手法のまとめ
|
今回、3種類のタイプを実際に解析した手順を基に、評価手法についてまとめる。
|
| プロファイリング評価
|
OProfileでプロファイリングを実施してその結果を解析する。上位の傾向から今回の評価で明らかになった3種類に分類する。
- CPUビジー型
- 結果がCPUビジー型の場合は、上位のシンボル（関数）を上から順に解析し、具体的にどの処理に集中しているのかを把握する。今回の測定ではシンボルdo_generic_file_write()が最上位で、この中で呼ばれている__copy_from_user()に処理が集中していた。
- CPUアイドル型
- 結果がCPUアイドル型の場合は、OProfileではボトルネックを捉えきれないことがあるため、LKSTでも測定する。今回の評価ではI/Oのベンチマークを実施していたので、LKSTのbufferとblkqueueのデータを取得し、この結果を分析した。
- ロック競合型
- 結果がロック競合型の場合には、まずOProfileの詳細データからスピン時間の長いロックのコードを（マクロ的に）特定する。次に、LKSTのbusywaitとspinlockのデータを取得して、ミクロで実際にどのような競合が起こっていたのかをつきとめる。LKSTのデータを取れる時間は短いため、OProfileの結果とLKSTの結果を照合することで確実性を増すことができる。
- それ以外
- 上の3種類のどれにもあてはまらない場合、基本的にOProfileの詳細結果を分析して、処理が集中しているコードを特定する。続いて、このコードの処理内容に近いデータを取得するLKST測定を実施する。
|
|
| LKSTによる追加評価
|
プロファイリング結果から、必要であると判断される場合はLKSTによる評価を実施する。どのイベントを取得するかはプロファイリング結果、または注目する観点から判断する。ロック競合が発生している場合はbusywaitやspinlock、I/O処理待ちが推定される場合はbufferやblkqueue、ネットワーク負荷が高い場合はnetsendやnetroute、プロセススケジューリングに注目する場合はrunqueueやwaitqueueやwaittimeなどを選択する。
LKSTはオーバーヘッドが大きいため、有効にするマスクセットは必要最小限のものとし、またI/Oの評価においてはlkstlogdを使用せず、カーネル内バッファを使用するのが望ましい。カーネル内バッファを使用した場合、LKSTで測定できる時間が短いため（今回の評価で、概ね数十秒〜1分未満程度）、ベンチマーク所要時間とあまりにかけ離れている場合は、LKSTを有効にするタイミングを工夫する必要があるだろう。
LKSTによる測定結果が得られたら、まず統計情報を確認する。それに基づいて、必要に応じて時系列データから個々のイベントを抽出し、個々のイベントにおいて何が起きていたのかを詳細に把握する。今回の測定では、ロック競合のイベントを詳細に把握した。
|
| 評価
|
以上の手順で得られたプロファイリング結果とLKSTの結果から、システムの動作状態およびボトルネックを判断する。この時、はじめに設定した評価目的に沿った観点での結論を得ること、また前提条件と矛盾しない結果でなければならない。妥当と思われる結論を得るためには、上の評価を様々な機種、様々なパターンで多大な工数を費やして実施しなくてはならないこともありえる。
|
| 改善手段の考案と適用
|
システムの動作が明らかになり、そのボトルネックを把握できたと判断した場合は、これを解消する手段を考案する。そのためには、単なるパラメータのチューニングから、ハードウェアの交換、カーネルの修正など幅広い対応が考えられる。基本的には複雑な手法よりも単純な手法のほうが好ましい。
改善手段を考案したらこれを適用し、再度評価を行う。評価手順を改めて実施する。
再評価の結果、改善があったと認められる場合は、次に現れたボトルネックをターゲットとしてこれの改善に努める。
もしも改善しなかった場合は、改善手段またはボトルネックの把握に間違いがあったことになるため、改善手段を再検討するか、測定結果を再度分析し直すか、あるいは環境を見直したうえで測定自体を再度実施する。
|
| LKSTの利点、制限事項
|
今回、OProfileでは捉えきれない、個々の現象の詳細な情報をLKSTによって把握することができた。現状ではいくつかの制限があるものの、OProfileと組み合わせることで非常に強力な分析ツールとなることを証明した。
今回使用した、改良版LKSTによってはじめて可能になった調査機能は以下の通り。
- ひとつ一つのロック取得・解除のイベントの把握
- ロックの統計データの取得
- I/Oリクエストの処理時間の取得
- I/Oリクエストキューの長さ（統計値ではなく瞬間値）の取得
今回使用した範囲では、以下に挙げる制限があった。
- サンプリング（間引き）の機能がないため、データを格納する領域が不足する。CPUを複数搭載したシステムでは、CPU数の分のデータを保持するため、相対的に測定できる時間が短くなってしまう。lkstlogdを使用すると上限がかなり広がるが、これはファイルシステムへの書き込み処理を伴うため、I/Oの性能を評価する際に使うことが難しい。カーネルのバッファ領域サイズは32bitのシステムではかなり限られたものであるため、測定時間が十分であるとは言い難い。今回の測定では、イベント内容によっては20秒以下しか採取することができなかったケースもあった。
- spin_lockイベントの開始時刻がエンコードされているため、ロック取得時の個々イベントのビジー時間を把握することができなかった。統計値であればlkstlaコマンドから入手できる。
- プロセスidのデータを取得できるが、今回の測定ではプロセスidとプロセス名との対応を取ることができなかったため、別にtopコマンドを実施する必要があった。ただし、最新のLKSTでは改良されてプロセス情報を取得・抽出できるようになっている。
以上の点が改善されれば、LKSTはさらに強力な分析ツールとなり、様々な現場でのシステムの解析工数を大幅に減らす手段となるだろう。今後の改良が期待される。
|
| まとめ
|
これまでカーネルの評価というと、printk文の埋め込みやパッチの適用などカーネルに直接手を入れる手法が多く、限られたごく一部のハッカーの手にしか負えない領域であったが、今回の評価によって、ユーザコマンドレベルのツールを用いて比較的容易に実施できることを示した。
もちろんボトルネックを解消するためには多くの場合、カーネルを修正するなどの高度な技術が依然として必要とされるが、少なくともボトルネックの特定までは基本的な技術で到達できることがわかり、その手法を示すことができた。
大規模システムを使用した今回のパターンではCPUビジー型が最も多く観測された。これは大量のメモリコピーがボトルネックになっていることから、メモリ・レイテンシ問題のひとつが浮かび上がってきた例と考えられる。メモリの高速化およびキャッシュの大容量化、キャッシュに優しいアルゴリズムの導入等によって、このボトルネックの改善または解消が期待される。
CPUアイドル（I/Oビジー）型のようなケースではデバイスの高速化が解決手段として期待される。
ロック競合型については、競合が発生する箇所を特定できたものの、これを解消するにはカーネルの改良等が必要なため、容易ではない。今回は改善案の提案までにはいたらなかった。今後の課題としたい。
最後に、今回実施したOProfileとLKSTによる評価は、それぞれのツールの機能をすべて使い切ったわけではなく、どちらも有用な機能を他にも実装している。OProfileは今回使用したバージョンが0.5.4であるが、現在の最新版は0.8.1であり、機能強化が図られている。また、LKSTも今回使用した4個のイベントのほかに数多くのイベントがあり、より広範囲のデータを取得することができる。加えて、今回の測定において発見されて未解決となった現象も多々あり、今後追及すべき課題としたい。
今回明らかになった3タイプのボトルネックそれぞれを改善する取り組み
- __copy_from_user()呼び出しに無駄がないかどうか
- CPUキャッシュミスの調査・何らかの改善方法
- ディスクネックと判断したパターンで、ハードウェア構成を変更しての追検証
- ロック競合発生条件の追及
- グローバルロック lock_kernel()を減らすカーネル改良
今回は時間の制約から見送らざるを得なかったこれらの課題について、2005年度日本OSS推進フォーラム・開発基盤ワーキンググループにおいて、CPUのスケーラビリティの調査検証を行っている。さらなる解析手法のノウハウを蓄積し、それを公にして情報の共有化を進めたい。これによって信頼性を増すLinuxがこれまでよりもさらに普及するための一助となれば幸いである。
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
ミラクル・リナックス株式会社 吉岡 弘隆
2000年6月ミラクル・リナックス(株)設立、それ以前は日本オラクルにてOracleデータベースのサポートを担当していた。オープンソースとの出会いは、1998年米国Oracle出向時にNetscapeのソースコード公開がきっかけ。
ミラクル・リナックス株式会社 取締役
日本OSS推進フォーラム ステアリングコミッティ委員
OSDL Japan アドバイザリボードメンバー
|
|
|
|
|
|
