Ubuntu 18.04 시스템에서 대용량 디스크 이미지 작업을 수행할 때 시스템 전반에 걸친 대기 시간/지연 문제가 발생합니다. 시스템 사양은 다음과 같습니다.
프로세서: Intel Core i7(코어는 용량에 근접하지 않음)
메모리: 12GB(용량에 근접하지 않음)
시스템 디스크: SSD(용량에 근접하지 않음)
외부 디스크: USB 3.0 5400 및 7200RPM 회전 디스크
이러한 대용량 디스크 이미지 작업은 기본적으로 다음과 같습니다.
nice ionice dd if=/dev/usbdisk1 of=/dev/usbdisk2
내 시스템 파일이 USB 디스크에 없기 때문에 이론적으로 대기 시간이 많이 발생해서는 안 됩니다. 하지만 여러 개의 USB 디스크를 이미지화하면 시스템 속도가 느려지는 것을 발견했습니다. 왜? 제가 이해한 바에 따르면 각 디스크에는 자체 IO 대기열이 있는데 여기서 무슨 일이 벌어지고 있는 걸까요? 이 문제를 어떻게 해결할 수 있나요?
또한 FWIW, 저는 USB 디스크 이미징 속도에 전혀 관심이 없으므로 원활한 시스템 작동을 위해 이러한 작업 속도를 늦추는 솔루션이 좋을 것입니다.
답변1
이 문제를 어떻게 해결할 수 있나요?
디스크 이미지에 쓸 때 ddwith를 사용합니다 oflag=direct. O_DIRECT 쓰기는 페이지 캐시를 통한 데이터 쓰기를 방지합니다. oflag=direct좋은 성능을 위해서는 더 큰 블록 크기가 필요합니다 . 예는 다음과 같습니다.
dd if=/dev/usbdisk1 of=/dev/usbdisk2 oflag=direct bs=32M status=progress
참고: 때로는 다른 프로그램에서 파이프를 원할 수도 있습니다(예 gunzip: 이 경우 좋은 성능은 iflag=fullblock다른 명령에 따라 달라지며 이를 통해 dd파이프됩니다 ). 여기에 답변에 대한 완전한 예가 있습니다.dd 파이프라인에 대한 gunzip이 느려지는 이유는 무엇입니까?
(또 다른 해결책은 oflag=sync대신 를 사용하는 것입니다 oflag=direct. 이는 많은 수의 빌드를 구축하지 않음으로써 달성할 수 있습니다.씌어 있지 않은캐시된 페이지).
제가 이해한 바에 따르면 각 디스크에는 자체 IO 대기열이 있는데 여기서 무슨 일이 벌어지고 있는 걸까요?
그들은. 그러나 작성된 데이터는 먼저 시스템 페이지 캐시(RAM)에 저장된 다음 IO가 대기열에 저장됩니다.
편집하다:
이 답변이 승인되었으므로 다시 테스트하여 oflag=direct"시스템이 방금 크롤링되었습니다" 문제가 해결되었다고 가정합니다. 엄청난.
iflag=direct가장 안전한 옵션은 그것도 추가하는 것입니다. 이 옵션이 없으면 dd여전히읽다데이터는 시스템 페이지를 통해 캐시됩니다. 나는 당신이 나에게 말하지 않고 이 옵션을 추가하지 않았다고 가정합니다. 이것은 귀하의 특정 질문에 대한 힌트입니다.
페이지 캐시를 통해 너무 많은 데이터를 읽고 있다는 것이 분명해야 합니다.할 수 있다시스템 성능에 영향을 미칩니다. 페이지 캐시를 통해 푸시하는 총 데이터 양은 시스템 RAM보다 몇 배 더 큽니다. :-). 읽기 패턴에 따라 커널은 공간을 확보하기 위해 캐시된 다른 데이터 삭제(또는 교환)를 시작하기로 결정할 수 있습니다.
커널에는 확실한 비전이 없습니다. 캐시에서 제거된 데이터를 사용해야 하는 경우 디스크/SSD에서 다시 로드해야 합니다. 증거~인 것 같다이것이 당신의 문제가 아니라고 말해주십시오.
더티 페이지 캐시 제한
그러나 귀하의 문제는 다음과 관련이 있을 가능성이 더 높습니다.글쓰기데이터는 페이지를 통해 캐시됩니다. "더티" 페이지 캐시라고도 알려진 기록되지 않은 캐시는 제한되어 있습니다. 예를 들어 전체 더티 페이지 캐시가 RAM의 20%로 제한되어 있다고 가정할 수 있습니다. (상상을 돕기 위한 거짓말이고, 진실은 엉망으로 쓰여져 있다)여기).
명령 dd이 최대 더티 페이지 캐시를 채우면 일부 데이터가 기록될 때까지 강제로 "차단"(대기)됩니다.
그러나 동시에 쓰기를 원하는 다른 프로그램도 차단됩니다(O_DIRECT를 사용하지 않는 한). 이로 인해 많은 데스크톱 프로그램이 로그 파일에 쓰려고 할 때 작동이 중지될 수 있습니다. 서로 다른 장치에 쓰고 있는 경우에도 마찬가지입니다.
전체 더티 한계의 이름 dirty_ratio은 또는 입니다 dirty_bytes. 그러나 전체 이야기는 훨씬 더 복잡합니다. 서로 다른 장치의 더티 캐시 간에는 어느 정도 중재가 있어야 합니다. 초기 임계값을 설정하고 한 장치에서 사용되는 더티 캐시의 최대 비율을 제한해 보세요. 그러나 이 모든 것이 얼마나 잘 작동하는지 정확히 이해하기는 어렵습니다.
"여러 USB 디스크"를 이미징하는 데 문제가 있다고 언급하신 것 같습니다. 예를 들어, 장치별 임계값은 디스크 중 하나에 쓰려고 할 때 제대로 작동하지만 여러 디스크에 동시에 쓰면 충돌이 발생할 수 있습니다. 하지만 그건 단지 생각일 뿐이고, 무슨 일이 일어나는지는 모르겠습니다.
관련된:
일부 사용자는 속도가 느린 USB 드라이브에 쓸 때 전반적인 시스템 지연을 관찰했으며 전체 더티 제한을 낮추면 지연을 방지하는 데 도움이 된다는 사실을 발견했습니다. 나는 이것에 대한 좋은 설명을 모른다.
2013년에 "USB 플래시 드라이브 정지" 문제가 발생한 이유는 무엇입니까? 기존의 "I/O 더티 스로틀링 없음" 코드가 이 문제를 해결하지 못하는 이유는 무엇입니까?