장치당 dirty_ratio

장치당 dirty_ratio

Q: 더 많은 쓰기 캐시를 얻기 위해 빠른 장치를 "화이트리스트"로 만드는 방법이 있습니까? 아니면 느린 장치(또는 //cifs/paths와 같은 원격 "장치")가 쓰기 캐시를 덜 사용하도록 하시겠습니까?

이를 달성하기 위한 설정이 있지만 원하는 대로 작동하지 않습니다. bdi다음의 ("지원 장치") 개체를 참조하세요 sysfs.

linux-4.18/documentation/ABI/test/sysfs-class-bdi

최소 비율(읽고 쓰기)

일반적인 상황에서 각 장치는 다른 장치에 비해 현재 평균 쓰기 속도를 기준으로 총 후기입 캐시의 일부를 가져옵니다.

"min_ratio" 매개변수를 사용하면 후기입 캐시의 최소 비율을 특정 장치에 할당할 수 있습니다. 이는 예를 들어 최소 QoS를 제공하는 데 유용합니다.

최대 비율(읽고 쓰기)

특정 장치가 후기입 캐시의 지정된 비율 이상을 사용하지 않도록 제한할 수 있습니다. 이는 하나의 장치가 후기입 캐시의 전부 또는 대부분을 차지하는 것을 방지하려는 상황에서 유용합니다. 예를 들어 NFS 마운트가 쉽게 멈추는 경우입니다.

문제는 "이 설정은 총 더티 데이터가 (더티_배경_비율+더티_비율)/2개보다 많은 경우에만 적용됩니다. 이는 프로세스 제한을 시작할 때 더티 데이터의 양이기 때문입니다. 따라서 원하는 장치 제한은 다음과 같습니다. 현재 쓰기 이 제한이 큰 영향을 미치지 않는 유일한 쓰기를 입력하십시오." 추가 읽기:

• Jan Kara의 LKML 게시물(2013).
• 이 답변 끝에 "테스트 케이스"가 있습니다.
• 5fce25a9df48 제출v2.6.24에서. "시스템에 공간이 많으면 bdi 제한을 위반하는 것을 허용합니다. 전체 제한의 절반에 도달하면 bdi 제한을 적용하기 시작합니다..." 이것은 내부 공간을 추가하는 동일한 커널 버전의 일부입니다. -장치 "한계" . 따라서 "제한 사항"은 사전 릴리스 v2.6.24-rc1 및 -rc2를 제외하고 항상 이와 같이 작동합니다.

단순화를 위해 30% 설정을 무시하고 기본값: dirty_Background_ratio=10 및 dirty_ratio=20을 가정하겠습니다. 이 경우 프로세스는 시스템 전체가 15% 지점에 도달할 때까지 지연 없이 페이지를 더티할 수 있습니다.

Q: 이 상황은 재현 가능합니다. 설정을 통해 dirty_ratio = 1문제가 완전히 해결되었습니다.

:-/

이는 LWN.net에서 작성한 기사에 언급된 "유해한 USB 스틱 정지 문제"와 유사하게 들립니다. 안타깝게도 이 글은오해의 소지가 있는. 너무 혼란스러워서 보고된 것과 다른 문제를 만들어냈습니다.

한 가지 가능성은 보다 구체적인 결함을 재현하고 있다는 것입니다. 커널 개발자에게 보고하면 분석하고 해결책을 찾을 수도 있습니다. 사람들과 교류하는 것을 좋아합니다.투명 페이지예전에는해결됨. 문제를 재현하려면 업스트림 커널을 사용해야 합니다. 또는 유료 지원 담당자에게 문의하세요 :).

그렇지 않으면 패치를 적용하여 내부 strictlimit설정을 노출할 수 있습니다. 이것은 당신을 max_ratio엄격한 한계에 빠뜨립니다. 해당 패치는 아직 메인라인에 적용되지 않았습니다. 충분한 수의 사람들이 이에 대한 필요성을 보이면 패치가 적용될 수도 있고, 패치의 필요성을 제거하기 위한 일부 작업이 권장될 수도 있습니다.

제가 걱정하는 점은 이 기능이 작동할 수도 있지만 작동하지 않을 수도 있다는 것입니다.충분히포함을 정당화하는 데 도움이 됩니다. 따라서 우리는 결국 다른 방법을 통해 이러한 문제를 해결할 것이며, 이 더 이상 사용되지 않는 레거시 기능을 계속해서 유지할 것입니다.

나는 이것이 훌륭하고 완전하며 "충분히 큰" 문제 세트를 해결하기에 충분하다는 것을 누군가가 보여줄 수 없다면 패치 [1]을 통과할 것이라고 생각합니다. 사람들은 어떻게 생각하나요?

[1] 실제로 -mm에 넣어서 유지 관리할 것이므로 다음에 누군가 문제를 보고하면 "야, 이거 해봐"라고 말할 수 있습니다.

--앤드류 모튼, 2013

mm-add-strictlimit-knob-v2.patch여전히 -mm에 앉아 있습니다. 사람들은 더티 캐시의 자동 조정을 개선하는 아이디어를 몇 번 언급했습니다. 하지만 저는 아직 이 분야에서 많은 일자리를 찾지 못했습니다. 매력적인 제안은 장치당 5초의 후기입 캐시를 유지하는 것입니다. 그러나 예를 들어 IO 패턴이 무작위인지 순차적인지에 따라 장치의 속도가 갑자기 바뀔 수 있습니다.

분석(그러나 결론은 없음)

Q: 커널이 초고속 로컬 SSD 드라이브를 처리하는 것과 똑같은 방식으로 느린 원격 CIFS 장치에 대한 플러시 페이지를 처리한다는 사실에 놀랐습니다.

