프로세스 당 디스크 I / O 사용률을 확인하는 방법

정지 Linux 시스템에 문제가 있으며 sysstat / sar가 디스크 I / O 사용률, 평균 서비스 시간 및 시스템 정지 시점의 평균 대기 시간에서 막대한 피크를보고하는 것을 발견했습니다.

다음에 발생할 때 어떤 프로세스가 이러한 피크를 유발하는지 확인하려면 어떻게해야합니까?
sar로 가능합니까? (예 : 이미 기록 된 sar 파일에서이 정보를 찾을 수 있습니까?

"sar -d"에 대한 출력, 시스템 중단은 약 12.58-13.01pm에 발생했습니다.

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

이것은 어제 시작한 스레드에 대한 후속 질문입니다. 갑작스런 최대 로드 및 디스크 블록 대기 , 아직 문제를 해결할 수 없었기 때문에 문제에 대한 새로운 주제 / 질문을 만들었기를 바랍니다.

다음 피크 활용 기간을 잡을만큼 운이 좋으면 iotop을 사용하여 프로세스 별 I / O 통계를 대화식으로 연구 할 수 있습니다 .

이 명령으로 pidstat 를 사용 하여 20 초마다 프로세스 당 누적 IO 통계를 인쇄 할 수 있습니다 .

# pidstat -dl 20

각 행에는 다음과 같은 열이 있습니다.

• PID-프로세스 ID
• kB_rd / s-작업을 초당 디스크에서 읽은 킬로바이트 수
• kB_wr / s-작업으로 인한 킬로바이트 수 또는 초당 디스크에 기록됩니다.
• kB_ccwr / s-태스크가 디스크 쓰기를 취소 한 킬로바이트 수. 작업이 더티 페이지 캐시를자를 때 발생할 수 있습니다. 이 경우 다른 작업이 설명 된 일부 IO가 발생하지 않습니다.
• Command-작업의 명령 이름입니다.

출력은 다음과 같습니다.

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              

지속적인 모니터링을 능가하는 것은 없습니다. 이벤트 후 시간에 민감한 데이터를 다시 가져올 수는 없습니다 ...

그러나 내포하거나 제거하기 위해 확인할 수 있는 몇 가지 사항이 있습니다/proc . 친구입니다.

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

필드 10, 11은 누적 된 기록 섹터 및 누적 시간 (ms) 기록이다. 핫 파일 시스템 파티션이 표시됩니다.

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

이러한 필드는 PID, 명령 및 누적 IO 대기 틱입니다. 핫 프로세스 가 아직 실행중인 경우 에만 표시 됩니다 . (파일 시스템 저널링 스레드를 무시하고 싶을 것입니다.)

위의 유용성은 가동 시간, 장기 실행 프로세스의 특성 및 파일 시스템 사용 방법에 따라 다릅니다.

주의 사항 : 2.6 이전 커널에는 적용되지 않습니다. 확실하지 않은 경우 설명서를 확인하십시오.

(이제 당신의 미래에 호의를 베풀고 Munin / Nagios / Cacti / 무엇이든;-설치)

사용하십시오 atop. ( http://www.atoptool.nl/ )

atop나중에 대화식 스타일로 읽을 수 있는 압축 파일에 데이터를 씁니다 . 10 초마다 판독 (델타)을 수행하십시오. 1080 번 수행하십시오 (3 시간; 잊어 버린 경우 출력 파일이 디스크에서 실행되지 않습니다).

$ atop -a -w historical_everything.atop 10 1080 &

나쁜 일이 다시 발생하면 :

(백그라운드에서 여전히 실행 중이더라도 10 초마다 추가됨)

% atop -r historical_everything.atop

IO라고 말했기 때문에 3 개의 키를 누르십시오 : tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display

사용하십시오 btrace. 예를 들어 사용하기 쉽습니다 btrace /dev/sda. 명령을 사용할 수 없으면 패키지 blktrace 에서 사용할 수 있습니다 .

편집 : 커널에서 debugfs가 활성화되어 있지 않기 때문에 시도 date >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtf하거나 비슷할 수 있습니다 . 페이지 결함을 기록하는 것은 물론 btrace를 사용하는 것과 동일하지는 않지만 운이 좋으면 디스크 배고픈 프로세스에 대한 힌트를 줄 수 있습니다. 방금 가장 I / O 집약적 인 서버 중 하나를 시도하고 많은 I / O를 소비하는 프로세스를 포함했습니다.