☰

쓰기 저장 캐시("더티")는 dirty_Background_ratio보다 훨씬 작은 것으로 제한되는 것 같습니다. 그 한계는 무엇입니까? 이 한도는 어떻게 계산되나요?

tag-icon • tag-icon linux linux-kernel cache sysctl atop
쓰기 저장 캐시("더티")는 dirty_Background_ratio보다 훨씬 작은 것으로 제한되는 것 같습니다. 그 한계는 무엇입니까? 이 한도는 어떻게 계산되나요?

저는 Linux를 테스트해왔습니다 4.18.16-200.fc28.x86_64. 에 따르면 free -h내 시스템의 총 RAM은 7.7G입니다.

sysctl에 대한 기본값이 있습니다 vm.dirty*. dirty_background_ratio10이요, dirty_ratio20이요. 내가 읽은 모든 내용에 따르면 Linux는 RAM의 10%인 0.77G에 도달하면 더티 캐시를 쓰기 시작할 것으로 예상됩니다. 더티 캐시가 RAM의 20%(1.54G)에 도달하면 버퍼링된 write() 호출이 차단되어야 합니다.

나는 달려가서 들판을 dd if=/dev/zero of=~/test bs=1M count=2000바라보았다 . 명령이 실행 중일 때 값은 약 0.5G로 안정화됩니다. 이는 더티 백그라운드 임계값(0.77G)보다 훨씬 적습니다! 어떻게 그래? 내가 무엇을 놓치고 있나요?dirtyatopdddirty

dirty_expire_centisecs3000인데 그럴 이유는 없는 것 같아요. 나는 그것이 한계인지 확인하기 위해 dirty_expire_centisecs100, 10까지 내려가려고 노력했습니다 . 결과는 바뀌지 않았습니다.dirty_writeback_centisecsdirty

나는 원래 이 조사의 일환으로 다음과 같은 관찰 내용을 썼습니다.2013년에 "USB 플래시 드라이브 정지" 문제가 발생한 이유는 무엇입니까? 기존의 "I/O 더티 스로틀링 없음" 코드가 이 문제를 해결하지 못하는 이유는 무엇입니까?

내가 아는 한, 두 임계값(15% = 1.155G) 사이의 중간에서 write() 호출이 곡선에서 조절(지연)되기 시작합니다. 그러나 이 제한 이하에서는 대기 시간이 증가하지 않습니다. 더티 페이지를 생성하는 프로세스는 "자유롭게 실행"될 수 있습니다.

내가 이해한 바로는 이 제한의 목적은 더티 캐시를 15% 이상으로 유지하고 20% 하드 제한에 도달하는 것을 방지하는 것입니다. 모든 상황에서 보증을 제공하는 것은 아닙니다. 그러나 나는 dd명령을 사용하여 간단한 사례를 테스트하고 있습니다. 장치에서 구현하는 쓰기 속도와 일치하도록 write() 호출 속도를 제한해야 한다고 생각합니다.

(복잡한 예외가 있기 때문에 간단한 보장은 없습니다. 예를 들어 제한 코드는 지연을 최대 200밀리초로 제한합니다. 그러나 프로세스의 목표 속도 제한이 초당 1페이지 미만인 경우에는 그렇지 않습니다. 경우에는 엄격한 속도 제한이 적용됩니다.)

  • 문서/sysctl/vm.txt-- 리눅스 v4.18
  • I/O 더티 스로틀링 없음-- 2011 LWN.net.

  • (더티_배경_비율 + 더티_비율)/2 총 더티 데이터는... 프로세스 제한을 시작할 때 더티 데이터의 양입니다.제인 카라, 2013

  • 사용자는 전역(백그라운드 + 더티)/2=15% 임계값이 초과되면 애플리케이션이 제한되고 약 17.5%의 균형을 유지한다는 것을 알 수 있습니다. 패치 이전에는 더티 메모리를 20%로 제한하는 것이 동작이었습니다.

    --143dfe8611a6 커밋,"다시 쓰기: IO 없이 Balance_dirty_pages()"

  • 기본적으로 메모리 관리 하위 시스템은 더티 페이지를 시스템 메모리의 최대 15%로 제한하려고 시도합니다. 필요한 경우 페이지가 더러워지는 속도와 페이지를 정리할 수 있는 속도에 맞춰 많은 수의 페이지를 더티화하는 프로세스를 제한하는 Balance_dirty_pages()라는 "마법 함수"가 있습니다. "——다시 쓰기 그룹 및 제어 그룹, 2015 LWN.net.

  • 균형잡힌 페이지()리눅스 4.18.16.

