1249092564 Linuxで運用しているWebサーバがあり、最近レスポンスが悪いので調べてみると、CPUのiowaitの値が高いためということが判明しました。

しかしながら、このホストは以下のサービスも稼働しているのでどのサービスがIOを食っているのかが判定しづらいです。
・Apache+PHP
・MySQL
・qmail,dovecot
・nagios
・djbdns

topで見ても、プロセスのステータスが表示されるのは一瞬で傾向がつかめません。
どのプロセスがIO待ちに時間を消費しているか判定する方法はあるでしょうか?

ちなみに、以下の方法を試しました。
・topでプロセスのステータスを表示→傾向がつかめず。ステータスがIO待ちであるDになるのは一瞬で、apache,MySQLがたまにDになる。
・iostatを表示→スループットなどは出るが、どのプロセスが原因かわからない。

muninのCPU利用情報を添付します。AM5:30から3時間ほどバックアップのため、CPU負荷が高くなっています。

回答の条件
  • 1人2回まで
  • 登録:2009/08/01 11:09:25
  • 終了:2009/08/06 08:50:03

回答(4件)

id:pahoo No.1

pahoo回答回数5960ベストアンサー獲得回数6332009/08/01 12:19:10

ポイント10pt

ps u -A

でプロセス毎のリソース消費状況は確認しましたか?

id:matsubobo

確認しております。

50回ほど連続して実行しましたが、ステータスがDになっているプロセスは発見できないです。

物理メモリ不足によるスラッシングではなさそうです。

free領域がが137MBあります。

% free -m

total used free shared buffers cached

Mem: 256 251 4 0 14 117

  • /+ buffers/cache: 118 137

Swap: 1023 115 908


30秒ごとのvmstatを添付します。

% vmstat 30

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

2 0 118684 10228 8960 122688 4 1 523 179 18 14 12 2 70 16

1 0 118684 6900 9800 125176 0 0 104 259 144 163 7 3 81 9

1 1 118684 5532 9992 127208 1 0 68 28 87 117 3 1 90 6

4 0 118692 7688 9252 127080 2 0 249 138 107 186 8 2 79 11

0 0 118692 6552 9344 127260 0 0 7 46 65 88 1 0 97 2

1 1 118684 3012 8812 130168 2 0 145 91 99 155 4 1 82 13

0 0 118684 3888 8580 123956 2 0 175 86 163 128 3 0 79 18

0 0 118684 8800 8288 119404 1 0 42 30 97 178 1 1 94 4

0 0 118680 3548 8320 123780 1 0 290 108 124 178 3 1 81 15

2 0 118672 6804 7884 114872 2 0 328 123 135 233 6 4 74 16

3 1 118672 2812 9932 118584 1 0 193 161 135 606 13 2 70 15

0 0 118672 2880 10232 119096 0 0 89 45 90 161 3 1 88 8

2 0 118672 5140 18528 108804 0 0 365 112 151 191 1 1 79 20

2009/08/01 12:52:11
id:BlueSkyDetector No.2

BlueSkyDetector回答回数9ベストアンサー獲得回数22009/08/01 20:53:48

ポイント36pt

http://guichaz.free.fr/iotop/

iotopを使ってみてはどうでしょうか。

そしてwebのレスポンスに影響が大きいプロセスに対してioniceでI/Oの優先度を上げてみてはどうでしょう?

ただし、iotopは

It requires Python ≥ 2.5 and a Linux kernel ≥ 2.6.20 with the TASK_DELAY_ACCT and TASK_IO_ACCOUNTING options enabled.

になります。

こんな感じで kernel ≥ 2.6.20 を回避している方もいました。

http://d.hatena.ne.jp/kurosaka/20080728/p1

id:matsubobo

iotop試しましたが、kernelがIO周りの統計を出すようにコンパイルされていませんでした。

ioniceありがとうございます。はじめて知りました。

根本的な問題を発見して解決したいです。

2009/08/02 14:13:26
id:cannabis_c4 No.3

すかなび回答回数20ベストアンサー獲得回数42009/08/02 01:00:19

ポイント10pt

どのようなLinuxを使っているのかわかりませんが、Kernelが比較的新しいものであればiotopでI/Oの足を引っ張っているプロセスを特定してみるのはどうでしょうか。

