生活随笔
收集整理的這篇文章主要介紹了
linux io阻塞问题
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
在linux 上 磁盤讀寫過高 的 I/O 問題 導致 cpu wait 問題，這里是用一些方法找出問題。
首先 使用 top 命令找出 出現 cpu 中 是否進程運行等待問題
＃ top
[cpp]?view plaincopy
top?-?03:57:39?up?1?day,?15:40,??0?users,??load?average:?0.00,?0.00,?0.00??Tasks:???8?total,???1?running,???7?sleeping,???0?stopped,???0?zombie??%Cpu(s):??0.0?us,??0.0?sy,??0.0?ni,100.0?id,??95.1?wa,??0.0?hi,??0.0?si,??0.0?st??KiB?Mem?:??1019664?total,???174644?free,????78960?used,???766060?buff/cache??KiB?Swap:??1165316?total,??1154816?free,????10500?used.???272848?avail?Mem???
?在％Cpu(s) 一行中 95.1 wa (例子數據)
表示cpu 中出現嚴重等待問題，可能導致的原因就包括 讀寫磁盤 I/O 造成的
查找是否是 (確定 上面假設)I／O阻塞問題
方法有二
方法一
[cpp]?view plaincopy
$?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??
上面的指標 有有三個需要明白
%util 111.41??利用率，說明了磁盤 的 讀寫io 過高了，出現了延遲狀況
await 響應時間 ?svctm 表示平均每次設備I/O操作的服務時間 ?await 和?svctm 越接近表示幾乎沒有I/O等待，上面差距大
r/s 117.28? 讀出請求數 ?w/s 29.32? 寫入請求數 ?說明讀出次數過高
其它參數
[cpp]?view plaincopy
rrqm/s：每秒這個設備相關的讀取請求有多少被Merge了（當系統調用需要讀取數據的時候，VFS將請求發到各個FS，如果FS發現不同的讀取請求讀取的是相同Block的數據，FS會將這個請求合并Merge）；wrqm/s：每秒這個設備相關的寫入請求有多少被Merge了。????rsec/s：每秒讀取的扇區數；??wsec/：每秒寫入的扇區數。??rKB/s：The?number?of?read?requests?that?were?issued?to?the?device?per?second；??wKB/s：The?number?of?write?requests?that?were?issued?to?the?device?per?second；??avgrq-sz?平均請求扇區的大小??avgqu-sz?是平均請求隊列的長度。毫無疑問，隊列長度越短越好。??????await：??每一個IO請求的處理的平均時間（單位是微秒毫秒）。這里可以理解為IO的響應時間，一般地系統IO響應時間應該低于5ms，如果大于10ms就比較大了。???????????這個時間包括了隊列時間和服務時間，也就是說，一般情況下，await大于svctm，它們的差值越小，則說明隊列時間越短，反之差值越大，隊列時間越長，說明系統出了問題。??svctm????表示平均每次設備I/O操作的服務時間（以毫秒為單位）。如果svctm的值與await很接近，表示幾乎沒有I/O等待，磁盤性能很好，如果await的值遠高于svctm的值，則表示I/O隊列等待太長，?????????系統上運行的應用程序將變慢。??%util：?在統計時間內所有處理IO時間，除以總共統計時間。例如，如果統計間隔1秒，該設備有0.8秒在處理IO，而0.2秒閑置，那么該設備的%util?=?0.8/1?=?80%，所以該參數暗示了設備的繁忙程度??。一般地，如果該參數是100%表示設備已經接近滿負荷運行了（當然如果是多磁盤，即使%util是100%，因為磁盤的并發能力，所以磁盤使用未必就到了瓶頸）。??
參考?http://www.cnblogs.com/ggjucheng/archive/2013/01/13/2858810.html
方法二
[cpp]?view plaincopy
root@50e261fb9e06:/var#?dstat?-d??-dsk/total-???read??writ??1081B??977B?????0?????0??????0?????0??????0?????0??????0?????0??
使用 dstat ，其實他就是集成了iostat , vmstat,netstat,ifstat 等工具而已
現在確定了 是 I／O 問題了，接著找出哪個進程 操作哪些文件而導致上面的原因的
同樣提供兩種方法
第一種 根據 linux IO 讀寫 epoll 機制（省略，研究中...)讀寫時會合理運用資源，就是某某進程在讀資源，就會先sleep 一會，把cpu讓給其他進程，那么阻塞的時候就會不間斷的sleep 或 ps 里面 的?狀態或“D”狀態，所以可以用腳本找出如下可疑進程
[cpp]?view plaincopy
#?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??----??
第二種方法使用 ? iotop 工具，這個可能需要安裝，不是系統自帶的
[cpp]?view plaincopy
Total?DISK?READ?:???????0.00?B/s?|?Total?DISK?WRITE?:???????7.87?K/s??Actual?DISK?READ:???????0.00?B/s?|?Actual?DISK?WRITE:???????7.87?K/s??TID??PRIO??USER?????DISK?READ??DISK?WRITE??SWAPIN?????IO>????COMMAND??20736?be/4?www-data????0.00?B/s????7.87?K/s??0.00?%??0.08?%?php-fpm:?pool?www??
上面可以看到當前系統讀寫高的進程（已經排序）和 PID
找到 PID 號號辦事啊
現在已經發現是哪個進程導致的問題，跟著呢，找出磁盤上哪個文件的讀寫過高問題
使用 lsof 命令 最簡單用法是
lsof -p 20736(pid 號)
[cpp]?view plaincopy
root@iZ28ec5minyZ:~#?lsof?-p?20736??COMMAND?????PID?????USER???FD???TYPE?DEVICE?SIZE/OFF????NODE?NAME??php-fpm7.?20736?www-data??cwd????DIR??253,1?????4096???????2?/??php-fpm7.?20736?www-data??rtd????DIR??253,1?????4096???????2?/??php-fpm7.?20736?www-data??txt????REG??253,1??4277456?1196882?/usr/sbin/php-fpm7.0??php-fpm7.?20736?www-data??mem????REG??253,1????43616??798292?/lib/x86_64-linux-gnu/libnss_files-2.19.so??php-fpm7.?20736?www-data??mem????REG??253,1????47760??798284?/lib/x86_64-linux-gnu/libnss_nis-2.19.so??php-fpm7.?20736?www-data??mem????REG??253,1????97296??798280?/lib/x86_64-linux-gnu/libnsl-2.19.so??php-fpm7.?20736?www-data??mem????REG??253,1????39824??798279?/lib/x86_64-linux-gnu/libnss_compat-2.19.so??php-fpm7.?20736?www-data??DEL????REG????0,4????????????21893?/dev/zero??
上面的 iostat 可以看到哪個磁盤，lsof 可以找出進程控制的文件，然后找出大致是那幾份文件出問題了
ok！
參考資料?http://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/
總結
以上是生活随笔為你收集整理的linux io阻塞问题的全部內容，希望文章能夠幫你解決所遇到的問題。
如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。
