그래서 내 Linux 데스크톱에서는 일부 대용량 파일을 로컬 디스크나 NFS 마운트에 씁니다.
쓸 데이터를 캐시하는 일종의 시스템 버퍼가 있습니다. (내 시스템의 크기는 0.5-2GB 범위인 것 같아요?)
버퍼가 가득 차면 모든 파일 액세스가 차단되어 쓰기가 완료될 때까지 시스템이 효과적으로 정지됩니다. (읽기 액세스도 차단되어 있다고 확신합니다.)
보장하려면 무엇을 구성해야 합니까?안 돼요발생하다?
내가 원하는 것은:
프로세스가 디스크(또는 네트워크 마운트 등)에 데이터를 충분히 빠르게 쓸 수 없는 경우그 과정디스크가 따라잡을 때까지 차단할 수 있지만 다른 프로세스는 여전히 합리적인 속도와 대기 시간으로 데이터를 읽고 쓸 수 있습니다.어느방해하다.
이상적으로는 특정 유형의 프로그램(cp, git, mplayer, firefox 등)에 대해 dsik의 총 읽기/쓰기 속도를 설정할 수 있습니다.모든 mplayer 프로세스의 총 속도는 시스템의 나머지 부분이 수행하는 작업에 관계없이 최소 10MB/s입니다.". 하지만"그럼에도 불구하고 모든 mplayer 인스턴스는 전체 속도의 최소 50%를 받습니다."그것도 괜찮습니다. (즉, 절대 비율을 설정할 수 있는지 총 비율을 설정할 수 있는지는 별로 상관하지 않습니다.)
더 중요한 것은(가장 중요한 읽기/쓰기가 작기 때문에) 비슷한 대기 시간 설정을 원한다는 것입니다. 다시 말하지만, 무슨 일이 있어도 단일 프로세스의 읽기/쓰기가 10밀리초 이상(또는 무엇이든) 동안 시스템의 나머지 부분을 차단하지 않을 것임을 보장합니다. 이상적으로는 "시스템이 무엇을 하고 있든 mplayer는 읽기/쓰기 작업을 처리하기 위해 10밀리초 이상 기다릴 필요가 없습니다.".
이는 문제의 프로세스가 시작된 방식(실행 중인 사용자 등 포함)에 관계없이 작동해야 하므로 "큰 CP를 ionice로 감싸기"또는 거의 쓸모 없는 다른 것입니다. 이온화하는 것을 기억하면 특정 작업이 예상대로 모든 것을 정지시키는 것을 방지할 수 있지만 크론 작업, 특정 실행 중인 데몬의 exec 호출 등은 어떻습니까?
(최악의 범죄자를 항상 이온화하는 쉘 스크립트로 감쌀 수 있다고 생각하지만, 그럼에도 불구하고 ionice에 대한 매뉴얼 페이지를 검색해 보면 그것이 제공하는 정확한 보장이 약간 모호한 것 같아서 좀 더 체계적이고 유지 관리 가능한 대안).
답변1
일반적으로 Linux는 캐시를 사용하여 디스크에 비동기적으로 데이터를 씁니다. 그러나 쓰기 요청과 실제 쓰기 사이의 시간 간격 또는 기록되지 않은(더티) 데이터의 양이 매우 커지는 경우가 발생할 수 있습니다. 이 경우 충돌로 인해 상당한 데이터 손실이 발생하므로 더티 캐시가 크거나 오래되면 Linux는 동기 쓰기로 전환합니다. 쓰기 순서도 준수해야 하므로 대기열에 있는 모든 이전 쓰기와 완전히 독립적이라는 보장 없이는 작은 IO를 우회할 수 없습니다. 따라서 쓰기에 의존하면 엄청난 지연이 발생할 수 있습니다. (이 종속성은 파일 시스템 수준에서도 발생할 수 있습니다.https://ext4.wiki.kernel.org/index.php/Ext3_Data%3DOrdered_vs_Data%3DWriteback_mode).
내 생각엔 상관 쓰기와 결합된 일종의 버퍼 팽창을 경험하고 있는 것 같습니다. 큰 파일에 쓰고 큰 디스크 캐시가 있는 경우 동기 쓰기를 완료하려면 많은 데이터를 써야 하는 상황이 발생합니다. LWN에는 이 문제를 설명하는 좋은 기사가 있습니다.https://lwn.net/Articles/682582/
스케줄러는 아직 진행 중인 작업이며 새 커널 버전이 나오면 상황이 개선될 수 있습니다. 그러나 지금까지는 Linux의 캐시 동작에 영향을 미칠 수 있는 몇 가지 스위치가 있습니다(그리고 더 많은 스위치가 있습니다. 다음을 참조하세요).https://www.kernel.org/doc/Documentation/sysctl/vm.txt):
- 더러운 비율:사용 가능한 페이지와 회수 가능한 페이지가 포함된 총 사용 가능 메모리의 백분율을 포함합니다. 디스크를 생성하는 프로세스가 쓰는 페이지 수는 더티 데이터 쓰기를 시작합니다. 사용 가능한 총 메모리는 총 시스템 메모리와 동일하지 않습니다.
- 더러운 배경 비율:백그라운드 커널 새로 고침 스레드가 더티 데이터 쓰기를 시작하는 페이지 수를 포함합니다(사용 가능한 페이지와 회수 가능한 페이지를 포함한 총 여유 메모리의 백분율).
- dirty_writeback_centisecs:커널 플러셔 스레드는 주기적으로 깨어나 "오래된" 데이터를 디스크에 씁니다. 이 조정 가능 항목은 이러한 절전 모드 해제 간의 간격을 100분의 1초 단위로 나타냅니다. 0으로 설정하면 주기적 쓰기 저장이 완전히 비활성화됩니다.
- dirty_expire_centisecs:이 조정 가능 항목은 더티 데이터가 커널 플러셔 스레드에 의해 기록될 수 있을 만큼 오래된 시기를 정의합니다. 1/100초 단위로 표현됩니다. 이 간격보다 오랫동안 메모리에 더티된 데이터는 다음에 새로 고침 스레드가 깨어날 때 기록됩니다.
이 경우 최대 대기 시간을 줄이는 가장 간단한 솔루션은 더티 디스크 캐시의 최대 양을 줄이고 백그라운드 작업이 일찍 작성되도록 하는 것입니다. 물론, 대용량 캐시가 동기 쓰기를 방지할 수 없는 경우 성능 저하가 발생할 수 있습니다. 예를 들어 /etc/sysctl.conf에서 다음을 구성할 수 있습니다.
vm.dirty_background_ratio = 1
vm.dirty_ratio = 5
시스템에 적합한 값은 사용 가능한 RAM 용량과 디스크 속도에 따라 달라집니다. 극단적인 상황에서는 위에서 언급한 더러운 배급량이 여전히 클 수 있습니다. 예를 들어 여유 RAM이 100GiB이고 디스크 쓰기 속도가 약 100MiB인 경우 위 설정으로 인해 최대 더티 캐시는 5GiB가 되며 쓰는 데 약 50초가 걸릴 수 있습니다. 을 사용하면 dirty_bytes캐시 dirty_background_bytes된 값을 절대적으로 설정할 수도 있습니다.
시도해 볼 수 있는 또 다른 방법은 io 스케줄러를 전환하는 것입니다. 현재 커널 버전에는 noop, Deadline, cfq가 있습니다. 이전 커널을 사용하는 경우 cfq에 비해 데드라인 스케줄러에서 더 나은 반응 시간을 경험할 수 있습니다. 그러나 테스트해야 합니다. 귀하의 경우에는 Noop을 피해야 합니다. CFQ에 비해 대기 시간을 줄인다고 주장하는 비메인라인 BFQ 스케줄러도 있습니다(http://algo.ing.unimo.it/people/paolo/disk_sched/). 그러나 모든 배포판에 포함되는 것은 아닙니다. 다음을 사용하여 런타임에 스케줄러를 확인하고 전환할 수 있습니다.
cat /sys/block/sdX/queue/scheduler
echo <SCHEDULER_NAME> > /sys/block/sdX/queue/scheduler
첫 번째 명령은 사용 가능한 스케줄러와 정확한 이름에 대한 요약도 제공합니다. 참고: 이 설정은 다시 시작하면 손실됩니다. 일정을 영구적으로 선택하려면 커널 매개변수를 추가하면 됩니다.
elevator=<SCHEDULER_NAME>
상황은 NFS와 비슷하지만 추가적인 문제가 있습니다. 다음 두 가지 버그 보고서는 NFS의 통계 처리 및 대용량 파일 쓰기로 인해 통계가 매우 느려지는 이유에 대한 내부 정보를 제공할 수 있습니다.
https://bugzilla.redhat.com/show_bug.cgi?id=688232 https://bugzilla.redhat.com/show_bug.cgi?id=469848
업데이트: (2017년 8월 14일)
커널 4.10에는 새로운 커널 옵션 CONFIG_BLK_WBT과 해당 하위 옵션이 도입되었습니다. 커널이 크기와 우선순위를 제어할 수 없는 하드웨어 버퍼로 인한 버퍼 팽창을 방지합니다.BLK_WBT_SQCONFIG_BLK_WBT_MQ
Enabling this option enables the block layer to throttle buffered
background writeback from the VM, making it more smooth and having
less impact on foreground operations. The throttling is done
dynamically on an algorithm loosely based on CoDel, factoring in
the realtime performance of the disk
또한 BFQ-Scheduler는 커널 4.12를 기반으로 합니다.