Em uma pergunta e resposta anterior, mostrei um experimento sobre dirty_ratio.
Writeback cache ('dirty') parece estar limitado a menos que dirty_background_ratio. O que está sendo limitado por? Como este limite é calculado?
Pensei ter resolvido a questão, corrigindo minha compreensão do cálculo do índice de sujeira. Mas eu repeti o experimento agora, e o cache write-back foi limitado a menos do que eu vi antes. Eu não posso resolver isso, o que poderia estar limitando isso?
Eu tenho valores padrão para os vm.dirty* sysctl. dirty_background_ratio é 10 e dirty_ratio é 20. As "proporções" referem-se ao tamanho do cache de devolução de páginas, também conhecido como cache write-back, como uma porcentagem de MemFree + Cached . Eles são não uma porcentagem de MemTotal - isso foi o que me confundiu na pergunta acima.
Essas proporções significam que atingir 10% faz com que o writeback de plano de fundo seja iniciado e 20% seja o tamanho máximo do cache de write-back. Além disso, eu entendo que o cache de write-back é limitado por "estrangulamento sujo sem I / O". Quando o cache de write-back se eleva acima de 15%, os processos que geram páginas sujas, por ex. com write () são "estrangulados". Ou seja, o kernel faz com que o processo durma dentro da chamada write (). Assim, o kernel pode controlar o tamanho do cache de write-back, controlando o tamanho dos sleeps. Para referências, veja a resposta à minha pergunta anterior.
Mas minha "proporção" observada parece permanecer nitidamente abaixo do limite de estrangulamento de 15%. Deve haver algum fator que estou perdendo! Por que isso está acontecendo?
No meu teste anterior, vi valores em torno de 15-17,5%.
Meu kernel é Linux 4.18.16-200.fc28.x86_64 .
O teste é o seguinte: Eu corri dd if=/dev/zero of=~/test bs=1M status=progress . E, ao mesmo tempo, monitorei a taxa de sujeira alcançada. Eu interrompi o comando dd depois de 15GB.
$ while true; do grep -E '^(Dirty:|Writeback:|MemFree:|Cached:)' /proc/meminfo | tr '\n' ' '; echo; sleep 1; done
...
MemFree: 139852 kB Cached: 3443460 kB Dirty: 300240 kB Writeback: 135280 kB
MemFree: 145932 kB Cached: 3437220 kB Dirty: 319588 kB Writeback: 112080 kB
MemFree: 134324 kB Cached: 3448776 kB Dirty: 237612 kB Writeback: 160528 kB
MemFree: 134012 kB Cached: 3449004 kB Dirty: 169064 kB Writeback: 143256 kB
MemFree: 133760 kB Cached: 3449024 kB Dirty: 105484 kB Writeback: 119968 kB
MemFree: 133584 kB Cached: 3449032 kB Dirty: 49068 kB Writeback: 104412 kB
MemFree: 134712 kB Cached: 3449116 kB Dirty: 80 kB Writeback: 78740 kB
MemFree: 135448 kB Cached: 3449116 kB Dirty: 8 kB Writeback: 0 kB
Por exemplo, a primeira linha na saída citada:
avail = 139852 + 3443460 = 3583312
dirty = 300240 + 135280 = 435520
ratio = 435520 / 3583312 = 0.122...
Eu encontrei uma coisa que estava limitando, mas não o suficiente para ver esses resultados. Eu estava experimentando com a configuração de /sys/class/bdi/*max_ratio . Os resultados do teste na questão são da execução com max_ratio = 1.
Repetindo o teste acima com max_ratio = 100 , posso conseguir uma maior razão de sujidade, e. 0,142:
MemFree: 122936 kB Cached: 3012244 kB Dirty: 333224 kB Writeback: 13532 kB
O teste de gravação precisa ser bastante longo para observar isso de forma confiável, por ex. 8GB. Esse teste leva cerca de 100 segundos. Estou usando um disco rígido giratório.
Eu tentei testar com 4 GB e só vi uma taxa suja de 0,129:
MemFree: 118388 kB Cached: 2982720 kB Dirty: 249020 kB Writeback: 151556 kB
Como eu digo, isso me surpreende. Eu tenho uma fonte especializada em 2013 , dizendo que dd deveria ter "livre executar "para gerar páginas sujas até que o sistema atinja uma taxa suja de 0,15. É explicitamente falando sobre max_ratio .