Mal-entendido sobre Cache de Página e dirty_background_bytes

Question

Eu tenho visto isso por um tempo agora e as coisas não estão alinhadas com minhas expectativas, mas eu não sei se é porque algo está errado, ou se minhas expectativas estão erradas.

Então, eu tenho um sistema com mais de 100GB de RAM, e eu configurei meu dirty_background_bytes para 9663676416 (9GB) e dirty_bytes para 2x que (19327352832 ou 18GB)

Na minha cabeça, isso deve permitir que eu grave até 9 GB em um arquivo, mas na verdade ele fica na memória e não precisa atingir o disco. Meu dirty_expire_centisecs é o padrão de 3000 (30 segundos).

Então, quando eu corro:

# dd if=/dev/zero of=/data/disk_test bs=1M count=2000

e executou:

# while sleep 5; do egrep 'Dirty|Writeback' /proc/meminfo | awk '{print $2;}' | xargs; done

(Imprimindo bytes em kb, Writeback em kb e WritebackTmp em kb em instantâneos de 5s)

Eu esperava vê-lo despejar 2 GB no cache da página, ficar lá por 30 segundos e começar a gravar os dados no disco (já que ele nunca ficou acima da taxa de segundo plano de 9 GB)

Em vez disso, o que vi foi:

3716 0 0
4948 0 0
3536 0 0
1801912 18492 0
558664 31860 0
7244 0 0
8404 0 0

Quando, assim que o cache de páginas pulou, ele já estava gravando os dados, até voltarmos para onde começamos.

O que eu estou realmente trabalhando é basicamente tentando ver se o meu gargalo de processo é disco IO ou algum outro fator, mas no meio eu fiquei confuso com esse comportamento. Eu acho que enquanto o processo ainda está sendo executado no desempenho de gravação em disco da zona de buffer não deve ser relevante, já que ele deveria estar apenas sendo despejado na memória.

Então, eu estou entendendo mal a maneira como esses recursos devem funcionar ou algo estranho está acontecendo?

    

Answer 1

Isso pode ser um efeito colateral do seu comando dd desvinculando e criando um novo disk_test em cada iteração.

Tente primeiro criar um arquivo de destino com um único comando dd if=/dev/zero of=/data/disk_test bs=1M count=2000 e, em seguida, execute seu loop com o comando dd if=/dev/zero of=/data/disk_test bs=1M count=2000 conv=notrunc,nocreat .

Expansão: notrunc faz diferença porque, no passado, alguma heurística foi adicionada para evitar que os aplicativos substituíssem por renomear e substituíssem por truncar e falhassem para corromper seus dados. Essa heurística basicamente força a liberação de dados pertencentes a arquivos truncados abertos > escritos & gt ;.

Na página de manual do mount :

auto_da_alloc|noauto_da_alloc

Many broken applications don't use fsync() when noauto_da_alloc replacing existing files via patterns such as

fd = open("foo.new")/write(fd,..)/close(fd)/ rename("foo.new", "foo")

or worse yet

fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).

If auto_da_alloc is enabled, ext4 will detect the replace-via-rename and replace-via-truncate patterns and force that any delayed allocation blocks are allocated such that at the next journal commit, in the default data=ordered mode, the data blocks of the new file are forced to disk before the rename() operation is commited. This provides roughly the same level of guarantees as ext3, and avoids the "zero-length" problem that can happen when a system crashes before the delayed allocation blocks are forced to disk.

Dê também um saque em FAQ do XFS