Hardware

非常高的負載,顯然是由pdflush引起的

  • September 3, 2013

我有一台執行 CentOS 5 的伺服器,它會定期(每天幾次)出現巨大的負載峰值,整個伺服器將停止執行。幾分鐘後,負載將恢復正常,一切恢復正常。

懷疑它與 I/O 以及可能是壞磁碟有關,但由於磁碟使用硬體 RAID,我不確定如何找出問題所在(smartctl 只是說“設備不支持 SMART”)。

所以無論如何,我看到的top是:

top - 08:51:03 up 73 days,  7:45,  1 user,  load average: 69.00, 58.31, 46.89
Tasks: 316 total,   2 running, 314 sleeping,   0 stopped,   0 zombie
Cpu(s): 11.0%us,  1.3%sy,  0.0%ni, 15.2%id, 72.0%wa,  0.0%hi,  0.5%si,  0.0%st
Mem:   8299364k total,  7998520k used,   300844k free,    15480k buffers
Swap: 16779884k total,     4788k used, 16775096k free,  6547860k cached

如您所見,負載高得離譜。並vmstat顯示:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
24 16   5632 296080  23392 6317688    0    0     3    28    0    0  7  1 89  3  0
0 22   5632 292644  23600 6325372    0    0    69 18781 1985 2318  9  2 14 75  0
1 23   5656 299472  23756 6299140    0    0    44 18667 2075 3382 14  2 13 71  0
0 23   5656 304756  24152 6295696    0    0    88 17002 1880 1445  4  1 16 78  0
0 24   5656 296736  24488 6356564    0    0    60 17967 1841  990  2  1 20 76  0
0 21   5672 302248  24764 6388424    0    0    66 17216 1820  749  2  1 24 73  0

在我看來,這是非常高的“wa”值。此外,iotop給出:

Total DISK READ: 77.37 K/s | Total DISK WRITE: 15.81 M/s
 TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                                      
25647 be/4 apache     73.50 K/s    0.00 B/s  0.00 % 99.99 % httpd
24387 be/4 root        0.00 B/s    0.00 B/s 99.99 % 99.99 % [pdflush]
23813 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [pdflush]
25094 be/4 root        0.00 B/s    0.00 B/s 96.72 % 99.99 % [pdflush]
25093 be/4 root        0.00 B/s    0.00 B/s 99.99 % 99.99 % [pdflush]
25095 be/4 root        0.00 B/s    0.00 B/s 99.99 % 99.99 % [pdflush]
25091 be/4 root        0.00 B/s    0.00 B/s  0.00 % 99.99 % [pdflush]
24389 be/4 root        0.00 B/s    0.00 B/s 99.99 % 99.99 % [pdflush]
24563 be/4 root        0.00 B/s    0.00 B/s 99.99 % 99.99 % [pdflush]
24390 be/4 apache      0.00 B/s   23.21 K/s 96.71 % 99.99 % httpd
24148 be/4 apache      0.00 B/s    0.00 B/s 96.71 % 99.99 % httpd
24699 be/4 apache      0.00 B/s    0.00 B/s 99.99 % 99.99 % httpd
23973 be/4 apache      0.00 B/s    0.00 B/s 99.99 % 99.99 % httpd
24270 be/4 apache      0.00 B/s    0.00 B/s 99.99 % 99.99 % httpd
24298 be/4 apache      0.00 B/s 1918.82 K/s 96.71 % 99.02 % httpd
 628 be/3 root        0.00 B/s    0.00 B/s  0.00 % 97.51 % [kjournald]
25092 be/4 root        0.00 B/s    0.00 B/s  0.00 % 96.72 % [pdflush]
24258 be/4 root        0.00 B/s    0.00 B/s 99.99 % 96.71 % [pdflush]
23814 be/4 root        0.00 B/s    0.00 B/s  0.00 % 96.71 % [pdflush]
24388 be/4 root        0.00 B/s    0.00 B/s 99.02 % 96.71 % [pdflush]
25545 be/4 apache      0.00 B/s    0.00 B/s  0.19 % 92.73 % httpd
25274 be/4 apache      0.00 B/s    0.00 B/s  0.00 % 92.38 % httpd
24801 be/4 apache      0.00 B/s    5.84 M/s 99.99 % 91.63 % httpd
25281 be/4 apache      0.00 B/s    5.75 M/s  0.00 % 91.33 % httpd
26115 be/4 apache      0.00 B/s    0.00 B/s  9.60 % 19.26 % httpd
25561 be/4 apache      0.00 B/s    3.87 K/s  0.00 %  9.66 % httpd
26035 be/4 apache      0.00 B/s    0.00 B/s  0.00 %  9.63 % httpd

最後,我得到以下資訊sar -d 5 0

Linux 2.6.18-308.1.1.el5PAE (ausbt.com.au)  23/08/12

08:55:45          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
08:55:50       dev8-0    877.25    103.79  29306.19     33.53    158.81    179.28      1.14     99.84
08:55:50       dev8-1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:55:50       dev8-2      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
08:55:50       dev8-3    877.25    103.79  29306.19     33.53    158.81    179.28      1.14     99.84

這只是最近才說發生(至少,我最近才注意到)並且伺服器上沒有任何變化,所以這就是為什麼我懷疑可能是某種硬體故障,但我不確定從哪裡開始尋找。

更新

感謝 Mark Wagner 的提示,我執行strace了一個正在執行 MB/s I/O 的程序,發現它正在寫入名為“/tmp/magick-XXXXXXX”的文件。這是 `ls -l /tmp/magick-XX*" 的輸出:

-rw------- 1 apache apache 1854881318400 Aug 20 04:26 /tmp/magick-XXrQahSe
-rw------- 1 apache apache 1854881318400 Aug 20 04:26 /tmp/magick-XXTaXatz
-rw------- 1 apache apache 1854881318400 Aug 20 04:26 /tmp/magick-XXtf25pe

哇!這些文件是幾天前的,但今天也有類似大小的文件。我的程式碼使用 ImageMagick 動態生成圖像的縮略圖,因此可能某處存在損壞的圖像,導致 ImageMagick 崩潰並將 1.6 TB 的文件寫入 /tmp。

當我發現更多時,我會做更多的探索並發布更新。感謝大家到目前為止的提示。

評論轉換為答案。

到目前為止,Apache PID 24801 和 25281 的 I/O 最高:分別為 5.84 M/s 和 5.75 M/s。我iotop -o用來排除不執行 I/O 的程序。

我不確定您是否可以信任 iotop,因為您不在與之兼容的核心級別。

我和你在同一個核心(2.6.18)上,我什至無法讓 iotop -o 工作..它並沒有隻顯示 IO 生產過程。

引用自:https://serverfault.com/questions/420233