Kodama's home / tips.

処理が遅い場合の調査

処理が遅い場合, 問題が, ディスク I/O, CPU能力, ネットワ−ク, メモリ不足, NFS 等のうちどこにあるかが問題になる.(いや,他にもありうるけど) ディスク I/O や ネットワ−クが問題になることが多いと思う.

ネットワ−ク関連では, hosts ファイル や DNS に無登録のマシンだったり, NIS 参照に問題が出ていたり, また, 自分自身でなく NFS サ−バが遅いのが原因の例もあった. 機材の故障やケ−ブル不良で, ネットワ−クに大量のエラ−がでているのが 原因のことも多い. 複数の DNS サ−バを参照しているばあい, DNS サ−バの参照順が適切か考え直してみる.

使用する tool

/proc/loadavg, /proc/meminfo, /proc/stat, /proc/swaps など(Linux kernel 2.4).

ディスク I/O

ディスクI/O を調べてみる. 一見,負荷が,集中していないように見えても, くわしく見ると ディスクが原因であったりする.

• キャッシュの影響を避けてテストしたいなら, 強制的にキャッシュを同期させる. (Linux ディスクキャッシュの開放)
• hdparm -t と hdparm -T :
  -T は Linux のディスクキャッシュを利用した場合のディスクからの読み込み性能. -t はディスクキャッシュを利用しない場合のディスクからの読み込み性能. -t の方がディスクの性能が直に現れる.
• vmstat の bi と bo :
  vmstat で bi と bo の欄を見る. これは, 入出力ブロック数だが, ディスクの大体の能力と比べてみよう.
• vmstat の b :
  vmstat の b 欄は 入出力待ちでブロックされているプロセス数を表す. b 欄の数値が大きいなら, 入出力がボトルネックの兆候.
• nfsstat :
  NFS マウントしているときには, クライアント側で nfsstat で調べる.
• NFS サ−バ−のメモリー :
  サ−バ−側でメモリが足りなくなって, NFS サ−ビスが遅くなっていた事がある. サ−バ−側の調査も忘れずに.

# /sbin/hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  120 MB in  3.05 seconds =  39.30 MB/sec
bash-3.2# /sbin/hdparm -T /dev/sda

/dev/sda:
 Timing cached reads:   8264 MB in  1.99 seconds = 4143.25 MB/sec

# vmstat 30
 procs                  memory    swap        io    system         cpu
 r b w  swpd  free  buff cache  si  so   bi   bo   in   cs  us  sy  id
 1 0 0 23032   496   432  4700   3   3    6    7  168   70  19   7  74
 1 0 0 20576   980   212  5100  46  13   76    5  358  288  33   8  59
 2 0 0 20576   644   396  5228   2   0    6   11  162  312  27   6  68
 2 0 0 20364   208   100  4732  16   9   93    4  363  349  34  10  56
 1 0 0 21896   388    84  5400  12  55   87   27  432  315  45  12  42

iostat 相当のコマンドは無いのかな？ ディスクのサ−ビスの遅延とかを知りたいんだけど...

メモリは足りているか

free または top コマンドで現在のメモリの利用状況を調べる事ができる.

$ free
             total       used       free     shared    buffers     cached
Mem:         22292      21872        420      11128        560       4644
-/+ buffers:            16668       5624
Swap:       120956      22124      98832

上の数値の単位は kbyte. このマシン(僕の愛用 PC)は 約24M byte のメモリを積んでいるが, total=22292 の自由に使えるメモリがある. このうち used=21871 使用し free=420 空き. used=21872 の内 buffers=560, cashed=4644 は 空いているメモリを作業用に転用しているだけなので, free が数百k 程度なのが普通. これを実質的には 空きと考えると, +/-buffers の補正後, used=16668 使い free=5624 空いている事になる.

swap にはみ出していたとしても, それだけでは メモリ不足の証拠にはならない. あまり使わないコ−ドを追い出して cache と buffre に転用しているだけかも知れない.