이러한 치료법은 동일하지 않습니다. 위의 BDI 문서에 대한 참조를 참조하세요. "각 장치에는 현재 평균 쓰기 속도를 기준으로 전체 쓰기 캐시의 일부가 할당됩니다."

그러나 이로 인해 느린 장치가 기록되는 유일한 장치인 경우 전체 쓰기 저장 캐시를 15~20% 표시 사이로 채울 수 있습니다.

쓰기 시작하려는 장치의 최대 쓰기 저장 캐시가 허용된 공유보다 작은 경우 "더티 제한" 코드를 약간 조정해야 합니다. 이를 통해 남은 공간 중 일부를 사용할 수 있으며 느린 장치가 공간을 확보할 때까지 기다릴 필요가 없습니다.

문서에서는 NFS 서버를 사용할 수 없게 되는 경우 지연을 포함하여 장치 속도가 예측할 수 없게 변경되는 경우 min_ratio 및 max_ratio 설정을 추가할 것을 권장합니다.

문제는 더티 스로틀링이 느린 장치를 제어하지 못하고 20% 하드 제한을 채우거나 그에 가까워지는 경우입니다.

우리가 관심을 갖고 있는 더티 조절 코드는 v3.2에서 재작업되었습니다. 소개는 LWN.net 기사 “IO 더티 스로틀링 없음". 또한 출시 후 Fengguang Wu는 LinuxCon Japan에서 연설했습니다. 그의프레젠테이션 슬라이드매우 상세하고 유익합니다.

목표는 더 나은 IO 패턴을 허용하기 위해 BDI에 대한 모든 쓰기를 전용 스레드에 다시 위임하는 것입니다. 그러나 덜 직접적인 제한 시스템으로 전환해야 했습니다. 기껏해야 코드를 추론하기가 더 어려워집니다. 잘 테스트되었지만 가능한 모든 작동 메커니즘을 다루고 있는지는 확실하지 않습니다.

실제로 v4.18을 보면명시적인 대체 코드문제의 더 극단적인 버전의 경우: BDI가 다음과 같은 경우완전히반응이 없습니다. 다른 BDI가 계속해서 발전할 수 있도록 노력하지만... 사용할 수 있는 쓰기 저장 캐시의 양이 더 제한됩니다. 작성기가 하나만 있어도 성능이 저하될 수 있습니다.

질문: 메모리 부족으로 인해 시스템은 대부분의 읽기 캐시를 회수할 때 더티(쓰기) 캐시를 플러시하고 회수하려고 고집스럽게 시도합니다. 따라서 상황은 엄청난 로컬 디스크 I/O 완료 시간과 결합된 거대한 CPU iowait, 논스톱 대기 중인 D의 많은 프로세스, 완전히 응답하지 않는 시스템입니다. 시스템이 여유 메모리를 해제하지 않기 때문에 OOM 킬러가 시작되지 않습니다. (CIFS에는 플러시를 매우 느리게 만드는 버그도 있는 것 같습니다. 하지만 여기서는 신경 쓰지 마세요.)

시스템이 메모리 부족에 직면해 있다고 말씀하셨습니다. 이것은 매우 어려운 사례의 예입니다. "사용 가능한" 메모리가 떨어지면 후기입 캐시의 크기에 부담을 줄 수 있습니다. "dirty_ratio"는 실제로 "사용 가능한" 메모리의 백분율입니다.이는 여유 메모리 + 페이지 캐시를 의미합니다..

이는 원작에서도 나타났습니다. 시도가 있다쉬움그것. "새로운 더티 제한은 빛 기관의 제한을 피할 수는 없지만 수면 시간을 200밀리초로 제한할 수 있습니다."라고 명시되어 있습니다.

"max_ratio"에 대한 테스트 케이스

VM/노트북/무엇이든 설정하면 작동합니다.아니요값비싼 RAM을 보유하고 있습니다. dd if=/dev/zero bs=1M of=~/testWatch Write Cache를 실행 하고 사용합니다 grep -E '^(Dirty:|Writeback:)' /proc/meminfo. 더티+쓰기 저장이 "설정 지점" 주위에 정착되는 것을 볼 수 있습니다.

설정점은 17.5%(15%~20%)입니다. Linux v4.18의 결과는 다음과 같습니다.여기. 정확한 비율을 보려면 비율이 다음과 같습니다.아니요총 RAM의 백분율;i제안dirty_balance_pages()에서 추적점을 사용합니다.

max_ratio파일 시스템 BDI에서 다른 값을 사용하여 이 테스트를 실행했습니다. 예상대로 쓰기 저장 캐시를 15% 미만으로 제한하는 것은 불가능합니다.

각 장치의 더티 비율을 다음과 같이 설정할 수 있다고 생각합니다.

echo RATIO > /sys/class/bdi/MAJOR:MINOR/max_ratio

dirty_ratio실험을 해보니 "팩"의 균형이 꽤 잘 맞는다는 것을 알았습니다 . 페이지를 더럽히는 과정에는 일종의 제한이 따릅니다. 하나의 cp프로세스는 가능한 거의 모든 쓰기 캐시를 쉽게 차지할 수 있지만 10번의 경쟁 프로세스를 실행하더라도 쓰기 캐시 제한(dirty_ratio)에 거의 도달하지 않습니다.

그러므로 나는 모든 문제를 내가 언급한 CIFS 관련 버그에 있다고 생각합니다. 더 많은 프로세스가 빠른 로컬 디스크에 쓰려는 경우 커널은 CIFS 사용량을 줄입니다. 여기서는 더 많은 프로세스가 메모리만 사용하려고 하며 위의 버그로 인해 커널이 대규모 CIFS 쓰기 캐시를 플러시하고 회수할 수 없습니다. 버그가 아니었다면 dirty_ratio 30%는 문제가 되지 않았을 것입니다.