hajichan.net technical version

色々な機器で構成されたシステムにおいてパフォーマンスが悪いとなると、ボトルネックと成りうる部位(間のネットワークとかサーバとかその他の機器とか)を総合的に調査しなければならないのですが、 ここではサーバやOS自体に関してのパフォーマンスチェックの内容に留まります。と言っても、これだけでもかなり難しいんでが・・・

パフォーマンスチェックをする際は、まず、どの部分が悪いのか調査する必要が有ります。Solarisには主に以下の表に記載するようなモニタリングツールが用意されています(詳細はマニュアルを参照下さい)。

※その他にも、memtoolとかSE Toolkitとか言うフリーウエアも有るようです。 また、SOLARISインターナルと言う本のサイトにもおもしろそうなツールらしきものが有ります。

どのツールについても共通なことなんですが、大事なことはこれらのツールを利用して継続的にデータを収集すると言うことです。継続的にデータを収集することにより、一時的な高負荷状態でリソースが圧迫されていたのか、それとも慢性的にリソースを喰ってパフォーマンスが悪いのかを判断します。

一時的なリソース不足状態

この場合は、プロセス管理コマンド(ps、top、prstatなど)を実行して、暴走しているプロセスやリソースを喰っているプロセスが無いか確認します。ある意味突発的な負荷であるため、原因も特定しやすいので、そんなに気にする必要は無いと思います。

慢性的なリソース不足状態

問題となるのはこの場合で、リソース増設やパフォーマンスチューニングを施す必要が有るでしょう。

ここでは、主にvmstatコマンドを使用したCPU、メモリの負荷状態モニタリング方法と、iostatコマンドを使用したディスクI/Oの負荷状態モニタリング方法、そしておまけでnetstatコマンドを使用した ネットワーク状態モニタリング方法を記載します。これだけでもシステムの大半の負荷状況が把握出来ると思います(というか、他のコマンドあまり使ったこと有りません。すいません)。

30秒間隔位で、データを収集すればいいと思います。一番上のデータは、システム起動時からの統計情報なので無視しましょう。この結果をファイルに保存して継続的に取得し傾向を見るのです。

# vmstat 30
---
 procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr dd dd m0 m1   in   sy   cs us sy id
 0 0 0 515816 39512   5  34  5  3  3  0  0  2  2  0  0  310  106  117  6  1 93
 0 0 0 511456 36216   0   2  0  0  0  0  0  0  0  0  0  303   22  110  0  0 100
 0 0 0 511456 36216   0   0  0  0  0  0  0  0  0  0  0  303   19  110  0  0 100
 0 0 0 511456 36216   0   0  0  0  0  0  0  0  0  0  0  303   18  111  0  0 100

各値の意味は、マニュアルで調べていただくとして、一体どの値に着目すれば良いんだという話になってくるかと思います。そこで注意して見るべき値についてだけ記載します。 下の表は、vmstatの注目すべき値とその大まかな意味、そして、その値からどのリソースの状態が分かるかを示しています。

CPU

CPUの負荷状況は、vmstatのr値から大体分かります。r値は、「実行可能キュー」な訳ですから、値が大きければそれだけ処理待ちのジョブが溜まっちゃってるということで、CPUのパワー不足であることが読みとれます。 で、ある本に書かれていたは、以下通りになっています。キューをシステムのCPU数で割った値で判断します。

swap

swapの領域の状況は、vmstatのswap値から大体分かります。文字通りですが。これも、ある本に書かれていた判断基準値は、以下通りになっています。

物理メモリ

物理メモリの負荷状況は、vmstatのsr値から大体分かります。sr値は、「ページデーモンがスキャンしたページ数」な訳ですから、値が大きければそれだけページデーモンが必死に活動して解放できそうなページを探しているということで、ページデーモンが必死に活動するということは、要するにメモリ不足であることが読みとれます。 で、これもある本に書かれていた判断基準値は、以下通りになっています。

30秒間隔位で、データを収集すればいいと思います。一番上のデータは、システム起動時からの統計情報なので無視しましょう。この結果をファイルに保存して継続的に取得し傾向を見るのです。

