나는 왜 높은 디스크 I/O로 인해 시스템 속도가 느려지는지 전혀 이해하지 못했습니다. 속도 저하가 하드 드라이브/광 드라이브의 데이터에 의존하는 프로세스에만 영향을 미칠 것으로 예상했지만 속도 저하가 RAM에 로드된 콘텐츠에도 영향을 미칠 수 있기 때문에 이것은 나에게 이상합니다. 제가 여기서 말하는 것은기다리다.
프로세서가 다른 작업을 수행하는 대신 대기하는 이유는 무엇입니까? 누구든지 이 제한 사항과 Linux 커널에서 이 제한 사항이 해결되지 않는 이유를 설명할 수 있습니까? 이 문제가 없는 커널이 있나요?
[노트] 이미 가지고 있어요약간의 진전이 성능 영역에서. 우선, 최신 커널(내 경우에는 2.6.37)이 더 반응성이 좋습니다.
답변1
운영 체제 활용가상 메모리이를 통해 사용 가능한 실제 RAM보다 더 많은 메모리를 사용할 수 있습니다. 커널이 물리적 메모리 페이지를 더 잘 사용할 수 있다고 결정하면 해당 내용을 디스크에 저장하기 위해 "가져올" 수 있습니다. 콜아웃에서 이러한 가상 메모리 페이지에 액세스하면페이지 오류디스크에서 RAM으로 다시 이동합니다.
디스크 대기 시간은 밀리초 단위로 측정되고 RAM 대기 시간은 나노초 단위로 측정되므로 페이지 오류는 성능에 재앙입니다. (1밀리초 = 100만 나노초!)
메모리는 사용자 프로세스뿐만 아니라 파일 시스템 캐싱과 같은 작업을 위해 커널에서도 사용됩니다. 파일 시스템 활동 중에 커널은 최근에 사용한 데이터를 캐시합니다. 동일한 데이터가 곧 다시 사용될 가능성이 높다고 가정하므로 캐싱을 사용하면 I/O 성능이 향상됩니다.
파일 시스템 캐시에 사용되는 실제 메모리는 프로세스에서 사용할 수 없으므로 파일 시스템 활동 중에 더 많은 프로세스 메모리가 페이지 아웃되고 페이지 오류가 증가합니다. 또한 메모리 페이지를 디스크로 이동하는 데 사용할 수 있는 디스크 I/O 대역폭이 더 적습니다. 따라서 프로세스가 중단될 수 있습니다.
답변2
내가 이해한 바로는 IOwait는 프로세서가 아닌 프로세스가 IO가 사용 가능해질 때까지 기다리고 있음을 의미합니다. 프로세서는 하드 드라이브보다 훨씬 빠르며, 이는 더 많은 코드가 더 빨리 완료되고 디스크에서 읽어야 함을 의미합니다. 읽어야 할 데이터의 양이 드라이브의 읽기 속도를 초과하면 프로세서가 대기합니다. 디스크를 읽고 쓰는 사람을 결정하는 방법은 대부분의 경우 현재 CFQ인 블록 스케줄러에 의해 결정됩니다. 이는 CFQ를 사용하고 시스템 응답성을 향상하기 위해 전체 IO 시간을 줄이는 프로세스가 필요한 경우 사용할 수 있습니다 ionice -c3 <processid>. 이는 시스템이 다른 필요가 없을 때만 프로세스에 IO를 제공하도록 지시합니다.
이것여전히 흥미롭고 iowait 문제를 더 잘 설명합니다.