本当にメモリが逼迫しているかどうか調べるには, vmstat の si と so 欄を見ながら, 実際の作業をやってみる. ある程度の si(swap in) があるのは正常と思う. あまりにも so(swap out)が多いのは メモリ不足の兆候かも知れない. 下の例では, メモリが不足気味.

$ vmstat 30    # 30秒毎にメモリー関連の統計を出力
 procs                  memory    swap        io    system         cpu
 r b w  swpd  free  buff cache  si  so   bi   bo   in   cs  us  sy  id
 1 0 0 23032   496   432  4700   3   3    6    7  168   70  19   7  74
 1 0 0 20576   980   212  5100  46  13   76    5  358  288  33   8  59
 2 0 0 20576   644   396  5228   2   0    6   11  162  312  27   6  68
 2 0 0 20364   208   100  4732  16   9   93    4  363  349  34  10  56
 1 0 0 21896   388    84  5400  12  55   87   27  432  315  45  12  42
 2 0 0 22468   816   144  5452   6  22   22    6  217  155  53   4  42
 2 0 0 22540   416   384  5732   3   3   12   12  160  224  15   3  82

CPU の利用状況

• load average :
  load は CPUの処理を待っているプロセス数を意味する. だから,いくらでも大きい値になりうるはず.
• CPU利用率 :
  vmstat の us 欄や top 等の CPU 利用率は CPU が費やしている時間の割合を意味する. だから 100% を越える事はない.

load average の調べ方

1. top コマンドを用いる
2. w コマンドを用いる
3. vmstat の r 欄
4. xload : Xの画面で見る事ができる.
5. xosview : Xの画面で見る事ができる.
6. procmeter : Xの画面で見る事ができる.

CPU 利用率 の調べ方

1. vmstat の us sy id の欄を見る. 各々 user の処理時間, system の処理時間, idle 時間の割合.
2. top コマンドを用いる.
3. xcpustate : Xの画面で見る事ができる.
4. xosview : Xの画面で見る事ができる.
5. procmeter : Xの画面で見る事ができる.

CPU の負荷の基準としては, CPU 利用率よりも load average が役にたつ. CPU の速度と要求される処理速度にもよるが, load average が 4*(CPU数) 以上なら (そして他の要因でなく CPUが問題と確信できるなら) CPU を買足す方がよいかも. ただ, 処理待ちのプロセスが溜る原因が, ディスクや ネットワ−クの IO待ちにある方が多いかも.

vmstat または top の CPU 利用率の user と system の割合に注意. NFS サ−バは別として, system 時間が多すぎるとか load が高いのに CPU が遊んでいるようなら, 入出力とか 割込みとかに問題があるかも.

ネットワーク

考慮すべき主な要素:

• クライアント側(ネットワークの設定など)
• サーバ側
• 通信経路(ケーブル, HUB, ルータ, PROXY)
• DNS などの基本的なサービス (問題が発見されたサービス以外の部分に原因がある事も多い)

NFS

• サ−バのCPU能力が不足
• サーバのディスクIO速度の不足
• サ−バのメモリ不足
• NIC の能力の不足
• ネットワ−クの能力不足(容量,遅延),
• ネットワ−クの不調によるパケットロスや遅延
• ネットワ−クの混雑で collision が起こってサ−ビスが低下

sendmail などネットワークサービスの起動や処理が遅い

/etc/hosts ファイルの自分の項が guppy.kobe-kosen.ac.jp みたいな ドメイン名も含む名でなく 略名(guppy とか) のため(?) sendmail の起動が遅くなった事がある.(ほんと？) hosts に書く場合, 下のように, ip-address に続けて 長い名前, 略名 の順でかくと良いかも.

10.10.10.10 guppy.kobe-kosen.ac.jp guppy

/etc/hosts ファイル, DNS への参照(/etc/resolv.conf), DNS サーバの動作 など.

Kodama's home / tips.