높은 디스크 I / O가 시스템 응답 성 / 성능을 저하시키는 이유는 무엇입니까?

높은 디스크 I / O가 시스템을 너무 느리게하는 이유를 전혀 이해하지 못했습니다. 속도 저하가 하드 / 광학 드라이브 데이터에 의존하는 프로세스에만 영향을 줄 것으로 기대하기 때문에 이상합니다. 그러나 속도 저하는 RAM에로드 된 내용에도 영향을 미칩니다. 나는 여기 iowait을 언급하고 있습니다.

다른 작업을 수행하는 대신 프로세서가 대기하는 이유는 무엇입니까? 누구 든지이 제한 사항을 설명하고 Linux 커널에서 해결되지 않은 이유는 무엇입니까? 이 문제가없는 커널이 있습니까?

[ note ] 이 성능 영역에서 일부 진전 이있었습니다 . 하나는 후자의 커널 (필자의 경우 2.6.37)이 훨씬 더 반응이 좋다는 것입니다.

운영 체제는 사용 가능한 실제 RAM보다 더 많은 메모리를 사용할 수 있도록 가상 메모리를 사용합니다. 커널이 실제 메모리 페이지를 더 잘 사용하기로 결정하면 디스크에 저장하기 위해 내용이 "페이지 아웃"될 수 있습니다. 페이징 아웃되는 동안 이러한 가상 메모리 페이지에 액세스하면 페이지 폴트 가 발생 하고 디스크에서 RAM으로 다시 이동됩니다.

디스크 대기 시간은 밀리 초 단위로 측정되고 RAM 대기 시간은 나노초 단위로 측정되므로 페이지 결함은 성능을 저하시킵니다. (1 밀리 초 = 백만 나노초!)

메모리는 사용자 프로세스뿐만 아니라 커널도 파일 시스템 캐싱과 같은 용도로 사용합니다. 파일 시스템 활동 중에 커널은 최근에 사용한 데이터를 캐시합니다. 동일한 데이터가 곧 다시 사용될 가능성이 높기 때문에 캐싱은 I / O 성능을 향상시켜야합니다.

파일 시스템 캐시에 사용되는 실제 메모리는 프로세스에 사용할 수 없으므로 파일 시스템 활동 중에 더 많은 프로세스 메모리가 페이징 아웃되고 페이지 결함이 증가합니다. 또한 메모리 페이지를 디스크간에 이동하는 데 사용할 수있는 디스크 I / O 대역폭이 적습니다. 결과적으로 프로세스가 중단 될 수 있습니다.

내가 이해하는 한 IOwait는 프로세서가 아닌 프로세스가 IO를 사용할 수 있기를 기다리고 있음을 의미합니다. 프로세서는 하드 드라이브보다 속도가 훨씬 빨라서 더 많은 코드가 더 빨리 완료되고 디스크를 읽어야합니다. 드라이브가 충분히 빠르게 수행 할 수있는 것보다 여러 개를 읽어야 할 경우 프로세서 대기 상태가됩니다. 누가 디스크를 읽고 쓸 것인지 결정하는 방식은 블록 스케줄러 (대부분의 경우 CFQ)에 의해 결정됩니다. CFQ를 사용하고 있고 시스템 응답 성을 높이기 위해 전체 IO 시간을 적게 사용하는 프로세스가 필요한 경우을 사용할 수 있습니다 ionice -c3 <processid>. 이것은 시스템에 다른 프로세스가 필요하지 않은 경우에만이 프로세스 IO를 제공하도록 지시합니다.

이것은 여전히 흥미롭고 iowait 문제를 더 잘 설명합니다.