Por que meu pool do ZFS está gastando 97% de seu tempo lendo o destino e apenas 3% escrevendo, em uma operação de gravação?
Isso me deixa perplexo e não sei como detalhar o que o ZFS está realmente fazendo.
Estou usando uma instalação limpa do FreeNAS 11.1 com um pool ZFS rápido (espelhos importados em fast 7200s), além de um SSD UFS solitário para testes. Config é praticamente "fora da caixa".
O SSD contém 4 arquivos de tamanhos de 16 a 120 GB, copiados usando o console para o pool. A piscina é deduped (vale a pena: 4x poupança, tamanho 12TB no disco) e o sistema tem muita RAM (128GB ECC) e rápido Xeon. A memória é bastante adequada - zdb mostra que o conjunto tem um total de 121M blocos (544 bytes cada no disco, 175 bytes cada na RAM), portanto, o DDT inteiro é de apenas 20,3 GB (cerca de 1,7 GB por TB de dados). / p>
Mas quando copio os arquivos para o pool, vejo isso em zpool iostat :
Estáfazendoumciclodeatéumminutodeleiturasdebaixoníveleumabrevesequênciadegravações.Apartelidaémostradanafoto.Avelocidadegeraldegravaçãoparaatarefatambémnãoégrande-oconjuntoé45%/10TBvazioenativamentepodegravaremtornode300-500MB/s.
Semsabercomoverificar,minhasuspeitaéqueasleiturasdebaixonívelsãodaleituradoDDTeoutrosmetadados,poiselesnãosãopré-carregadosnoARC(ousãocontinuamenteenviadosdoARCpordadosdearquivosendogravados).Talvez.
Talvezseuachadodedesduplicaçãoaconteça,entãonãohámuitaescrita,sóquenãomelembrodenenhumaversãodupdessesarquivosefazomesmode/dev/random,peloquemelembromelhor(vouverificarissoeatualizarEmbreve).Talvez.Nenhumaideiareal.
Oquepossofazerparadescobriroqueestáacontecendocommaisexatidão,comoobjetivodeotimizá-lo?
AtualizaçãonaRAMededup:
AtualizeioQparamostrarotamanhodoDDTapósocomentárioinicial.ARAMDedupéfrequentementecitadacomo5GBporTBx4,masissoébaseadoemumexemploquenãoémuitoadequadoparadedup.Vocêtemquecalcularacontagemdeblocosmultiplicadaporbytesporentrada.O"x4" frequentemente citado é apenas um limite padrão "soft" (por padrão, o ZFS limita os metadados a 25% do ARC, a menos que seja solicitado a usar mais - esse sistema é especificado para dedup e eu adicionei 64GB que é all utilizável para acelerar o cache de metadados).
Portanto, neste pool, zdb confirma que o DDT inteiro precisa apenas de 1,7 GB por TB e não 5 GB por TB (20G no total), e estou feliz em fornecer metadados de 70% do ARC não 25% (80G de 123G ).
Nesse tamanho, não será necessário ejetar qualquer coisa além do conteúdo de arquivo 'morto' do ARC. Então, eu estou tentando realmente investigar o ZFS para encontrar o que ele pensa que está acontecendo, e assim posso ver o efeito de qualquer alteração que eu faça, porque estou realmente muito surpreso com sua enorme quantidade de "baixos níveis de leitura", e procurando uma maneira de investigar e confirmar a realidade do que ela pensa que está fazendo.