linuxの高I/O Wait問題の検出と解決–linuxで高io待ちが発生するプロセスの検出方法

linuxは多くの使用可能なツールで並べ替えを発見することができ、使いやすいものもあれば、法則が高度なものもあります.
I/O waitの問題を表示するには、高度なツールだけでなく、基本的なツールの高度な使い方も必要です.I/O waitがチェックしにくいのは、デフォルトでは多くのツールがシステムのI/Oブロックを教えてくれているからですが、どのプロセスが原因の問題を特定するために範囲を縮小するツールはそれほどありません.
まず、I/Oがシステムを遅らせるかどうかを答えます.I/Oがシステムを遅らせるかどうかを確定します.多くのツールを使用することができますが、最も簡単なのはunixコマンドtopです.

[root@coolnull ~]# top
 top - 14:31:20 up 35 min, 4 users, load average: 2.25, 1.74, 1.68
 Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie
 Cpu(s): 2.3%us, 1.7%sy, 0.0%ni, 0.0%id, 96.0%wa, 0.0%hi, 0.0%si, 0.0%st
 Mem: 245440k total, 241004k used, 4436k free, 496k buffers
 Swap: 409596k total, 5436k used, 404160k free, 182812k cached

CPU(s)の行から、現在のCPU I/O Waitの状況がわかります.高いwaほど多くのcpuリソースがI/Oを待っていることを示します

wa -- iowait
Amount of time the CPU has been waiting for I/O to complete.    //cpu    I/O     

 
どのハードディスクが上に書き込まれているかを調べるtopコマンドは、システム面からI/O Waitがほぼ表示されていますが、どのハードディスクが影響を受けているかは教えていません.iostatコマンドを使用する必要があります

[root@coolnull ~]# iostat -x 2 5
 avg-cpu: %user %nice %system %iowait %steal %idle
  3.66 0.00 47.64 48.69 0.00 0.00

 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
 sda 44.50 39.27 117.28 29.32 11220.94 13126.70 332.17 65.77 462.79 9.80 2274.71 7.60 111.41
 dm-0 0.00 0.00 83.25 9.95 10515.18 4295.29 317.84 57.01 648.54 16.73 5935.79 11.48 107.02
 dm-1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13.94 2329.08 10.93 107.02

上記の例のiostatコマンドは、2秒ごとにレポートを5回印刷します.-xパラメータはiostataにより詳細なレポートを印刷するように伝えます
iostatが印刷した1番目のレポートは、最後のシステム起動の時間統計に基づいています.このため、iostatが印刷した最初のレポートは、ほとんどの場合無視されるべきである.各サブレポートは、前回のレポートに基づいています.この例では、私たちのコマンドは5回のレポートを印刷し、2回目のレポートは1回目のレポートからハードディスクデータを印刷し、3回目のレポートは2回目に基づいています.
上記の例では、sdaディスクの%utilizedは111.41%に達しています.これは、I/Oの遅いプロセスがsdaディスクに書き込まれていることを示します.このテスト例では1つのハードディスクしかありませんが、複数のハードディスクを持つサーバではI/Oを使用するプロセスの範囲を縮小できます.
iostatの%utilizedは豊富な情報を提供するほか、rrqm/s、wrqm/sのような毎秒の読み取り、書き込みの要求数、r/s、w/sの毎秒の読み取り、書き込み数も役に立ちます.私たちの例では、私たちのプログラムが読み書きが重いように見える情報も、この嫌なプロセスを特定するのに役立ちます.
高I/Oを引き起こすプロセスiotopの検索

[root@coolnull ~]# iotop
 Total DISK READ: 8.00 M/s | Total DISK WRITE: 20.36 M/s
  TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
 15758 be/4 root 7.99 M/s 8.01 M/s 0.00 % 61.97 % bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp

どのプロセスで最もハードディスク(HDD)を使用するかを確認する最も簡単な方法はiotopコマンドを使用することです.データを見ることで、bonnie++というプロセスが私たちの機械の高I/Oを引き起こしたと簡単に判断できます.
iotopは使いやすいですが、デフォルトの主流のlinuxリリースではインストールされていません.また、個人的にはデフォルトシステムに依存してインストールされていないコマンドもお勧めしません.システム管理者は、これらの非デフォルトパッケージを短時間で簡単にインストールすることはできません.
iotopが使えない場合は、以下のステップで嫌なプロセスの範囲を縮小することができます.
プロセスステータスリスト
psコマンドはメモリ、cpuの場合は印刷できますが、ハードディスクI/Oの場合は印刷できません.psはI/Oを印刷できない場合がありますが、プロセスがI/Oを待っているかどうかを示すことができます.
The ps state field provides the processes current state; below is a list of states from the man page. psステータス列はプロセスの現在のステータスを提供し、manpsから取得したプロセスstatリスト

