디스크 I / O가 높을 때 시스템 성능 / 응답 성을 향상시키는 방법은 무엇입니까?

디스크 I / O가 높을 때마다 시스템이 평소보다 훨씬 느리고 응답 성이 떨어지는 경향이 있습니다. 이것에 관한 리눅스 커널의 진전은 무엇입니까? 이 문제가 활발히 진행되고 있습니까?

나는 그것이 대부분 해결되었다고 생각합니다. IO가 많은 경우 2.6.36에서 성능이 향상되었으며 2.6.37에서 더 향상 될 것으로 기대합니다. 이 phoronix 기사를 참조하십시오 .

Wu Fengguang과 KOSAKI Motohiro는 이번 주에 "메모리 부족으로 시스템이 응답하지 않고 더티 / 라이트 백 페이지가 많음"버그라고하는 응답 성 문제를 해결할 패치를 발표했습니다. 이 문제를 LKML에보고 한 사용자 중 한 명인 Andreas Mohr는 커널의 vmscan에 적용되는 두 가지 패치를 테스트하여 성공을보고했습니다. Andreas의 문제는 솔리드 스테이트 드라이브가 USB 1.1을 통해 연결된 경우 EXT4 파일 시스템을 만들 때 시스템이 완전히 응답하지 않고 VT로 전환하는 데 20 초 이상 걸린다는 점입니다. 그의 시스템에서 / dev / zero 파일에서 300M을 쓸 때 문제는 더욱 악화되었습니다.

버그에 직접 연결되는 링크는 다음과 같습니다.

또한 Phoronix에서

다행스럽게도 테스트와이 문제가 해결 된 다른 Linux 사용자의 보고서를 통해 게시 된 비교적 작은 vmscan 패치가이 문제를 해결하는 것으로 보입니다. 시스템이 압도적 인 디스크 활동을 유지하고 있다면 사용자 인터페이스 (우리의 경우 그놈)는 여전히 100 % 유동적이지는 않지만 이전보다 훨씬 뛰어나고 현재 Linux 2.6.35 커널에서 발견 된 것입니다.

도있다 Phoronix 2.6.36 릴리스 발표

블록 장벽이 사라지고 성능에 도움 이 될 것 같습니다 .

실제로, 장벽은 블록 I / O 성능을 죽이는 것으로 불쾌한 평판을 가지고 있습니다. 현대 하드웨어가 제공하는 태그가 지정된 대기열 작업은 장벽을 합리적으로 구현해야하지만 이러한 기능을 사용하려는 시도는 일반적으로 어려움을 겪었습니다. 따라서 실제 환경에서는 하드웨어가 실제로 영구 미디어에 데이터를 커밋하도록하기 위해 일부 플러시 작업을 수행하면서 배리어 작업을 수행하기 전에 I / O 요청 큐를 비우는 방식으로 배리어가 구현됩니다. 큐 드레인 작업은 장치를 정지시키고 전체 성능에 필요한 병렬 처리를 중단시킵니다. 장벽의 사용이 고통 스러울 수 있다는 것은 놀라운 일이 아닙니다.

공정한 I / O 스케줄링에 대한 LWN 기사 도 있습니다.

2.6.28에서 ext4가 출시 된 시점에서 IO가 큰 관심으로 다시 일어났다 고 말할 수 있습니다. 다음은 Linux Kernel Newbies Kernel 릴리스에 대한 링크입니다. 블록 및 파일 시스템 섹션을 검토해야합니다. 이것은 물론 불공평 한 감정 일 수도 있고, FS 개발을 시청하기 시작했을 때, 그것이 계속 개선되고 있다고 확신하지만, ext4 문제 중 일부는 사람들이 IO 스택을 열심히 보았거나 그들은 모든 성능 문제를 해결하기 위해 ext4를 기대했을 수도 있고, 그렇지 않은 경우 다른 곳에서 문제를 찾아야한다는 것을 깨달았습니다.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37