높은 서버로드-99.99 % IO를 사용하는 [jbd2 / md1-8]

지난주로드가 급증했습니다. 이것은 보통 하루에 한두 번 발생합니다. iotop에서 [jbd2 / md1-8]이 99.99 % IO를 사용하고 있음을 식별했습니다. 로드 시간이 많으면 서버에 대한 트래픽이 없습니다.

서버 사양은 다음과 같습니다.

• AMD Opteron 8 코어
• 16GB RAM
• 2x2.000 GB 7.200 RPM HDD 소프트웨어 RAID 1
• Cloudlinux + Cpanel
• MySQL이 제대로 조정되었습니다

스파이크와는 별도로 부하는 최대 0.80입니다.

주변을 검색했지만 [jbd2 / md1-8]의 기능을 정확히 찾을 수 없습니다. 누구 든지이 문제가 있거나 가능한 해결책을 알고 있습니까?

감사합니다.

최신 정보:

TIME        TID     PRIO     USER    DISK READ    DISK WRITE    SWAPIN  IO       COMMAND
16:05:36     399     be/3    root    0.00 B/s      38.76 K/s    0.00 %  99.99 %  [jbd2/md1-8]

정확한 원인을 제시하기에 충분한 컨텍스트가 없기 때문에 이것은 실제로 답이 아니지만, 그것이 나에게 일어날 때 이것을 추적하는 방법에 대한 설명입니다.

내 눈치 jbd2/md0-8상단에 게재 보관 iotop. 나는 /sys/kernel/debug/tracing/events/jbd2무엇 jbd2을하고 있는지 결정하기 위해 어떤 옵션이 있는지 살펴 보았습니다 .

참고 -1 : 디버그 추적 이벤트에 대한 출력을 보려면 cat /sys/kernel/debug/tracing/trace_pipe- 추적 을 활성화 / 비활성화하는 동안 터미널에서 실행했습니다.

참고 -2 : 추적을 위해 이벤트를 활성화하려면 예를 들어 echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable. 비활성화 echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable합니다.

나는 가능하게 시작했다 /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable-그러나 그것의 출력에서 ​​특히 흥미로워 보이는 것은 아무것도 없었다. 나는 추적하기 위해 몇 가지 다른 이벤트를 시도했으며 활성화했을 때 /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable매초마다 발생하는 것을 보았습니다.

# cat /sys/kernel/debug/tracing/trace_pipe
...
jbd2/md0-8-2520  [004] .... 658660.216492: jbd2_commit_flushing: dev 9,0 transaction 32856413 sync 0
jbd2/md0-8-2520  [001] .... 658661.334900: jbd2_commit_flushing: dev 9,0 transaction 32856414 sync 0
jbd2/md0-8-2520  [001] .... 658661.394113: jbd2_commit_flushing: dev 9,0 transaction 32856415 sync 0

이것은 sync(2)/ fsync(2)/ 와 관련이있는 것처럼 보였으 msync(2)므로 이것을 프로세스에 연결하는 방법을 찾고 이것을 찾았습니다.

# find /sys/kernel/debug/tracing/events/ | grep sync.*enable
...
/sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable
...

활성화하면 다음과 같은 결과가 나타납니다.

# cat /sys/kernel/debug/tracing/trace_pipe
...
      nzbget-17367 [002] .... 658693.222288: ext4_sync_file_enter: dev 9,0 ino 301924373 parent 301924357 datasync 1 
  jbd2/md0-8-2520  [001] .... 658693.284080: jbd2_commit_flushing: dev 9,0 transaction 32856465 sync 0
      nzbget-17367 [000] .... 658693.334267: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 
  jbd2/md0-8-2520  [002] .... 658693.334275: jbd2_commit_flushing: dev 9,0 transaction 32856466 sync 0
      nzbget-17367 [001] .... 658694.369514: ext4_sync_file_enter: dev 9,0 ino 301924367 parent 301924357 datasync 1 
  jbd2/md0-8-2520  [002] .... 658694.414861: jbd2_commit_flushing: dev 9,0 transaction 32856467 sync 0
      nzbget-17367 [001] .... 658694.470872: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1 
  jbd2/md0-8-2520  [002] .... 658694.470880: jbd2_commit_flushing: dev 9,0 transaction 32856468 sync 0

이것은 나에게 프로세스 이름 / id를 주었다. 그리고이 프로세스에 대한 디버깅을 한 후에 ( nzbget) fsync(2)매 초마다 수행 되고 있음을 발견했다 . 구성을 변경 한 후 ( FlushQueue=no문서화되지 않은 것으로 생각하고 소스에서 찾았습니다.) 초당이 작업을 수행하지 못하게 fsync(2)하면 문제가 사라졌습니다.

내 커널 버전은 4.4.6-gentoo. make oldconfig커널 설정의 어느 시점에서 /sys/kernel/debug이러한 이벤트 를 얻기 위해 (수동으로 또는으로 ) 활성화 한 옵션이 있다고 생각합니다. 그것.

이것은 저널 업데이트 관련 문제인 것 같습니다. 소프트웨어 RAID로 구성된 디스크 수 명령을 만드는 데 사용 된 명령을 보여줄 수 있습니까?

dumpe2fs 출력을 붙여 넣을 수도 있습니다. 먼저로드가 보이는 물리적 장치를 식별하십시오. 이것을 알고 싶다면 df를 사용하십시오. 그때,

dumpe2fs /dev/sdaX > /tmp/dump

귀하의 경우 / dev / md0 일 수 있습니다.

또한 이것을 실행하십시오.

iostat -xdk 1 25

IO 문제가 많을 때

나는 cloudlinux를 모르지만 그 아래에서 사용할 수있는 blktrace 도구입니다.