OpenSolaris Hot Topics 6th (2009/02/13) 音声
2 月 13 日(金) 開催の OpenSolaris Hot Topics 6th の音声をこちらに置きました。
当日使用した資料と動画はもうすぐナイトセミナーのページに掲載予定です。 。と思ったら、下記長く語りを書いている間に掲載されたようです。
http://sdc.sun.co.jp/events/nightSeminar/sol_hot_topics2009.html
ご質問のフォローを私なりに以下ちょっと書きますのでよろしければご参照ください。
- 値の大きい・小さいはどう考えればよいか
これはある種永遠の FAQ とも言えるご質問ではあるのですが、どの値がどうなったら大きい・小さいという具体的な数値は、システム構成や負荷状況によって変わるので、一概には言えません。以下いくつかの指針として考えられるところを列挙しますと、
- 運用中のシステムの場合
普段はどのくらいの *stat や sar の値なのか、低負荷時はこのくらいで高負荷時はこれくらいで、といった値を普段から収集しておくようにすると、何か (例えばレスポンスが悪い、など) がおかしい際に値を比較することができるかと思います。
- 開発中のシステムの場合
開発において、何らかの性能目標 (例えばレスポンスタイム) を設定するかと思いますが、目標値がうまく出ているときの *stat や sar の値をとっておき、そうでないときとの差異を見つけていくことになるかと思います。
いずれにしても、*stat コマンド出力の各項目が何を意味するのかと、各項目がどのくらい性能に影響を及ぼすのかの大まかなところがわかっていないと、掘り下げていきにくいかなと思いますので、下記します本やトレーニングなどで大まかなところをご理解いただけると思います。
- チューニング用パラメータを最初から入れないのはなぜか
いくつか理由を列挙します。
- チューニングは、どちらかというと上のレイヤーから着手していく方が性能への貢献が大きいことが多く、OS のチューニングは不要であることも多いから。
- Solaris の各パラメータ標準値設定の方針は、どのようなマシンにインストールされて、どのような負荷をかけても
- 遅いということが起きにくい (バランス重視)
- 不安定にならない (安定性重視)
- もちろん標準準拠
- しかも結構いい性能が出る (Solaris 10 初期リリース後特に両立が図られる)
- パラメータは OS 側で自動調整 (Solaris 10 で大幅に導入)
ようにバランスがとられているから。
- OS パラメータは今後変わる可能性があるので
- こちらのマニュアルもご参照ください
- マイナーフォルト・メジャーフォルト
メモリ関連につきましては、以下資料が参考になるかと思います。新しい順に列挙します。古い資料の内容と現在の Solaris での実装は正確には異なっている箇所もありますが、概要を掴むには非常に役立つかと思います。
- 複数のアプリケーションが動いている環境での解析
セミナー中にありましたように、prstat -mL でどのプロセスからの負荷が高いかを切り分ける方法は非常に有効かと思います。DTrace のサンプルスクリプト (/usr/demo/dtrace の *snoop.d , *time.d , what*.d , where*.d , who*.d あたり) や DTrace Toolkit 各ツールによって、システム統計値などの各値がどのプロセスによって引き起こされているかをまずは切り分けることができると、後の解析を進めやすいかと思います。
- 網羅的にまとまっている本など無いか
思いついた順に列挙してみます。
- Sun Performance and Tuning - Java and Internet -
- 10 年以上前で今となってはかなり古い本ですが、Ch.2 Performance Management と Ch.3 Performance Measurement あたりの基本概念は大事
- 確か第一版は『Solaris & SPARC パフォーマンスチューニング』として日本語版あり
- Unix システムパフォーマンスチューニング第 2 版 (2003 年)
- Java の tuning について
ツールがいろいろあり便利ですが、JVM の内部構造や GC の仕組みがどのようになっているかを理解しておくとよりスムーズかと思います。
- 本当に 10Gbps 出るか
セミナー前半では 10 Gigabit Ether の性能をどこまで出せるか、というストーリーでした。
用いたハードウェアがリリースされた頃は、CPU 性能 vs. 作業量のバランスと、ネットワークチップの性能 vs. 作業量のバランスで、どちらかというと CPU 側が先にボトルネックとなる頃とお考えいただけるとよいかなと思いました。
CPU がボトルネックしてしまう要因を解析して取り除くことによって、ネットワークインターフェースの性能をある程度までは引き出せるということになります。
これは、Solaris 10 にて強化された TCP/IP (6/06 頃からは UDP も) プロトコルスタックの実装改善 (FireEngine プロジェクト) が非常に大きなポイントとなっていて、ネットワーク性能のスケーラビリティを成し遂げたからこそ可能だったチューニングと言えます。
参考: FireEngine - Solaris 10 ネットワークパフォーマンスの向上 (SDC 会員登録が必要)
(さらに知りたい場合はこちら (SDC の Solaris 10 ネットワーク関連記事))
また、read/write、sendfilev、mmap でどれが速いかは、負荷要件やシステム構成など他の要因や、各コールの個数によっても性能は異なってきますので、セミナーでの例はあくまでも例であり、このように進めていくといいのかなというイメージをお持ちいただければいいのかなと思っています。流れとともに、やはり各パラメータの意味するところを理解するというのが非常に大事だと個人的には思っています。
- runqueue の長さについて
最近のシステムは core 数やハードウェアスレッド数が多いので、runqueue の値自体をそれほど気にする必要は無いかなと思います。特に Solaris では、システム負荷に対しての耐性が高い (高負荷でも急激な性能低下が少ない) と言われていますので、どちらかというと、runqueue の値の増減に注目する方がいいのかなと思います。
Posted at
04:55午後 2 16, 2009
by Hiroaki Nozaki in Solaris |