쓰기 시스템 호출이 너무 많을 때 top이 높은 %wa를 보고하지 않는 이유

Question

몇 가지 시나리오에 대해 몇 가지 실험을 했고 이제 답을 얻은 것 같습니다.

뒤쪽에@소토의견과 인터넷 검색에 따르면 터미널에 인쇄하는 것은 디스크에 쓰는 것과 다르다는 것을 알았습니다. 전자는 추가 처리가 필요하고 스레드는 데이터가 터미널에 인쇄될 때까지 기다려야 하며 터미널의 버퍼링은 동일하게 작동합니다. 디스크 I/O와 같은 방식입니다. 이 답변은 그것을 아주 잘 설명합니다https://stackoverflow.com/questions/6338812/printing-to-the-console-vs-writing-to-a-file-speed.

또한 stdout 대신 파일에 로그를 보내는 것이 더 빠르지만 명령 에 의해 증가하는 sy대신 커널 공간 시간이 증가합니다 . 나는 이것이 sys 호출이 디스크의 파일에 직접 쓰지 않고 대신 파일 시스템의 버퍼로 보내서 가능한 최선의 방법으로 디스크에 쓰기를 처리하기 때문이라는 것을 알았습니다.wa%Topwrite

나중에 sys 호출을 사용하여 모든 로그를 인쇄하여 sync버퍼를 지우고 모든 데이터를 즉시 파일에 커밋하기 시작했습니다. 여기서 wa%IO 작업의 데이터가 예상보다 훨씬 높고 CPU가 대부분 절전 모드인 것을 확인했습니다.

결론적으로:

터미널은 디스크 I/O와 동일하지 않으며 더 느립니다.
시스템 호출을 통해 작성된 I/O 함수는 write파일 시스템 버퍼로 인해 디스크 쓰기 오버헤드를 반드시 증가시키지는 않지만 컨텍스트 전환을 증가시키고 커널 공간에서 CPU 주기를 소비합니다.

Answer 1

몇 가지 시나리오에 대해 몇 가지 실험을 했고 이제 답을 얻은 것 같습니다.

뒤쪽에@소토의견과 인터넷 검색에 따르면 터미널에 인쇄하는 것은 디스크에 쓰는 것과 다르다는 것을 알았습니다. 전자는 추가 처리가 필요하고 스레드는 데이터가 터미널에 인쇄될 때까지 기다려야 하며 터미널의 버퍼링은 동일하게 작동합니다. 디스크 I/O와 같은 방식입니다. 이 답변은 그것을 아주 잘 설명합니다https://stackoverflow.com/questions/6338812/printing-to-the-console-vs-writing-to-a-file-speed.

또한 stdout 대신 파일에 로그를 보내는 것이 더 빠르지만 명령 에 의해 증가하는 sy대신 커널 공간 시간이 증가합니다 . 나는 이것이 sys 호출이 디스크의 파일에 직접 쓰지 않고 대신 파일 시스템의 버퍼로 보내서 가능한 최선의 방법으로 디스크에 쓰기를 처리하기 때문이라는 것을 알았습니다.wa%Topwrite

나중에 sys 호출을 사용하여 모든 로그를 인쇄하여 sync버퍼를 지우고 모든 데이터를 즉시 파일에 커밋하기 시작했습니다. 여기서 wa%IO 작업의 데이터가 예상보다 훨씬 높고 CPU가 대부분 절전 모드인 것을 확인했습니다.

결론적으로:

터미널은 디스크 I/O와 동일하지 않으며 더 느립니다.
시스템 호출을 통해 작성된 I/O 함수는 write파일 시스템 버퍼로 인해 디스크 쓰기 오버헤드를 반드시 증가시키지는 않지만 컨텍스트 전환을 증가시키고 커널 공간에서 CPU 주기를 소비합니다.

쓰기 시스템 호출이 너무 많을 때 top이 높은 %wa를 보고하지 않는 이유

답변1

관련 정보