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의 힌트 덕분에 나는 straceMB/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이 놀라서 /tmp에 1.6테라바이트 파일을 쓰는 원인이 되는 손상된 이미지가 있을 수 있습니다.
좀 더 찾아보고 더 많은 정보를 찾으면 업데이트를 게시하겠습니다. 지금까지 힌트를 주신 모든 분들께 감사드립니다.
답변1
댓글이 답변으로 변환되었습니다.
Apache PID 24801 및 25281은 각각 5.84M/s 및 5.75M/s로 가장 많은 I/O를 수행합니다. iotop -oI/O를 수행하지 않는 프로세스를 제외하는 데 사용합니다 .
답변2
iotop과 호환되는 커널 수준이 아니기 때문에 iotop을 신뢰할 수 있는지 잘 모르겠습니다.
나는 당신과 같은 커널(2.6.18)을 사용하고 있으며 iotop -o도 작동하지 않습니다. IO 생성 프로세스만 표시되지 않습니다.