Instalei recentemente um novo disco e criei um zpool nele:
Depois de usá-lo por um tempo, notei que era bastante lento:
Este teste é bastante semelhante ao meu caso de uso real. Estou lendo um número moderado (~ 10k) de imagens (~ 2 MiB cada) do disco. Eles foram gravados de uma só vez quando o disco estava praticamente vazio, portanto, não espero que estejam fragmentados.
Para comparação, testei o ext4:
E btrfs:
O que pode estar causando problemas de desempenho no ZFS e como posso torná-lo mais rápido?
Falha na tentativa de solução
Também tentei definir explicitamente o tamanho do setor para o zpool, pois meu disco ( Seagate ST1000DM003 ) usa setores físicos de 4096 bytes:
Isso não melhorou o desempenho:
Estranhamente, o uso de um zvol teve um ótimo desempenho:
Por que isso afeta apenas os sistemas de arquivos ZFS e não os zvols?
Teste estendido para btrfs
Nos comentários, foi sugerido que a diferença pode ser devido ao cache. Após mais testes, não acredito que seja esse o caso. Aumentei o tamanho do teste btrfs bem acima da quantidade de memória que meu computador possui e seu desempenho ainda era significativamente maior que o do ZFS:
Arch Linux, versão do kernel 4.11.6
ZFS no Linux 0.6.5.10
Unidade sendo testada: Seagate ST1000DM003 , conectado à porta SATA de 6 Gb / s
Placa-mãe: Gigabyte X99-SLI
Memória: 8 GiB
Informações do ZFS
Aqui está como eram as propriedades do ZFS antes de executar o fio. Estes são apenas o resultado da criação de um zpool com as configurações padrão.
Não há detalhes como o hardware em uso, sistema operacional e versão, controlador, configurações do sistema etc. Não sei ao certo o que podemos lhe dizer!
Qual é o drive em si? É uma unidade SATA de consumo pronta para uso. Você tem um longo caminho a percorrer para provar que ele realmente pode lidar com mais de 200 MB / s sustentados. A maioria das unidades SATA de nível de consumidor em condições reais terá a sorte de obter mais de 70-80 operações de E / S por segundo, ou mais do que cerca de 100-120 MB / s. E se você fizer operações aleatórias de E / S de blocos pequenos em uma unidade como essa, provavelmente obterá algo como 30-40 KB / s. 10 GB podem facilmente ficar no cache.
— Andrew Henle 29/06
@ewwhite Não há configurações de ajuste estão presentes em/etc/modprobe.d/zfs.conf
@whwhite Eles são. Limpei a tabela de partição entre cada teste. Em todos os casos, a partição teve um deslocamento de 1 MiB desde o início do disco.
Observe para si mesmo / qualquer pessoa que tropeça nessa questão: as configurações de ajuste mencionadas pelo ewwhite estão documentadas man 5 zfs-module-parameters.
Enquanto velho, sinto que esta pergunta merece uma resposta.
fioemite, por padrão, IOPs do tamanho de 4KB; Os conjuntos de dados do ZFS, em vez disso, usam 128 KB de gravação por padrão. Essa incompatibilidade significa que cada gravação em 4K causa uma leitura / modificação / gravação de todo o registro de 128K.
Os ZVOLs, por outro lado, usam tamanho de bloco de 8K por padrão. Isso significa que uma gravação em 4K causa um ciclo de leitura / modificação / gravação muito menor de um registro de 8K e, com alguma sorte, duas gravações em 4K podem ser combinadas em uma única gravação de 8K (que não requer leitura / modificação / gravação).
O zfs set recordize=8K <dataset>tamanho do registro do conjunto de dados do ZFS pode ser alterado e, nesse caso, deve fornecer um desempenho mais ou menos equivalente aos ZVOLs. No entanto, quando usado para transferências relativamente grandes (o OP falou sobre arquivos de 2 MB que, sendo imagens, devem ser lidos inteiramente toda vez que forem acessados), é melhor ter um tamanho de registro / volume grande , às vezes até maior que a configuração padrão (128K).
Nota: como o trabalho do fio não possui direct=1( http://fio.readthedocs.io/en/latest/fio_doc.html#cmdoption-arg-direct ), uma certa quantidade de E / S que está sendo executada (leitura e gravação) pode ser armazenada em cache pelo sistema operacional, distorcendo seus resultados (e aumentando os números artificialmente). Isso por si só é ainda mais complicado pelo seguinte:
O ZFS no Linux não suporta O_DIRECT(portanto, a abertura falha) ou, se o fizer, faz isso silenciosamente voltando à E / S em buffer (consulte o ponto 3 de https://github.com/zfsonlinux/zfs/commit / a584ef26053065f486d46a7335bea222cb03eeea ).
Em alguns casos, o BTRFS e o ext4 O_DIRECTretornam à E / S em buffer.
Esteja ciente de que O_DIRECTainda é permitido fazer E / S em buffer porque no Linux O_DIRECTé mais uma dica (consulte a seção de referências em /programming//a/46377629/2732969 ).
Se você estiver em uma situação em que não pode ignorar corretamente os caches, é crucial que você faça E / S suficientes em uma área grande o suficiente para minimizar o impacto do cache (a menos, é claro, que você realmente queira testar o cache) ...