Este é um acompanhamento para:Gravações em rede de alta velocidade com grande capacidade de armazenamento. A configuração mudou notavelmente.
Eu tenho um pool com um único raid-z2com 6 unidades, todas unidades Exos X18 CMR. Usando fiotestes manuais, sei que o array pode sustentar em média cerca de 800 MB/s de gravações sequenciais, o que é bom e está alinhado com o desempenho esperado deste array. A máquina é um Ryzen5 Pro 2400 GE (4C/8T, aumento de 3,8 GHz) com 32G ECC RAM, unidade de inicialização/sistema NVMe e portas Ethernet de 2x10 Gbps (Intel x550-T2). Estou executando um sistema Arch atualizado com zfs 2.1.2-1.
Meu caso de uso é um arquivo de vídeo em sua maioria grande (~ 30G), gravação uma vez, leitura uma vez, vídeo compactado. Eu desabilitei atime, configurei recordsize=1M, configurei compressios=offe dedup=offcomo os dados são realmente incompressíveis e os testes mostraram um desempenho pior do compression=lz4que offo que a Internet disse e não há dados duplicados por design. Este pool é compartilhado na rede via Samba. Ajustei minha rede e o Samba ao ponto em que a transferência de NVMe NTFS em uma máquina Windows para NVMe ext4 atinge 1 GB/s, ou seja, razoavelmente perto de saturar o link de 10 Gbps com Jumbo Frames de 9K.
É aqui que me deparo com problemas. Quero ser capaz de transferir um arquivo de vídeo 30G inteiro a 1 GB/s para o raid-z2array que suporta apenas gravação sequencial de 800 MB/s. Meu plano é usar as páginas sujas baseadas em RAM para absorver as repercussões e deixá-las fluir para o disco após a transferência ser "concluída" no lado do cliente. Achei que tudo que eu precisaria seria (1024-800)*30~=7Gde páginas sujas na RAM que pudessem ser liberadas para o disco em aproximadamente 10 segundos após a conclusão da transferência. Entendo as implicações disso para a integridade dos dados e o risco é aceitável, pois sempre posso transferir o arquivo novamente mais tarde por até um mês, caso uma queda de energia faça com que o arquivo seja perdido ou incompleto.
No entanto, não consigo fazer com que o ZFS se comporte da maneira que espero... Editei meu /etc/modprobe.d/zfs.confarquivo assim:
options zfs zfs_dirty_data_max_max=25769803776
options zfs zfs_dirty_data_max_max_percent=50
options zfs zfs_dirty_data_max=25769803776
options zfs zfs_dirty_data_max_percent=50
options zfs zfs_delay_min_dirty_percent=80
Executei o mkinitcpio -Pcomando apropriado para atualizar meu initramfs e confirmei que as configurações foram aplicadas após uma reinicialização:
# arc_summary | grep dirty_data
zfs_dirty_data_max 25769803776
zfs_dirty_data_max_max 25769803776
zfs_dirty_data_max_max_percent 50
zfs_dirty_data_max_percent 50
zfs_dirty_data_sync_percent 20
Ou seja, defino o máximo de páginas sujas para 24G, que é muito mais do que os 7G que preciso, e espero para começar a atrasar as gravações até que 80% disso seja usado. Pelo que entendi, o pool deve ser capaz de absorver 19G na RAM antes de começar a atrasar as gravações do cliente (Samba) com latência.
No entanto, o que observo ao escrever no cliente Windows é que, após cerca de 16 segundos a uma velocidade de gravação de aproximadamente 1 GB/s, o desempenho de gravação cai de um penhasco ( iostatainda mostra os discos trabalhando duro para liberar os dados), o que só posso assumir ser o retrocesso mecanismo para limitação de gravação do ZFS. No entanto, isso não faz sentido, pelo menos mesmo que nada tenha sido liberado durante os 16 segundos, deveria ter sido ativado 3 segundos depois. Além disso, cai novamente no final, veja a imagem: [ 
][https://i.stack.imgur.com/Yd9WH.png]
Eu tentei ajustar para zfs_dirty_data_sync_percentcomeçar a escrever mais cedo porque o buffer de página suja é muito maior que o padrão e também tentei ajustar o dimensionamento io ativo para zfs_vdev_async_write_active_{min,max}_dirty_percententrar em ação mais cedo também para acelerar as gravações mais rapidamente com o grande buffer sujo. Ambos apenas mudaram ligeiramente a posição do penhasco, mas não perto do que eu esperava.
Questões:
- Eu entendi mal como funciona o atraso da limitação de gravação?
- O que estou tentando fazer é possível?
- Se sim, o que estou fazendo de errado?
Sim, eu sei, estou literalmente perseguindo alguns segundos e nunca recuperarei o esforço despendido para conseguir isso. Tudo bem, é pessoal entre mim e o ZFS neste momento, e uma questão de princípio;)
Responder1
Você também precisa aumentar zfs_txg_timeouto parâmetro de seu padrão atual de 5 segundos para algo como 7G/0,2G/s = 35s, portanto, definir para 40s deve ser suficiente.
Na tua /etc/modprobe.d/zfs.conf:
options zfs zfs_txg_timeout=40
Observe que o ARC é exatamente isso, um cache de "leitura" com zero envolvimento no cache de gravação, portanto, certifique-se de que seu ARC não esteja configurado para consumir os 7G+ extras de dados que seu cache de gravação em bloco deve absorver por fluxo de gravação de 30 GB. O cache de gravação para ZFS é como qualquer outro cache de gravação de bloco simples (como o commitparâmetro para sistemas de arquivos ext4), portanto, teste em não produção para garantir que não haja falta de RAM durante todos os cenários de transferência.
Responder2
Cada gravação atualizará o ARC se zfs Primarycache = all (padrão). Se a latência de leitura não for importante para os dados que você está gravando no momento, sugiro definir zfs primáriocache=meta.
Responder3
No momento, você não tem RAM ou recursos de armazenamento suficientes para o que procura.
Projete em torno dos níveis de transferência de E/S desejados e do pior desempenho possível.
Se você precisar de uma taxa de transferência de 1 GB/s sob todas as condições para o conjunto de dados de trabalho que está sendo descrito, certifique-se de que a contagem do eixo do disco ou a taxa de transferência da interface sejam capazes de suportar isso.