디스크 I/O가 높을 때마다 시스템은 평소보다 훨씬 느리고 응답성이 떨어지는 경향이 있습니다. 이 분야에서 Linux 커널은 어떻게 진행되고 있나요? 이 문제가 적극적으로 해결되고 있습니까?
답변1
대부분 해결이 된 것 같아요. IO가 많은 상황에서 성능이 2.6.36에서 향상되었고, 2.6.37에서는 더욱 향상될 것으로 기대합니다. 바라보다이것들 프로닉스기사.
Wu Fengguang과 KOSAKI Motohiro는 이번 주에 이러한 응답성 문제 중 일부를 해결할 것이라고 생각하는 패치를 발표했습니다. 이를 "메모리 부족 및 대량의 더티/쓰기 저장 페이지로 인해 시스템이 응답하지 않음" 버그라고 합니다. Andreas Mohr는 이 문제를 LKML에 보고하고 커널 vmscan에 적용된 두 가지 패치를 테스트하여 성공했다고 보고한 사용자 중 한 명이었습니다. Andreas의 문제는 솔리드 스테이트 드라이브가 USB 1.1을 통해 연결된 경우 EXT4 파일 시스템을 생성할 때 시스템이 완전히 응답하지 않게 된다는 것입니다(VT로 전환하는 데 20초 이상 소요). 그의 시스템에서는 /dev/zero 파일에서 300M을 쓸 때 문제가 더욱 악화되었습니다.
이것은 바로가기 링크입니다허점
포로닉스에서도
다행스럽게도 이 문제를 해결하려는 다른 Linux 사용자의 테스트 및 보고서에 따르면 릴리스된 상대적으로 작은 vmscan 패치가 문제 해결에 더 나은 작업을 수행하는 것으로 보입니다. 시스템이 디스크 활동을 많이 하는 경우 사용자 인터페이스(우리의 경우 GNOME)는 여전히 100% 매끄럽지는 않지만 확실히 이전보다 훨씬 나아졌으며 이는 현재 Linux 2.6.35 커널에서도 볼 수 있습니다. .
것 같다블록 장벽이 사라지고 있다이는 성능 향상에도 도움이 됩니다.
실제로 장벽은 블록 I/O 성능을 파괴하는 것으로 악명 높기 때문에 관리자는 위험에 처해 장벽을 끄려고 하는 경우가 많습니다. 최신 하드웨어에서 제공하는 표시 대기열 작업은 장벽을 합리적으로 잘 구현해야 하지만 이러한 기능을 활용하려는 시도는 종종 어려움에 직면합니다. 따라서 현실 세계에서는 장벽 작업을 실행하기 전에 단순히 I/O 요청 대기열을 지우고 하드웨어가 실제로 데이터를 영구 매체에 커밋할 수 있도록 일부 플러시 작업을 던져 장벽을 구현합니다. 대기열 소진 작업은 장치를 정지시키고 적절한 성능에 필요한 병렬성을 종료합니다. 당연히 장벽을 사용하는 것은 고통스러울 수 있습니다.
IO가 다시 깨어나는 것은 ext4가 2.6.28에 출시되었을 때 일어난 큰 일이었다고 말하고 싶습니다. 다음 링크는Linux 커널의 새로운 기능커널 버전의 경우 "블록" 및 "파일 시스템" 섹션을 살펴봐야 합니다. 물론 이것은 억울한 감정일 수도 있고, FS 개발을 보기 시작한 것처럼 계속해서 개선되고 있다고 확신하지만 ext4의 일부 문제로 인해 사람들이 FS 개발에 대해 진지하게 생각하게 된 것 같습니다. 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