http://gigazine.net/index.php?/news/comments/20080727_iotop/

id:matsubobo

kernelが対応していないので使えないです。

VPSにて稼働する、xen用kernelなのでkernelを入れ替えることは困難です。。。

% uname -a

Linux xxxxxxxxxxxx 2.6.16.13-xenU_3.0.2.3_4.centos4.5 #1 SMP Thu Jan 11 12:29:52 JST 2007 i686 i686 i386 GNU/Linux

2009/08/02 14:14:52
id:kmond2 No.4

kmond2回答回数31ベストアンサー獲得回数22009/08/02 21:33:06

ポイント34pt

VPSの種類にもよりますが、仮想マシンから見た場合、他の仮想マシンがCPUを専有している状態はIO-waitとして表れるものが多いですね。ご質問のケースも、そういうことなのではないでしょうか。

VPS提供業者に、仮想OSのwait状態のデータを開示させた方が解決が早いと思いますよ。


ああ、コメント者の中にVPSのことを知らない人が一人混じっていますね。

知らないならコメントなんかしなければいいのに。

id:matsubobo

> 他の仮想マシンがCPUを専有している状態はIO-waitとして表れるものが多い

参考にさせていただきます。

もう少しアプリケーション周りを調べて、解決しなさそうだったらISPへ問い合わせようと思います。

