CPU I / O 대기는 약 50 % 정도 일정하지만 실행 iostat 1하면 디스크 활동이 거의 또는 전혀 표시되지 않습니다.

iops없이 대기하는 원인은 무엇입니까?

참고 : 여기에는 NFS 또는 FUSE 파일 시스템이 없지만 Xen 가상화를 사용하고 있습니다.

NFS는이 작업을 수행 할 수 있으며 다른 네트워크 파일 시스템 (및 FUSE 기반 장치)도 비슷한 영향을 미쳤다고해도 놀라지 않을 것입니다.

서버의 다른 VM이 디스크를 손상시킬 가능성이 있습니까?

호스트 노드에 과부하가 걸리면 이상한 결과를 얻을 수 있다는 것을 가상화로 알고 있습니다.

인스턴스 기반 스토리지를 사용하는 Amazon EC2 Xen 환경 인 경우 Amazon에이 이미지가 포함 된 호스트의 상태를 확인하도록 요청하십시오.

이것이 하이퍼 바이저에 액세스 할 수있는 Xen 환경 인 경우 xvda 및 xvdb 장치에 사용되는 디스크 이미지 (파일, 네트워크, LVM 슬라이스 등)없이 IOwait를 확인하십시오. 다른 디스크 장치가 시스템 리소스를 독점하고있을 수 있으므로 일반적으로 하이퍼 바이저에 대한 I / O 시스템을 확인해야합니다.

iostat -txk 5

일반적으로 좋은 시작 진단 도구입니다. 사용 가능한 모든 장치에 대해 5 초의 I / O 요약이 필요하므로 VM 이미지의 사용 여부에 상관없이 유용합니다.

사용 가능한 파일 디스크립터 / 아이 노드를 확인하십시오. 한도에 도달하면 그들은 iowait를 바꾸고 모방합니다.

편집하다

나는 당신이 xen을 사용하는 것을 보았고, 현재 인터럽트를 보았으며, blkif가 정상보다 높다는 것을 알 수 있습니다.

조금 늦었지만 munin을 설치하면 향후 디버깅에 실제로 도움이됩니다.

sudo sysctl vm.block_dump=1

그런 다음 dmesg를 검사하여 블록 읽기 / 쓰기 또는 더티 inode를 수행하는 작업을 확인하십시오.

또한 limits.conf에서 nofile limit을 확인하십시오. 프로세스가 열 수있는 것보다 많은 파일을 요청할 수 있습니다.

경고 : HDPARM은 위험하므로 항상 사용하려는 명령에 대해 읽으십시오!

다른 가상 시스템이 하드 디스크에 스트레스를주지 않으면

hdparm -f

기본 물리 디스크에. 디스크 캐시가 정확하게 작동하지 않을 수 있습니다. 그러면 캐시에 저장된 데이터가 플러시되며 플러시 후 다시 상승 할 것인지 여부에 관계없이 I / O를 지속적으로 모니터링 할 수 있습니다. 그렇다면 캐시 문제 일 것입니다.

로드 평균으로 인해 네트워킹 작업 (즉, 외부 DB 서버에 대한 긴 호출)이 차단되는 것을 보았습니다. 확실하지 않지만 네트워크 IO로 인해 CPU 대기 시간이 길어질 수 있다고 생각합니다. 누구나 확인할 수 있습니까?

네트워크를 통해 자체적으로 마운트되는 루프백 장치 일 수 있습니다.

내 컴퓨터에서 NFS는 가장 큰 IO-WAIT "생산자"입니다. 랩탑에 SSD가있어 빠르기 때문에 "실제 IO"는 문제가되지 않습니다. 그럼에도 불구하고 때로는 마운트 된 nfs 공유로 인해 많은 IO 대기가 있습니다.

SCP는 때때로 IO Wait로 이어지지 만 훨씬 적은 확장으로 이어집니다.

이것은 무엇이든 될 수 있습니다. 그것은 단지 무언가가 I / O 작업의 끝을 기다리고 있음을 의미합니다. ps를 통해 어떤 프로세스인지 파악한 다음 gdb를 첨부하고 역 추적을 확인하여 어떤 호출이 중단되었는지 확인합니다 (일반적으로 네트워크 관련 항목이거나 갑자기 연결이 끊어진 디스크 임). fd 정보는 / proc을 확인하십시오.

또한 RAID 의 디스크에 오류가 발생하기 직전에 비슷한 문제가 발생 했으며 구부러진 일부 SATA 케이블이 실패하기 시작했습니다.

CPU 사용량은 거의 0 % 였지만 4 코어 시스템에서 1 개 이상의 CPU가 IOwait에서 top매우 낮은 IOps 및 대역폭 (찾은 멀티 라인 CPU 디스플레이 를 통해 찾음) 동안 IOwait에서 100 %의 시간을 소비했습니다. )를 통해 iostat발생하지만 높은 인터럽트 활동이 발생합니다. 대화식 명령 줄 사용은 모든 디스크 액세스 (예 : 누군가의 emacs세션 에서 자동 저장 ) 중에 어려움을 겪었지만 IOwait 기간이 지나면 견딜 수있었습니다 (그리고 아마도 많은 재시도 후에 작업이 성공했을 것입니다).