답변1

보고 있다문서/sysctl/vm.txt:

더러운 요금

다음과 같은 내용이 포함되어 있습니다.사용 가능한 페이지 및 회수 가능한 페이지를 포함한 총 사용 가능한 메모리 비율, 디스크를 생성하는 프로세스가 자체적으로 더티 데이터를 쓰기 시작하는 페이지 수입니다.

사용 가능한 총 메모리가 총 시스템 메모리와 같지 않습니다..

사용 가능한 메모리는 다음과 같이 계산됩니다.글로벌더티메모리(). 이는 사용 가능한 메모리 양에 페이지 캐시를 더한 것과 같습니다. 교환 가능한 페이지(예: 익명 메모리 할당, 파일로 지원되지 않는 메모리)는 포함되지 않습니다.

이 동작은 다음에 적용됩니다.리눅스 3.14(2014). 이 변경 이전에는 교체 가능한 페이지가 global_dirtyable_memory() 총계에 포함되었습니다.

명령 실행 시 통계의 예 dd:

$ while true; do grep -E '^(Dirty:|Writeback:|MemFree:|Cached:)' /proc/meminfo | tr '\n' ' '; echo; sleep 1; done
MemFree:         1793676 kB Cached:          1280812 kB Dirty:                 4 kB Writeback:             0 kB
MemFree:         1240728 kB Cached:          1826644 kB Dirty:            386128 kB Writeback:         67608 kB
MemFree:         1079700 kB Cached:          1983696 kB Dirty:            319812 kB Writeback:        143536 kB
MemFree:          937772 kB Cached:          2121424 kB Dirty:            312048 kB Writeback:        112520 kB
MemFree:          755776 kB Cached:          2298276 kB Dirty:            389828 kB Writeback:         68408 kB
...
MemFree:          136376 kB Cached:          2984308 kB Dirty:            485332 kB Writeback:         51300 kB
MemFree:          101340 kB Cached:          3028996 kB Dirty:            450176 kB Writeback:        119348 kB
MemFree:          122304 kB Cached:          3021836 kB Dirty:            552620 kB Writeback:          8484 kB
MemFree:          101016 kB Cached:          3053628 kB Dirty:            501128 kB Writeback:         61028 kB

마지막 행에는 약 3,150,000kB의 "사용 가능한" 메모리가 표시되며 총 562,000kB의 데이터가 다시 기록되거나 다시 기록되기를 기다리고 있습니다. 17.8%입니다. 비율은 이 수준 주위에서 변동하는 것처럼 보이지만 일반적으로 15%에 더 가깝습니다. 편집하다: 이 수치는 더 가까워 보이지만 이 접근 방식을 신뢰하지 마십시오. 이는 여전히 올바른 계산이 아니며 매우 잘못된 결과를 가져올 수 있습니다. 후속 조치 보기여기.

나는 이것이 매우 어렵다고 생각합니다.

나는 다음이 있다는 것을 알아차렸다.Balance_dirty_pages()의 추적 지점, "조절 알고리즘의 역학 분석"에 사용될 수 있습니다. 그래서 나는 다음을 사용했습니다 perf:

$ sudo perf list '*balance_dirty_pages'

List of pre-defined events (to be used in -e):

  writeback:balance_dirty_pages                      [Tracepoint event]
...
$ sudo perf record -e writeback:balance_dirty_pages dd if=/dev/zero of=~/test bs=1M count=2000
$ sudo perf script

표시된 내용 dirty(4096바이트 페이지로 측정)은 예상보다 낮았습니다 setpoint. 코드를 추적했는데 이는 ... freerun로 설정된 추적점 정의에 유사한 낮은 값이 있어야 함을 의미합니다 .(thresh + bg_thresh) / 2global_dirtyable_memory()

관련 정보