I/O로 인해 시스템이 거의 응답하지 않는 이유는 무엇이며 어떻게 해결할 수 있습니까?

I/O로 인해 시스템이 거의 응답하지 않는 이유는 무엇이며 어떻게 해결할 수 있습니까?

하드 드라이브에서 데이터를 복구하고 있습니다. 디스크가 제대로 작동하고 있습니다. 파일 세트가 실수로 삭제되었습니다. 저는 photorec을 사용하고 있으며 복구된 파일을 다른 물리적 디스크에 저장하고 있습니다. 내 OS와 Exchange가 이것과 다른 장치에 있습니다.

그러나 photorec을 실행하면 내 시스템이 본질적으로 사용할 수 없게 됩니다. Alt 키를 누른 채 다른 창으로 이동(또는 다른 방식으로 전환)하면 5~10초가 걸리고 마우스가 느리고 불안정하며 프로그램이 응답하지 않는 경우가 많습니다. 작업을 완료하려면 출력을 계속 일시 중지해야 합니다(Ctrl-S, photorec이 Konsole 내에서 실행 중임). 출력을 재개하자마자 시스템 속도가 느려지기 시작했고 1분 안에 거의 사용할 수 없게 되었습니다.

niceIO 스케줄링 클래스를 유휴 상태로 설정하고 값을 19()로 설정했지만 이 문제는 계속 발생합니다. 나는 32GB(!!!)의 RAM을 가지고 있는데 그 중 1/3도 채 사용하지 않습니다. HT가 포함된 쿼드 코어 Xeon이 있고 CPU가 사용되지 않습니다(photorec이 일시 중지되면 유휴 상태에서 CPU 사용량이 거의 균일합니다). 두 디스크 모두 100MB/s 이상의 지속적인 전송 속도를 보여주었으므로 하드웨어 성능은 문제가 되지 않습니다. 그러나 CPU+IO 로드가 높을 때 시스템은 이전 Windows 98 시스템보다 느리게 반응했습니다.

정확히 이런 일이 발생하는 이유와 해결 방법은 무엇입니까?

운영 체제는 원래 4.19 커널을 실행하는 Debian 10(buster)입니다.

10개의 스레드/프로세스가 전체 용량으로 실행되는 경우에도(비디오 인코딩이나 대규모 프로젝트 컴파일에는 문제 없음) 시스템을 완전히 사용할 수 있으며 로드로 인해 일반적인 속도 저하가 발생하지 않습니다.

답변1

귀하의 질문 내용 중 일부를 살펴보겠습니다.

출력을 재개하자마자 시스템 속도가 느려지기 시작했고 1분 안에 거의 사용할 수 없게 되었습니다.

이는 무언가가 한동안 백업되고 결국 처리량을 유지할 수 없음을 의미합니다. 다른 모든 디스크와 다른 디스크에 있다고 말했으므로 시스템 전역이어야 합니다.

나는 32GB(!!!)의 RAM을 가지고 있는데 그 중 3분의 1도 채 사용하지 않습니다.

"사용"은 "RSS가 아님"을 의미한다고 생각합니다. 불행하게도 그렇게 간단하지 않으며 페이지 캐싱도 가능합니다.RSS보다 무료로 해제하기가 ​​더 쉽다고 해서 무료라는 의미는 아닙니다. 예를 들어 RSS가 더러워서 먼저 디스크로 다시 플러시해야 할 수도 있습니다. 이 질문이 그 예일 수 있습니다. :-)

이는 일반적으로 a.) 사용 중인 I/O 스케줄러 및 b.) 수행 중인 I/O 유형의 문제입니다. 귀하의 경우 이는 대규모 페이지 캐시 쓰기 저장이 될 수 있으며, 일반적으로 커널은 일단 시작된 후 쉽게 조절하지 않습니다. 이러한 쓰기가 다른 디스크에 있을 수 있더라도 여전히 페이지 캐시 형태의 단일 공유 상태 소스가 있습니다.