2009/08/02 21:49:04
  • id:b-wind
    ベタだけど、top の -d オプションで画面更新のスパンを長めに取るのが楽じゃないかと。
    もちろん取りこぼしもあるだろうけど。
    http://www.linux.or.jp/JM/html/procps/man1/top.1.html#lbAI
  • id:matsubobo
    30秒おきのvmstat取ってみました。

    % vmstat 30
    procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
    r b swpd free buff cache si so bi bo in cs us sy id wa
    2 0 84984 5788 12928 135024 4 1 523 179 18 14 12 2 70 16
    2 1 84984 5992 13312 128700 26 0 148 103 142 215 8 3 76 13
    0 0 84984 10196 12280 124140 1 0 122 197 130 195 12 3 74 11
    0 0 84984 8744 13204 126520 1 0 87 198 122 162 3 1 87 8
    0 0 84984 5828 13344 127796 9 0 199 94 182 239 3 1 83 13
    1 0 84984 6252 12840 128308 0 0 145 96 105 118 5 1 85 9
    0 0 84984 3236 12616 127240 0 0 60 58 91 171 2 1 92 5
    0 0 84984 7856 11544 124232 0 0 16 29 54 100 2 1 97 1
    0 0 84984 7784 11684 124432 0 0 7 11 52 89 1 0 97 2
    0 0 84984 7892 11840 124344 0 0 35 45 88 189 6 2 87 5
    0 0 84984 8568 21244 117908 1 0 414 117 182 260 5 2 69 24
    0 0 84984 3796 22020 121824 0 0 149 182 118 108 2 0 88 10
    0 0 84984 11644 14072 119012 0 0 608 169 149 277 8 4 65 23
    0 0 84984 4412 20972 125576 0 0 434 177 173 172 4 0 79 16
    1 0 84984 3416 19280 127444 0 0 365 93 135 177 3 1 78 17
    0 0 84984 6128 19528 125972 0 0 104 19 96 141 3 2 86 10
    0 0 84984 6772 19820 123300 0 0 33 38 101 116 2 0 92 6
    0 0 84984 4928 20132 124088 0 0 183 94 180 1049 11 3 72 14
    0 0 84984 9468 16076 122020 0 0 217 166 166 230 6 2 69 24
    0 0 84984 6280 16360 124992 0 0 104 122 120 175 8 2 80 10
    0 0 84984 6808 14140 126788 1 0 68 57 106 160 4 2 85 9
    0 0 84984 17228 12656 118820 0 0 123 129 152 190 21 1 71 7
    0 0 84984 10316 11720 124564 1 0 440 142 157 298 17 3 55 24
    1 0 84984 8780 11988 126272 1 0 94 71 115 247 11 3 74 12
    1 0 84984 3444 19464 124052 0 0 475 292 207 285 5 2 65 28
    0 0 84984 5164 20224 120500 1 0 207 557 208 256 8 2 66 24
    0 2 84984 6380 20344 120108 0 0 20 123 77 112 3 1 93 4
    0 0 84984 6216 20604 121072 0 0 27 82 88 123 4 1 89 5
    0 0 84960 6380 20252 120060 10 0 265 51 116 168 5 1 78 16
    0 0 84960 3476 20824 122004 0 0 111 85 98 120 2 1 88 10
    0 0 84960 6980 20812 119988 2 0 66 242 114 175 3 1 87 9
  • id:b-wind
    じゃあ -b : バッチモード で動作させてファイルに保存とか。かなりのデータ量になるだろうけど仕方ない。

    /proc ファイルシステムを覗けばある程度情報は得られるはずだけどわりと見やすく出力してくれるコマンドって無いんだよね。
    http://www.linux.or.jp/JM/html/LDP_man-pages/man5/proc.5.html

    あと、ディスクキャッシュなんかも関係してくるので必ずしもIO待ちになっているプロセスが原因とは限らないところには注意。
  • id:matsubobo
    調査を進めました。HDDのがボトルネックではないですが、topで見るとiowaitが高い状態です。
    HDDの最高パフォーマンスの約5%しか使っていないけど、iowaitがCPU時間の13%を消費しています。

    HDDの他にiowaitでカウントするリソースがあるのでしょうか?

    補足:
    iowaitにはネットワークのI/O待ちは含まれていないようです。
    http://www.netfort.gr.jp/~dancer/column/data/20050326-vmstat.pdf

    以下、検証詳細。
    ---------------------------

    ■検証1 ディスクのパフォーマンス測定
    # /sbin/hdparm -tf /dev/sda1

    /dev/sda1:
    Timing buffered disk reads: 90 MB in 3.00 seconds = 29.96 MB/sec

    ■結果1 29.96 MB/sec


    ■検証2
    % vmstat 30
    を行い、16分間データ取得しました。

    ■結果2
    biの平均が、0.815033784 MB/s
    boの平均が、0.536845439 MB/s


    ■結論
    HDDがボトルネックではない。
    HDDのread最高パフォーマンスの約1.8%((0.536/29.96)*100)しか使っていないため。
  • id:pahoo
    スラッシングがそれほど起きていないとするなら、iowait の原因は補助記憶装置のドン詰まりでしょうね。
    以下の確認をお願いします。

    1)HDD以外の補助記憶は使っていませんか?(RAMドライブとかSSDとか)
    2)write速度は計測しましたか?
    3)HDDキャッシュの挙動がおかしいということはありませんか?
    4)アンチウイルスソフトの挙動がおかしいということはありませんか?
    5)RAIDを設定していませんか?
  • id:matsubobo
    コメントありがとうございます。
    VPS上で動いているOSなので、その可能性大いにあります。ISPへ連絡する前にきっちり原因を切り分けておきたいです。

    1)HDD以外の補助記憶は使っていませんか?(RAMドライブとかSSDとか)
    使っていないです。

    % df -ah
    Filesystem Size Used Avail Use% Mounted on
    /dev/sda1 22G 15G 6.1G 72% /
    none 0 0 0 - /proc
    none 0 0 0 - /sys
    none 0 0 0 - /dev/pts
    /dev/sda3 496M 11M 481M 3% /backup


    2)write速度は計測しましたか?
    1GBのシーケンシャルwriteで 24.39MB/s でした。

    3)HDDキャッシュの挙動がおかしいということはありませんか?
    可能性はあります。
    VPSなのでISPに確認する必要があります。

    4)アンチウイルスソフトの挙動がおかしいということはありませんか?
    私用しておりません。

    5)RAIDを設定していませんか?
    しておりません。
  • id:kn1967
    感じとしては
    (1)swap領域不足
    (2)swapディスクの混雑
    (3)swapディスクの物理的不調

    対策としては
    (1)メモリを増やす
    (2)apache、php、MySQLそれぞれのキャッシュ機能などが
      目的に即して有効に活用できているかを確認して、
      プログラム改変。

    ところで・・・、
    コメント欄内でドメイン名明記しちゃってるけど、いいの?
    アクセスしてみたけど、別段遅いとは感じなかったので、
    テストしている回線が細いとか混雑してるだけかも?
  • id:pahoo
    > VPS上で動いているOSなので

    それでは iowait が高いのは仕方がありませんよ。ユーザー数が多かったら、当然そうなります。でも、VPS の root 権限では、他ユーザーのプロセスがどうなっているのかは見えません。
    プロバイダに問い合わせるしかないでしょう。
  • id:kn1967
    >> VPS上で動いているOSなので
    >それでは iowait が高いのは仕方がありませんよ。ユーザー数が多かったら、当然そうなります。

    否定はしないけど、言い切るのはどうだろう?
    ・iowait が高いのは”ある程度”は仕方がありません。
    ・ユーザー数が増えてたり、アクセス数が増えたユーザーがいたりするかもしれませんね。
    くらいがいいんじゃない?
  • id:matsubobo
    kn1967さん>
    ご指摘ありがとうございます。
    該当コメント削除しました。以下に再掲します。

    --------------------------------
    コメントありがとうございます。-dで間隔を1から5秒ほどに長くするとDステータスが表示される場合が少なくなってしまいます。
    以下に、5秒で取ってみた結果です。

    top - 13:04:18 up 23 days, 6:27, 5 users, load average: 0.77, 1.51, 0.95
    Tasks: 137 total, 2 running, 135 sleeping, 0 stopped, 0 zombie
    Cpu(s): 1.7% us, 1.7% sy, 0.0% ni, 58.7% id, 38.0% wa, 0.0% hi, 0.0% si
    Mem: 262280k total, 259044k used, 3236k free, 3868k buffers
    Swap: 1048568k total, 118664k used, 929904k free, 131848k cached

    PID USER PR NI %CPU TIME+ %MEM VIRT RES SHR S COMMAND
    3869 mysql 16 0 2.7 0:01.06 14.9 361m 38m 13m S /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var --user=mysql --pid-file=/usr/local/mysql/var/xxxxxxxxxxxxxxxx.pid --skip-locking -
    2460 mysql 15 0 0.3 0:16.99 14.9 361m 38m 13m S /usr/local/mysql/libexec/mysqld --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var --user=mysql --pid-file=/usr/local/mysql/var/xxxxxxxxxxxxxxxx.pid --skip-locking -
    2678 root 16 0 0.3 0:00.70 0.4 2000 1064 756 R top
    2819 apache 17 0 0.3 0:01.41 7.0 55924 17m 12m R /usr/local/apache2/bin/httpd -k start
    1 root 16 0 0.0 0:05.57 0.1 1624 376 348 S init [3]
    2 root RT 0 0.0 0:00.00 0.0 0 0 0 S [migration/0]
    3 root 34 19 0.0 0:02.00 0.0 0 0 0 S [ksoftirqd/0]
    4 root RT 0 0.0 0:00.03 0.0 0 0 0 S [watchdog/0]
    5 root 10 -5 0.0 0:00.35 0.0 0 0 0 S [events/0]
    6 root 14 -5 0.0 0:02.74 0.0 0 0 0 S [khelper]
    7 root 10 -5 0.0 0:00.01 0.0 0 0 0 S [kthread]
  • id:matsubobo
    kn1967さん>
    原因は物理メモリ不足によるswapかと考えましたが、
    ・物理メモリに100MBほど余裕がある
    ・Swap領域をほとんど使用していない
    という理由から違うと考えます。
  • id:BlueSkyDetector
    他の方も書いていますが、xen上では他の仮想マシンが大量のディスク書き込みをすると、自分の仮想マシンのディスク書き込みに遅延が発生してもおかしくありません。
    VPSのサービスの内容はよく知りませんが、IOパフォーマンスについてはベストエフォートになっているのではないでしょうか。

    もし、xenのホスト側でxentopなどを実行できるならば、どの仮想マシンが原因になっているか調べることは可能だと思いますが、xen上の仮想マシンしか扱えない状況でIO遅延の原因を特定することは困難です。
  • id:BlueSkyDetector
    もし、VPSではない環境に移行することができないのならば、突然IOパフォーマンスが落ちることを前提として、なんとかやりくりをするしかないでしょう。
    優先的にIOを使用できるプロセスを設定する程度しか思い浮かびませんが。。。
  • id:matsubobo
    BlueSkyDetector さん>
    確かに、CPU時間、メモリは保証されていますがIOは保証されていません。

    もう少し調べて、ISPに問い合わせます。

この質問への反応(ブックマークコメント)

トラックバック

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません