☰

리디렉션 방법에 따라 명령 실행 기간에 차이가 있는 이유는 무엇입니까?

tag-icon • tag-icon io-redirection tty time
리디렉션 방법에 따라 명령 실행 기간에 차이가 있는 이유는 무엇입니까?

find일반 사용자로 시간 제한 명령을 실행하고 있습니다 .

내가 아는 것은 리디렉션이 터미널에서 stdout/stderr 메시지를 방지하는 것입니다. 그렇다면 리디렉션 방법에 따라 시간이 걸리는 이유는 무엇입니까? tty의 쓰기 속도와 관련이 있나요? 아니면 그 뒤에 다른 이유가 있나요? 누군가 이것을 이해하는 데 올바른 방향을 알려줄 수 있습니까?

$ id
uid=1000(user1) gid=1000(user1) groups=1000(user1),1001(user2)

$time find /
<truncated output>
real    0m13.902s
user    0m0.197s
sys 0m0.448s

$ time find /  >/dev/null  
<truncated output>
real    0m0.298s
user    0m0.068s
sys 0m0.206s

$time find /  2> /dev/null 
<truncated output>
real    0m13.279s
user    0m0.181s
sys 0m0.405s

$ time find /  > /dev/null 2>&1
real    0m0.306s
user    0m0.109s
sys 0m0.174s

답변1

프로세스( find)가 실제로 출력을 작성해야 하는 경우 해당 출력을 삭제하도록 지시할 때보다 분명히 훨씬 더 오랜 시간이 걸립니다.

  • 를 사용하면 find /stdout과 stderr이 모두 터미널로 전송되며 둘 다 기록해야 합니다(즉, 실제 결과와 모든 권한 오류 등).

  • 사용하면 time find / >/dev/null명령의 표준 출력이 삭제되지만 여전히 모든 오류(있는 경우)가 인쇄됩니다. 귀하의 결과를 보면, 합법적인 결과가 많고 오류가 거의 없습니다.

  • 를 사용하면 time find / 2> /dev/null명령의 표준 출력이 여전히 터미널로 전송되지만 이제 단순히 stderr을 삭제하는 것뿐입니다. 읽기 권한이 없는 파일 시스템을 찾는 경우 실제로는 매우 빠릅니다.

  • 을 사용하면 time find / > /dev/null 2>&1표준 출력을 삭제한 다음 표준 출력이 전송되는 위치로 표준 오류를 보냅니다. 즉, 둘 다 삭제하는 것입니다. 이는 아무것도 출력하지 않으므로 모든 명령 중에서 가장 빠릅니다.

답변2

내가 아는 것은 리디렉션이 터미널에서 stdout/stderr 메시지를 방지하는 것입니다.

아니요. 파일로 리디렉션할 수도 있습니다.

find / > ~/all-the-files

tty의 쓰기 속도와 관련이 있습니까?

한마디로 그렇습니다.

사용 중인 터미널의 종류(Linux의 가상 콘솔, 로컬 xterm, SSH 연결을 통한 것)에 관계없이 실제 터미널 에뮬레이터는 터미널에 인쇄된 모든 것을 그려야 합니다. 이 경우에는 스크롤되지만 곧 나가요. (여기서는 연결 오버가 mosh예외일 수 있습니다.)

네트워크 연결을 통해 고려해야 할 전송 지연도 있습니다. 전체가 아닌 많은 데이터가 있는 경우 일부 데이터가 버퍼링될 수 있습니다. 무언가를 로 리디렉션하면 /dev/null어디에도 저장되지 않고 그려지지도 않습니다. OS는 아마도 쓰기를 메모리에 캐시하고 나중에는 실제로 디스크에 느리게 쓰기 때문에 적당한 양의 데이터를 사용하면 파일로 리디렉션하는 속도가 빨라집니다. 데이터 양이 많으면 디스크에 쓰는 것도 병목 현상이 발생할 수 있습니다. (또는 프로세스가 동기 I/O 모드에서 출력을 쓰도록 관리한 경우)

많은 출력을 수행하는 프로그램의 경우 출력을 포맷하고( printf()프로세스 내에서) 이를 작성하기 위해 OS를 호출하는 프로세스에만 데이터가 /dev/null. 그러한 경우에는 프로그램이 출력을 완전히 금지하도록 설득할 수 있다면 훨씬 더 빠를 수도 있습니다. 아마도 의 경우에는 그렇지 않을 것입니다 find. I/O 속도나 시스템 호출 오버헤드에 묶여 있을 것이라고 가정합니다.

또한 동일한 디렉토리 트리에서 반복적으로 실행하는 경우 find처음에는 디스크에서 읽어야 할 수 있지만 그 이후에는 많은 데이터가 OS에 의해 캐시되므로 처음에는 다른 것보다 느릴 수 있습니다. .

관련 정보