# iostat -xnp 30
---
                    extended device statistics
    r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b device
    0.3    1.8   12.9   10.8  0.0  0.0    0.5    1.8   0   0 c0t0d0
    0.0    0.0    0.0    0.1  0.0  0.0    1.3    2.8   0   0 c0t0d0s0
    0.0    0.0    0.0    0.2  0.0  0.0    2.5    6.7   0   0 c0t0d0s1
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t0d0s2
    0.0    0.1    0.0    0.6  0.0  0.0    0.5    1.6   0   0 c0t0d0s3
    0.0    0.3    0.0    0.2  0.0  0.0    0.8    1.7   0   0 c0t0d0s4
    0.0    0.0    0.9    0.1  0.0  0.0    0.4    4.2   0   0 c0t0d0s5
    0.1    0.3    1.7    1.9  0.0  0.0    0.6    3.6   0   0 c0t0d0s6
    0.2    1.1   10.2    7.8  0.0  0.0    0.4    1.2   0   0 c0t0d0s7
    0.1    2.0    2.7   20.9  0.0  0.0    1.2    2.3   0   0 c0t2d0
    0.0    0.0    0.0    0.1  0.0  0.0    3.5    5.1   0   0 c0t2d0s0
    0.0    0.0    0.2    0.0  0.0  0.0    0.4    8.2   0   0 c0t2d0s1
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t2d0s2
    0.0    0.1    0.0    0.6  0.0  0.0    0.9    3.2   0   0 c0t2d0s3
    0.0    0.3    0.0    0.2  0.0  0.0    2.0    3.0   0   0 c0t2d0s4
    0.0    0.0    0.9    0.1  0.0  0.0    0.5    4.4   0   0 c0t2d0s5
    0.0    0.3    0.4    3.2  0.0  0.0    1.7    4.8   0   0 c0t2d0s6
    0.0    1.2    1.3   16.7  0.0  0.0    0.8    1.2   0   0 c0t2d0s7
    0.0    0.0    0.0    0.1  0.0  0.0    6.2    9.9   0   0 d0
    0.0    0.0    0.2    0.2  0.0  0.0    0.4    9.1   0   0 d1
    0.0    0.1    0.0    0.6  0.0  0.0    4.6    5.1   0   0 d3
    0.1    0.0    1.8    0.1  0.0  0.0    0.3    5.0   0   0 d5
    0.1    0.3    2.1    3.2  0.0  0.0    2.8    7.9   0   0 d6
    0.2    1.2   11.5   16.7  0.0  0.0    0.3    2.6   0   0 d7
    0.0    0.0    0.0    0.1  0.0  0.0    0.0    4.1   0   0 d10
    0.0    0.0    0.0    0.2  0.0  0.0    0.0    9.3   0   0 d11
    0.0    0.1    0.0    0.6  0.0  0.0    0.0    2.1   0   0 d13
    0.0    0.0    0.9    0.1  0.0  0.0    0.0    4.6   0   0 d15
    0.1    0.3    1.7    1.9  0.0  0.0    0.0    4.3   0   0 d16
    0.2    1.1   10.2    7.8  0.0  0.0    0.0    1.7   0   0 d17
    0.0    0.0    0.0    0.1  0.0  0.0    0.0    8.7   0   0 d20
    0.0    0.0    0.2    0.0  0.0  0.0    0.0    8.7   0   0 d21
    0.0    0.1    0.0    0.6  0.0  0.0    0.0    4.1   0   0 d23
    0.0    0.0    0.9    0.1  0.0  0.0    0.0    4.9   0   0 d25
    0.0    0.3    0.4    3.2  0.0  0.0    0.0    6.6   0   0 d26
    0.0    1.2    1.3   16.7  0.0  0.0    0.0    2.1   0   0 d27
    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t1d0

各値の意味は、マニュアルで調べていただくとして、これもvmstatと同様着目すべき値についてだけ記載します。 下の表は、iostatの注目すべき値とその大まかな意味を示しています。

これもある本に書かれていた判断基準値をまとめると以下のようになります。

ディスクI/Oが多いと、%bの値が高くなりますが、svc_tが小さければこれは単純にディスクI/Oでビジー状態になっているだけです。つまり、ディスクI/Oが多いけど、時間を掛けずに処理してるよってことですから、問題ないと判断できます。

%bに加えて、svc_tが大きくなってくると危険です。ビジー状態で尚かつ処理にも時間が掛かってるってことですから(処理に時間が掛かってるからビジーなのか？)、ディスクの過負荷によって、明らかにディスクI/Oのスループットが落ちていると言えます。

30秒間隔位で、データを収集すればいいと思います。一番上のデータは、システム起動時からの統計情報なので無視しましょう。この結果をファイルに保存して継続的に取得し傾向を見るのです。

# netstat -i 30
---
    input   eri0      output           input  (Total)    output
packets errs  packets errs  colls  packets errs  packets errs  colls
4475176 0     8176288 78    0      5253822 0     8954934 78    0
1       0     1       0     0      1       0     1       0     0
1       0     1       0     0      1       0     1       0     0
2       0     2       0     0      2       0     2       0     0

netstatの注目すべき値とその大まかな意味は以下の通りです。

で、2.0% < 100 * (output colls) / (output packets) < 5.0%となっているとネットワークが過負荷状態であると言えます。

以上のパフォーマンスチェックを踏まえて、もし悪い結果となった場合は、対策を考えましょう。サーバ管理者が出来る対策はこれくらいでしょうか。

• 起動するサービスを最小限に留める(本当に必要なサービスしか起動しない)
• カーネルパラメータを調整してリソースを最大限に有効活用する(パフォーマンスチューニング)
• 部分的にモジュールを増設する(CPU、メモリ増設)
• 高スペックのマシンを購入する

「起動するサービスを最小限に留める」は、サーバを管理されている方で有れば、やっていることだと思いますので特に言及しません。

「部分的にモジュールを増設する」と「高スペックのマシンを購入する」は、お金を掛けても良いので有れば、一番早い解決策だと思います。 うだうだチューニングをするよりは、良いものを使うということは、時間コストの節約にもなりますし得策だと思います。

「カーネルパラメータを調整してリソースを最大限に有効活用する」は、お金は掛かりませんが高度なテクニックだと思います。僕もよく分かってません。 パラメータをどれくらいにすればいいのか、パラメータを変更することにより期待通りパフォーマンスが向上しただろうか、逆にパフォーマンス が劣化してないだろうか、など考慮すべき点がたくさん有ります。

と言うわけで、パフォーマンスチューニングに関しては、何も掛けませんでしたが、ここでクローズしたいと思います。