 |
||||||||||||||||||||
|
||||||||||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||||||||||
|
||||||||||||||||||||
| 評価手法のまとめ | ||||||||||||||||||||
|
今回、3種類のタイプを実際に解析した手順を基に、評価手法についてまとめる。 |
||||||||||||||||||||
| プロファイリング評価 | ||||||||||||||||||||
|
OProfileでプロファイリングを実施してその結果を解析する。上位の傾向から今回の評価で明らかになった3種類に分類する。
|
||||||||||||||||||||
|
||||||||||||||||||||
| 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によってはじめて可能になった調査機能は以下の通り。
今回使用した範囲では、以下に挙げる制限があった。
以上の点が改善されれば、LKSTはさらに強力な分析ツールとなり、様々な現場でのシステムの解析工数を大幅に減らす手段となるだろう。今後の改良が期待される。 |
||||||||||||||||||||
| まとめ | ||||||||||||||||||||
|
これまでカーネルの評価というと、printk文の埋め込みやパッチの適用などカーネルに直接手を入れる手法が多く、限られたごく一部のハッカーの手にしか負えない領域であったが、今回の評価によって、ユーザコマンドレベルのツールを用いて比較的容易に実施できることを示した。 もちろんボトルネックを解消するためには多くの場合、カーネルを修正するなどの高度な技術が依然として必要とされるが、少なくともボトルネックの特定までは基本的な技術で到達できることがわかり、その手法を示すことができた。 大規模システムを使用した今回のパターンではCPUビジー型が最も多く観測された。これは大量のメモリコピーがボトルネックになっていることから、メモリ・レイテンシ問題のひとつが浮かび上がってきた例と考えられる。メモリの高速化およびキャッシュの大容量化、キャッシュに優しいアルゴリズムの導入等によって、このボトルネックの改善または解消が期待される。 CPUアイドル（I/Oビジー）型のようなケースではデバイスの高速化が解決手段として期待される。 ロック競合型については、競合が発生する箇所を特定できたものの、これを解消するにはカーネルの改良等が必要なため、容易ではない。今回は改善案の提案までにはいたらなかった。今後の課題としたい。 最後に、今回実施したOProfileとLKSTによる評価は、それぞれのツールの機能をすべて使い切ったわけではなく、どちらも有用な機能を他にも実装している。OProfileは今回使用したバージョンが0.5.4であるが、現在の最新版は0.8.1であり、機能強化が図られている。また、LKSTも今回使用した4個のイベントのほかに数多くのイベントがあり、より広範囲のデータを取得することができる。加えて、今回の測定において発見されて未解決となった現象も多々あり、今後追及すべき課題としたい。
今回明らかになった3タイプのボトルネックそれぞれを改善する取り組み
今回は時間の制約から見送らざるを得なかったこれらの課題について、2005年度日本OSS推進フォーラム・開発基盤ワーキンググループにおいて、CPUのスケーラビリティの調査検証を行っている。さらなる解析手法のノウハウを蓄積し、それを公にして情報の共有化を進めたい。これによって信頼性を増すLinuxがこれまでよりもさらに普及するための一助となれば幸いである。 |
||||||||||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||||||||||
|
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
-
-
連載