PROCESS STATE CODES
 D uninterruptible sleep (usually IO)
 R running or runnable (on run queue)
 S interruptible sleep (waiting for an event to complete)
 T stopped, either by a job control signal or because it is being traced.
 W paging (not valid since the 2.6.xx kernel)
 X dead (should never be seen)
 Z defunct ("zombie") process, terminated but not reaped by its parent.

I/O待ちのプロセスはuninterruptible sleepまたはD状態にある.これらの情報を与えることで、wait状態にあるソースのプロセスを簡単に検索することができます.
例:

[root@coolnull ~]# for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done
 D 248 [jbd2/dm-0-8]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
 D 22 [kswapd0]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
 D 22 [kswapd0]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
 D 22 [kswapd0]
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----
 D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp
 ----

上記コマンドは、5秒ごとにD状態のプロセスを10回繰り返し印刷します
上記の出力からbonnie++がわかり、pid 16528は他のプロセスよりもI/Oを占有している.この点、bonnie++はI/O Waitを引き起こす可能性が高いように見えます.ただし、プロセスがuninterruptible sleep stateにある限り、これによるI/O waitを完全に特定することはできません.
私たちの疑いを肯定するために、/procファイルシステムを使用することができます.このプロセスディレクトリには、iotopコマンドで取得したI/O値と同じioファイルがあります.

[root@coolnull ~]# cat /proc/16528/io
 rchar: 48752567
 wchar: 549961789
 syscr: 5967
 syscw: 67138
 read_bytes: 49020928
 write_bytes: 549961728
 cancelled_write_bytes: 0

  read_bytesとwrite_bytesはこのプロセスについてハードディスクのバイト数を読み書きします.ここでbonnie++は46 MBを読み出し、524 MBのデータを書き込む.多くのプロセスでは、これは多くないかもしれませんが、私たちのこの例では、高i/o waitを引き起こすのに十分です.
どのファイルが煩雑に書き込まれているかを検索
lsofコマンドは、指定したプロセスが開いているすべてのファイルまたはオプションに依存しているすべてのプロセスを示します.このリストから、ファイルのサイズや/proc ioファイルに現れる回数に応じて、どのファイルが頻繁に書き込まれているかを推測することができます.
出力を減らすために、-pオプションを使用して、指定したプロセスidで開いているファイルのみを印刷できます.

[root@coolnull ~]# lsof -p 16528
 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
 bonnie++ 16528 root cwd DIR 252,0 4096 130597 /tmp
 
 bonnie++ 16528 root 8u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 9u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 10u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 11u REG 252,0 501219328 131869 /tmp/Bonnie.16528
 bonnie++ 16528 root 12u REG 252,0 501219328 131869 /tmp/Bonnie.16528

これらのファイルが煩雑に書き込まれていることをさらに確認するために、/tmpファイルシステムがsdaディスクの一部であるかどうかを見ることができます.

 [root@coolnull ~]# df /tmp
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/mapper/workstation-root 7667140 2628608 4653920 37% /

 
dfの出力から/tmpがルートディレクトリの下の一部であると判断できる.

[root@coolnull ~]# pvdisplay
  --- Physical volume ---
  PV Name /dev/sda5
  VG Name workstation
  PV Size 7.76 GiB / not usable 2.00 MiB
  Allocatable yes
  PE Size 4.00 MiB
  Total PE 1986
  Free PE 8
  Allocated PE 1978
  PV UUID CLbABb-GcLB-l5z3-TCj3-IOK3-SQ2p-RDPW5S

pvdisplayを使用すると、ハードディスクsdaの/dev/sda 5パーティションがworkstation volumeグループが使用しているパーティション、すなわち/tmpディレクトリであることがわかります.上記losfコマンドで列挙された大量のファイルが、頻繁に読み書きされているファイルである可能性が高いことは、与えられた情報によってより安全に言える.
linuxの高I/O Waitの問題を発見して解決します–どのようにlinuxの中で高ioの待つ過程を引き起こすことを発見します
原文URL:http://coolnull.com/4444.html