Linux I / O 대기 시간 디버깅

내가 관리하는 두 Linux 시스템에서 일부 I / O 문제가 있습니다. 프로세스는 종종 파일의 open (), unlink () 또는 close ()와 같은 간단한 syscall에서 최대 몇 초 동안 차단된다는 사실을 나타냅니다. 정확히). 문제의 시스템이 약간의 I / O로드를 경험하는 것은 사실이지만, 그러한 엄청난 대기 시간을 정당화하기에 충분하다고 생각할 수는 없습니다. 때로는 통화를 완료하는 데 15 초 이상 걸릴 수 있습니다 (1 ~ 2 초 정도 소요될 수 있음).

내 질문은 : 왜 이런 일이 발생하는지 어떻게 알 수 있습니까? 내가 원하는 것은 커널에서 문제의 프로세스가 무엇을 차단하고 있으며 왜 잠자고 있는지, 바쁘게 진행되는 이유 및 그와 같은 일을 알려주는 도구입니다. 그러한 도구가 있습니까, 아니면 어떤 일이 발생하는지 디버깅하는 다른 방법이 있습니까?

물론, 실제로 무슨 일 이 일어나고 있는지에 대한 단서가 있다면 어떻게 피할 수 있습니까?

기록을 위해 내가 사용하는 파일 시스템은 XFS입니다.

이제는 시간이 지남에 따라이 문제를 직접 해결할 수 있었으므로 적어도 후손을 위해 직접 조사 할 수 있습니다.

불행히도, 나는 커널 업그레이드에서 원래 문제를 잃었지만 대신 성능을 저하시키고 추적하기 어려운 새로운 문제를 얻었습니다. 내가 찾은 기술은 다음과 같습니다.

우선, blktrace/ blkparse는 매우 도움이되는 도구입니다. 요청을 제출 한 프로세스와 같은 많은 유용한 세부 사항으로 개별 I / O 요청의 진행 상황을 추적 할 수 있습니다. tmpfs추적 스토리지 저장 처리가 자체 추적을 시작하지 않도록 출력을 설정하는 것이 좋습니다 .

그래도 지금까지 도움이되었으므로 더 많은 디버깅 기능을 갖춘 커널을 컴파일했습니다. 특히 ftrace커널 공간 내에서 성능이 좋지 않은 프로세스를 추적하여 수행 한 작업과 차단 된 위치를 확인할 수 있었기 때문에 상당히 도움이되었습니다. 디버그 커널을 컴파일하면 작업 WCHAN출력 도 제공 ps되므로 프로세스가 커널 내부에서 수행되는 작업을보다 간단한 경우보다 쉽게 ​​확인할 수 있습니다.

또한 LatencyTop 이 유용하기를 바랐 지만 매우 버그가 많았으며 불행히도 너무 "높은 수준"인 지연 시간 이유 만 표시했습니다.

또한 다음과 같이 매우 가까운 간격으로 iostat내용을 보는 것보다 더 유용하다는 것을 알았 /sys/block/$DEVICE/stat습니다.

while :; do cat /sys/block/sda/stat; sleep .1; done

파일 Documentation/iostats.txt형식에 대해서는 커널 소스 트리를 참조하십시오 stat. 가까운 간격으로 볼 때 I / O 버스트의 정확한 타이밍과 크기 등을 볼 수있었습니다.

결국, 커널 업그레이드 후 내가 겪었던 문제 는 Linux 3.0에 도입 된 기능인 안정된 페이지 로 인해 발생한다는 것을 알았습니다 . 필자의 경우 mmap'ed 페이지를 더럽힐 때 Berkeley DB가 오랫동안 정지되는 원인이되었습니다. 지역 파일. 이 기능을 패치 할 수 있고 Linux 3.9에서 발생하는 문제가 해결 될 수도 있지만 Berkeley DB 를 패치 하여 해당 지역 파일을 다른 디렉토리에 넣을 수있게 함으로써 지금까지 최악의 문제를 해결했습니다. (내 경우 /dev/shm) 문제를 완전히 피할 수 있습니다.

내 경험에 따르면 신비한 시스템 성능 문제를 추적하기 위해 설치할 수있는 가장 간단하고 자세한 통계 도구는 http://freecode.com/projects/sysstat 일명입니다. sar

iostat 명령 출력, 특히 정상적인 시스템로드 (1.0 이하)에서 % iowait가 5-10 % 미만이어야하는 양을 확인하십시오.

STAT 열에 프로세스가 잠겨 있고 IO를 기다리고 있음을 의미하는 D 상태가 표시되면 ps 출력을 확인하십시오. 컨트롤러 또는 디스크의 하드웨어 문제 일 가능성이 높습니다 .SMART 통계와 dmesg 및 syslog에 실마리가 있는지 확인하십시오.

sar 로그를 확인하고 이런 일이 발생하면 최대 시간을 확인한 다음 디스크를 많이 사용하는 cron 작업 (예 : 네트워크를 통한 백업)과 해당 시간을 일치 시키십시오.

보니 ++로 디스크 성능을 벤치마킹 할 수 있습니다

이 질문이 이제 몇 달이 지난 후에도 strace를 언급 할 것이라고 생각했습니다. 이 페이지를 찾는 비슷한 문제가있는 사람에게 도움이 될 수 있습니다.

시험.

strace "application"

당신은 또한 할 수 있습니다

strace -e read,write "application"

읽기 / 쓰기 이벤트 만 표시합니다.

응용 프로그램이 정상적으로로드되고 (시작하는 데 조금 느리지 만) 문제를 발생시키기 위해 정상적으로 사용할 수 있습니다. strace를 시작하는 데 사용한 쉘에 출력이 나타납니다.

strace의 좋은 점은 응용 프로그램이 속도 저하를 트리거 할 때 가장 최근의 함수 / 커널 호출을 볼 수 있다는 것입니다. 당신은 당신의 경우 찾을 수 있습니다 /home계정 NFS에있는 다음 응용 프로그램이 파일 I / O를 통해 NFS에 대한 몇 가지 이유가 몇 가지 어려움을 겪고있다.