내 기본 데스크탑에는 64GB RAM이 있습니다. 이로 인해 파일 복사나 네트워크 전송과 같이 디스크를 많이 사용하는 작업 중에 더티 쓰기 캐시가 10GB를 초과하는 경우가 자주 발생하는 것으로 보입니다. (전송 전 Dirty값 /proc/meminfo(0 또는 매우 가까운 값)과 전송 중 값(10GB 이상)을 관찰하여 이 값을 모았습니다. ) SSD로 부팅하지만 대용량 데이터 전송은 외장 하드 드라이브에서 처리합니다. 예시 외부 드라이브의 평균 쓰기 속도는 약 100MB/초일 수 있지만, 저는 10Gbit 네트워크를 통해 ZFS 어레이 기반 NAS에 연결되어 있으므로 LAN을 통한 >400MB/초 대역폭이 일반적입니다.
이것의 문제는 멀티태스킹 중이고 다른 작업이 작업을 수행하는 경우 sync(예를 들어 작업 이 완료되기 전에 작업을 수행하는 것과 유사하다고 apt생각 함) 전체 프로세스가 몇 분 동안 중단될 수 있다는 것입니다. 또한 쓰기 프로세스가 여전히 쓰기 중이므로 더티 캐시를 지우는 데 걸리는 시간보다 동기화하는 데 시간이 더 오래 걸릴 수 있습니다. 이는 시스템의 다른 측면에서도 분명했습니다. 즉, 전송 중에 애플리케이션이 무작위로 지연되거나 중단되는 현상이 발생했습니다.dpkgsync
하드 드라이브의 경우에도 10GB의 쓰기 캐시는 상당히 큽니다. 내 NVMe 부팅 SSD의 경우 1GB/초 이상의 쓰기를 달성하면 문제가 없을 수 있지만 상대적으로 느린 드라이브에서는 새 쓰기가 발생하지 않는다고 가정하면 동기화 시간이 2분을 초과할 수 있습니다. 매우 큰 전송이 발생하는 경우 동기화 명령이 10분 이상 지연되는 것을 볼 수 있습니다!
특정 장치가 보낼 수 있는 데이터의 양을 제한하도록 Linux 커널에 지시할 수 있는 방법이 있습니까? (예를 들어, 데이터를 강제로 디스크에 플러시하기 전에 캐시에 512MB의 데이터만 허용하도록 커널에 지시할 수 있다면 이 상황에 엄청난 도움이 될 것입니다.) 이것이 실패하면 시스템을 낮추면서 살아갈 수도 있습니다. -와이드 쓰기 캐시가 있지만 무엇을 해야할지 모르겠습니다.
답변1
장치별 쓰기 캐싱은 아직 구현되지 않았습니다. 귀하가 말하는 문제는 잘 알려져 있습니다. 저는 5년 전에 이렇게 말했습니다.2013년에 "USB 플래시 드라이브 정지" 문제가 발생한 이유는 무엇입니까? 기존의 "I/O 더티 스로틀링 없음" 코드가 이 문제를 해결하지 못하는 이유는 무엇입니까?
아직 64GiB의 RAM이 있으므로 다음과 같이 문제를 직접 해결했습니다.
cat /etc/sysctl.d/dirty.conf
# Per Torvalds advice
vm.dirty_background_bytes = 33554432
vm.dirty_bytes = 134217728
일부 작업 실행 속도가 약간 느려질 수 있지만 문제는 해결될 것입니다.