10 억 개가 넘는 파일이있는 디렉토리에서 "tar"를 실행하면 해당 프로세스는 D 상태로 유지됩니다.

Question

Linux 프로세스 상태에 대해 자세히 알아보기 위해 실험을하고있었습니다.

그래서, 억 이상 파일 (디렉토리가 많은 하위 디렉토리를 재귀 적있다)이있는 디렉토리 (라는 이름의 big_dir)가있다, 그리고 나는 tar -cv big_dir | ssh anotherServer "tar -xv -C big_dir"을 실행하고 tar 프로세스가 D에 남아, 실행 top를 통해 발견 지위. 한편, tar 명령은 파일의 경로를 계속 출력합니다.

디스크 I/O를 수행 중이기 때문에 프로세스가 D 상태에 있었지만 상태가 D와 R 사이를 전환하지 않은 이유는 무엇입니까? 디렉토리 아래에 파일 이름을 인쇄 할 때 CPU 계산을 사용해야합니다. 그렇지 않습니까? 그렇지 않으면 find 명령은 어떻게 인쇄해야 하는지를 알 수 있습니까?

dd if=/dev/zero of=/dev/null을 실행하면 dd 프로세스 상태가 top 출력에서 ​​R 상태로 유지됩니다. 그런데 왜 D 상태가 아니 었습니까? 항상 I/O를하고 있지 않습니까?

Answer 1

/dev/zero 및 /dev/null은 의사 장치입니다. 따라서 그 뒤에는 물리적 장치가 없습니다. 내가

dd if=/dev/zero of=/tmp/zeroes 

을 할 경우

는 topD 상태 나에게 dd을 보여 않습니다. 그러나 많은 시간을 R (CPU 시간)에 소비합니다. top은 프로세스 테이블을 샘플링하기 때문에 일시적인 상태를 보려면 잠시 동안 프로세스 테이블을 감시해야 할 수 있습니다.

위의 tar 예제에서 stdout으로 출력하는 시간은 디스크 시간에 비해 무시할 만하다고 생각합니다. 또한 stdout으로 출력하는 것은 윈도우 시스템 쓰기를 포함하고 프로세스가 잠자고있는 동안에도 수행된다는 점에 유의하십시오. 예 : 나는 지금 yes을 실행 중이며 대부분의 작업이 내 X 서버에서 수행되고 있습니다. yes 과정은

Answer 2

나는 당신의 타르 프로세스가 가끔 R 간다 확신하지만 '아무튼 있기 때문에, 시간이 매우 짧은 기간 동안 아마 (top를 통해) 내가보고 있어요 대부분의 시간 자고있다 특히 네트워크를 통해 데이터를 전송할 때 그렇습니다. 10Gb/s 네트워크 카드가 아니라면 (anotherServer는 실제로 1GB/s에서 작동합니다.) 체인의 가장 느린 부분이 될 것입니다. ssh 자체는 데이터를 암호화 할 때 약간의 오버 헤드가 필요합니다.

디스크에서 데이터를 요청하는 데 몇 마이크로 초가 걸리고 디스크가 헤드를 이동하고 실제 데이터를 읽는 데 몇 밀리 초가 걸릴 것입니다. 그래서 당신은 "R"에 약 0.1 %의 시간을, 나머지는 "D"에 있습니다.