Linux版srcdsのパフォーマンス測定方法②

具体的な測定方法について。

大まかに手順を説明。
①下準備
②モニタリングの開始
③実際に遊んでラグの発生を確認。
④分析
⑤対策は自己責任

①まず下準備をします。数値をモニタリングするツールをインストールして使える状態にしておきましょう。
ここではsysstatを例に進めます。ぐぐってください。有名なツールなのでたくさん出ています。

②モニタリングの開始。
sarコマンドに必要なパラメーターを渡して出力させつづけます。↓は一例です。他にもパラメータはあります。

$sar -n EDEV -dqurS 1 7200 -o result.dat
説明: -n EDEV ネットワーク情報(エラー)、-d ディスクアクセス、-q プロセス数、-r メモリ、-u cpu使用率、1 7200 一秒間隔で7200回取得(2時間)、-o result.dat ファイルに出力(binary)

注)sysstatのバージョンにより渡せるパラメータ、出力内容に違いがあります。使えるものをつかってください。
Debian lennyのaptitudeでは古いものしかとれたなかったので、ソースからdebパッケージ作って入れました。

それから、他のPCからサーバにpingを飛ばし続けましょう。Windowsのコマンドプロンプトならping -t ip_addressで永久に飛ばし続けられます。
なるべくsrcdsとクライアント間の経路を通るようにしてください。

③実際に遊ぶ
実際に遊んでラグを感じるかどうかを調べます。何からぐったなとおもったらその時間をめもっておきます。
サーバの時間でメモりましょう(事前に同じNTPサーバで同期とるといいです)。複数人でやると効果的かもしれません。

④分析

遊んでラグッた時間を手がかりにsysstatとpingの結果を確認します。
#sysstatの結果については$sar -f result.dat で出力できます。
#出力結果については
#以下のページでわかりやすくまとめられています。
#http://stg.webmemo.uzuralife.com/article/2044

#$man sarもみてください。

まず、pingの結果をみてみる。
→ロスや遅延が発生している。
→→ネットワーク経路上で何らかのトラブルが発生しています。

sar -qのrunq-sz。
→この値が他の時間と比べて高くなっている。
→→サーバが原因でラグっているとみていいです。
runq-szが大丈夫そうな場合は最後にちょろっとかきます。

次になぜ、runq-szが増えたのかを分析。

パターン1 CPUの処理能力不足
sar -uの結果をみてみる。
→使用率が100%に近い。
→→ CPUの処理能力に限界がきています。

パターン2 メモリ容量の不足
sar -uの結果をみてみる。
→iowaitが発生している。
→→ディスクアクセスもしくはメモリアクセスの為、処理待ちが発生しています。
sar -rの結果をみてみる。
→kbmemused – ( kbbuffers + kbcached )が少なくなっている。
→→メモリを使い切っています。swapが発生していると思われます。
sar -Sの結果をみてみる。
→kbswpusedの値が増えている。
→→swapが発生している。

パターン3 何らかのディスクアクセスとバッティングしている。
sar -uの結果をみてみる。
→iowaitが発生している。
→→ディスクアクセスもしくはメモリアクセスの為、処理待ちが発生しています。
sar -dの結果を見てみる
→awaitの値が大きくなっている。
→→大きなディスクアクセスが発生している。(milliseconds)

パターン4 それ以外
どの数値にも問題がない場合
sarのパラメータを変えてみるといいかもしれません。
正直、わかりません。もしかしたらcronか何かで他のプロセスと処理がバッティングしてるかもしれません。

最後にrunq-szは問題ないけど何かラグった場合。

パターン5 サーバのNICでエラー
sar -n EDEVの結果を見てみる
→0以外の何かがでてる。
→→ NICがらみで何かがおかしいです。ドライバレベルからNIC不良、LANケーブルの接触不良など。

パターン6 それ以外
sarのパラメータを変えてみるといいかもしれません。
正直、わかりません。LANより外側の回線で何かおきたのかもしれません。

私で思いつくのはこんなところです。読んでて気づいた方がいるかもしれませんが、すべて下のレイヤーレベルの話だけです。
srcds自体、またはプラグインで何かおきてるとsysstatでは拾えないと思います。
何となく、そちらで問題が発生するパターンの方が多い気もします。

⑤対策は自己責任
実際の対策は自己責任でお願いします。
勢いで書いたエントリーなので、分析が間違ってる可能性があります。。
分析が外れる可能性もあります。
例えばCPUを交換しても負荷がさがらなかったり、メモリを増やしても増やしても足りなくなる事があるかもしれません。

#追記
待ちプロセスがsrcds以外のプロセスだったら問題は無いはずです。
http://blog.rino-server.jp/?p=25

ちなみに、まだ一度も試してません。最初に書いてよって話ですよね。ごめんなさい。
ですので現時点での懸念だけでも書いておきます。
sarに-oオプションをつけることにより頻繁にディスクアクセスが発生します。
それが高負荷状態でiowaitに現れる可能性があります。
ssh経由で別クライアントに飛ばすといいかもしれません。

他にも何かいい方法があれば是非教えてください。間違いの指摘も大歓迎です。
終わり。

コメントを残す

メールアドレスが公開されることはありません。