I/O 예약 클래스 는 ioniceCFQ I/O 스케줄러에만 영향을 미치며 다른 스케줄러에는 영향을 미치지 않습니다. 그러나 CFQ에는 "지연"보다 "공정성"을 선호하는 여러 가지 절충점이 있으며, 이로 인해 유사한 상황이 발생할 수 있습니다.

CFQ는 TID별 모델을 기반으로 하며 각 스레드에는 자체 대기열이 있습니다. 그런 다음 커널은 이러한 대기열을 반복하고, 각 대기열에서 일부 항목을 팝하고, 해당 항목에서 작업하고, 즐거운 방식으로 진행됩니다. 각 프로세스 대기열의 보장된 작업은 CFQ의 "공정한" 부분입니다. 그러나 공정성이 반드시 성능과 동일하지는 않습니다. 이는 각 프로세스가 일반적으로 동일한 우선순위를 갖음을 의미합니다(ionice와 같은 조정 제외).

대조적으로, 기한은 이름에서 알 수 있듯이 각 I/O 요청에 대해 지연된 시간 초과를 부과하는 것을 기반으로 합니다. TID 수준의 공정성에 중점을 두는 대신 주로 요청 부족(작업 유형별 변수 만료를 통해)을 방지하고 각 프로세스를 A 단위로 처리하는 대신 시스템을 하나의 단위로 처리하는 등 여러 가지 다른 문제에 중점을 둡니다. "공정성"을 위해 운영합니다.

다음을 시도하는 것이 좋습니다.

  1. I/O 스케줄러를 mq-deadline으로 설정합니다. 일반적으로 Deadline은 읽기 작업이 중단되지 않도록 보장하는 데 CFQ보다 낫습니다. 이를 통해 문제의 디스크에 대한 액세스가 종료될 때 이러한 몇 초 동안의 일시 중지를 방지할 수 있습니다. 데스크탑 사용의 맥락에서 반응을 기대할 때 대부분 읽기를 수행하므로 이는 의미가 있습니다.
  2. io.latency제가 조금 다루었던 cgroup v2의 사용을 고려해 보십시오.이 말. 이는 장치별이 아닌 시스템 전체에 적용되며, CFQ를 사용하는 것보다 I/O 보호 및 우선순위 설정을 더 세밀하게 제어할 수 있습니다 ionice. 그런 다음 지연 시간이 짧은 I/O가 필요한 cgroup에서 데스크탑을 실행하고 systemd-run그러한 보호 없이 다른 cgroup에서 데이터 복구를 실행하는 등의 방법을 사용할 수 있습니다. 또한 이를 통해 "중지할 수 없는" 쓰기(예: 페이지 캐시 쓰기 저장)가 발생하기 전에 앞서서 이러한 쓰기를 어느 정도 롤백할 수 있습니다.
  3. 커널 메모리 회수에는 직접 회수와 kswapd 회수의 두 가지 유형이 있습니다. kswapd 재활용은 시스템 메모리 사용량(캐시 포함!)이 100%에 도달하는 것을 방지하려고 노력하는 곳입니다. 이는 우리가 직접 재활용인 재활용의 다음 단계로 넘어가는 것을 방해합니다. 직접 재활용은 애플리케이션이 메모리를 요청하지만 요청을 충족할 만큼 메모리가 충분하지 않을 때 발생합니다. 이는 실제로 다음과 같은 결과를 낳습니다.정지시키다영향을 받는 응용 프로그램으로 인해 귀하가 설명하는 종류의 지연이 발생할 수 있습니다. 이 기간 동안 직접 재활용이 많이 발생하는 경우( grep allocstall /proc/vmstat여기 표시) kswapd 재활용 범위를 낮추면 상황이 개선되는지 테스트해 볼 가치가 있습니다. sysctl을 사용하여 이를 수행 할 수 있습니다 vm.watermark_scale_factor- 참조여기사용 방법에 대한 문서입니다.

관련 정보