백버퍼 쓰기 저장은 처음부터 끔찍했습니다. 백버퍼 쓰기 저장을 수행할 때 포그라운드 활동에 최소한의 영향을 주어야 합니다. 이것이 백그라운드 활동의 정의입니다... 하지만 리버퍼링 작성자는 제가 기억하는 한 이렇게 행동하지 않았습니다. 예를 들어, 다음과 같이 하면:
$ dd if=/dev/zero of=foo bs=1M count=10k
내 노트북에서 크롬을 실행하려고 하면 기본적으로 버퍼링된 쓰기 저장이 완료될 때까지 실행되지 않습니다.
이제 Linux에 패치를 적용했으며 Fedora Workstation 및 다른 곳에서 사용할 수 있습니다. 응.
그러나 이 "쓰기 저장 제한"(WBT)은 적어도 SATA HDD 및 SSD에는 기본적으로 영향을 미치지 않습니다. 기본 IO 스케줄러 CFQ호환되지 않음WBT와 함께. BFQ(다중 대기열 블록 계층의 CFQ 후속 버전)도 마찬가지입니다. 백그라운드 쓰기 저장 자체를 제한하지 않는 I/O 스케줄러로 전환해야 합니다. 따라서 몇 가지 절충안을 만들어야 합니다 :-(.
CFQ는 과거에도 마찬가지로 매력적으로 들리는 설명을 광고에 포함했을 수 있습니다. BFQ의 경우에도 마찬가지입니다. 하지만 문서에 따르면 CFQ와 유사한 경험적 방법을 사용하는 것으로 보입니다. IO 대기 시간을 측정하고 대기 시간이 너무 높으면 백그라운드 쓰기 저장을 제한하는 것을 볼 수 없습니다.
저는 회전하는 하드 드라이브가 장착된 2년 된 노트북을 가지고 있습니다. 장치의 32개 깊이 I/O 대기열인 SATA NCQ를 완벽하게 지원합니다. 기반으로v3 패치에 대한 표지, 저와 같은 시스템에서는 백그라운드 쓰기 저장이 한 번에 너무 많은 IO를 커밋할 수 있는 이 문제가 발생할 것으로 예상됩니다.
대용량 파일(20G VM 파일. 8GB RAM)을 복사할 때 시스템을 사용할 수 없게 되는 것을 확실히 발견했습니다. 그래도 이게 내가 가진 가장 큰 문제인 것 같아ext4 때문입니다, 또한 부분적으로그놈 쉘 오류.
- WBT가 해결한 문제를 재현하고 이것이 특정 시스템의 문제인지 보여주기 위한 매우 대략적인 수치를 얻으려면 어떤 지침을 따라야 합니까?
- 이 문제는 매우 심각한 것으로 들리며, 적어도 몇 년 동안은 이해되어 왔습니다. 일부 모니터링 시스템이 잠재적인 문제를 표시하는 방법을 알기를 원할 수도 있습니다. 성능 문제가 있고 이것이 가능한 원인 중 하나라고 생각하는 경우 이를 진단하기 위해 어떤 측정값을 볼 수 있습니까?