'D'현황을 정확하게 파악 하려고 노력 중입니다 .
내 경우에는 다음 프로세스가 'D'다음과 같았습니다.
make -f freac/CMakeFiles/freac_objs.dir/build.make freac/CMakeFiles/freac_objs.dir/build
NFS 공유를 사용합니다.
부하도 늘어나고 있다. load_avg는 이제 1600(40개 CPU)입니다. 나는 40개의 프로세서가 허용 가능한 한계라고 생각합니다.
좋아요, 그건 그렇고, 저는 세 가지를 알고 싶습니다:
'D'프로세스가 상태에 있을 때 부하가 증가하는 이유는 무엇 입니까?'D'프로세스가 완전히 종료되지 않고 NFS 공유에 액세스하는 것이 어려운 상태가 되는 이유는 무엇입니까 ?- NFS 공유에 액세스하는 데 갑자기 문제가 발생할 수 있는 이유는 무엇입니까?(주로 네트워크 문제 때문입니까?)
감사해요!
답변1
상태 "D"의 프로세스는 일반적으로(항상은 아니지만) "I/O를 기다리는 동안 차단됩니다". 예를 들어, 디스크가 사용 중이고 서비스 시간이 긴 경우 이런 일이 발생할 수 있습니다. 해당 상태의 프로세스는 D실제 CPU 리소스를 사용하지 않더라도 로드 평균에 포함됩니다.
NFS의 경우 프로세스는 NFS 서버의 응답을 기다리는 "D" 상태에서 많은 시간을 소비할 수 있습니다.
NFS 클라이언트의 기본 동작은 재시도하기 전에 최대 60초 동안 재시도하는 것입니다( timeo의 옵션 참조 man nfs). 이는 문제가 발생하면 프로세스가 최소 60초 동안 I/O를 대기할 수 있음을 의미합니다.
다음에 일어날 일은 retrans설정 및 hard/soft설정에 따라 다릅니다.
파일 시스템이 마운트되면 hard무기한 재시도되고, 마운트되면 soft결국 I/O 요청이 실패합니다. 그러나 timeo및 옵션으로 인해 retrans이것이 즉시 발생하지 않는다는 것을 알 수 있습니다 .
클라이언트는 여러 가지 이유로 NFS 문제를 볼 수 있습니다. 일반적인 이유는 네트워크 대역폭입니다(특히 WiFi 네트워크를 사용하는 경우). 또 다른 이유는 요청 볼륨(병렬로 실행될 경우 병목 현상이 발생할 수 있음)입니다. 디스크 성능이 좋지 않아 서버 자체가 NFS 요청에 응답하는 속도가 느릴 수도 있고, 서버에서 많은 수의 요청을 처리할 만큼 충분한 데몬 스레드를 실행하지 못할 수도 있습니다.