Comece por desativar o atime , se ainda não o fez.
Você também pode investigar a configuração primarycache=metadata impact.
Atualização: porque o padrão do registro é 128k, a quantidade de dados lidos pelo programa de teste é muito maior que o ARC em um sistema de 8GB e ainda é ligeiramente maior que o ARC em um sistema de 16GB. Reduzir o registro permite que menos dados sejam lidos e, portanto, ele se encaixa no ARC. Eu estava subestimando o tamanho dos dados que estavam sendo lidos, o efeito do registro e, portanto, tirando algumas conclusões ruins. Até agora, desativar a pré-busca não parece fazer muita diferença nesse caso, embora eu tente todas as opções de gravação com e sem pré-busca ativada.
Esta carga é semelhante a um cenário IMAP / Maildir com muitos diretórios, muitos arquivos e possivelmente apenas pequenas quantidades de dados lidos de cada arquivo.
Eu testei usando o FreeBSD 10 e o Fedora 19 com o zfsonlinux. eu tenho testou vários sistemas de arquivos nativos do linux, como extX / xfs / jfs e até btrfs. No FreeBSD eu testei usando o sistema de arquivos ufs nativo também. Minha carga de trabalho é simplesmente digitalizar uma coleção de música maior usando amarok / winamp / etc. Meu programa de teste é amarok_collectionscanner porque pode ser executado a partir da linha de comando facilmente. O padrão é sempre o mesmo. Uma execução inicial do scanner de coleta leva cerca de 10 minutos, dependendo do sistema de arquivos, mas o ZFS executa similarmente a sistemas de arquivos não-ZFS
Execuções subseqüentes de uma varredura são incrivelmente rápidas usando um não-zfs sistema de arquivos, geralmente em torno de 30 segundos. O ZFS torna apenas marginal melhorias com execuções subseqüentes. Também é óbvio de assistir iostat que, após uma execução inicial em um sistema de arquivos não-ZFS, o SO não toca no disco. Está tudo no cache do sistema de arquivos.
Usar um cache SSD para ZFS aumenta o tempo, mas nunca em qualquer lugar perto de 30 segundos.
Por que o ZFS não armazena essa carga em cache? Uma possibilidade que eu explorei foi que o tamanho do ARC era limitado a menos do que um sistema de arquivos não-ZFS é permitido usar para armazenamento em cache. Eu testei novamente em uma máquina com mais memória disponível para o ARC do que toda a memória disponível no primeiro sistema de teste e os números permaneceram os mesmos.
Espero encontrar / criar uma receita de fio que duplique esse tipo de carga. Basicamente, precisaria criar milhares de arquivos pequenos, digitalizar todos os diretórios procurando os arquivos, abrir cada arquivo e leia uma pequena quantidade de dados de cada um. É como o mundo pior banco de dados! Provavelmente vou testar OpenIndiana em seguida, mas espero os resultados são os mesmos.
O conjunto de dados é de 353 GB e 49.000 arquivos. Os sistemas de teste tinham 8GB-16GB de RAM. A configuração do zpool fez pouca diferença, mas os testes com os quais eu me importo sempre foram apenas um disco inteiro. Eu usei ST3500630AS e WDC WD20EZRX-00D8PB0 entre outras unidades. As unidades quase não faziam diferença. A quantidade de RAM ou a velocidade dos processadores fez pouca ou nenhuma diferença. Apenas o sistema de arquivos em uso alterou os resultados apreciavelmente e essas diferenças foram bastante substanciais, como observei acima. Eu realmente tenho montanhas de pontos de dados sobre os vários parâmetros do sistema de arquivos que eu tentei e estas são algumas das variáveis que eu verifiquei: Configurações de ataque do mdadm (0 e 1) configurações zpool, espelho e faixa zfs registra tamanho do pedaço de mdadm sistema de arquivos em blocos
Em uma única unidade ST3500630AS, obtive esses números para as opções de sistema de arquivos padrão para os seguintes sistemas de arquivos. Isso foi no Fedora 19, 8GB de RAM, 3.11.10-200 kernel, ZFS 0.6.2-1. Os valores estão em segundos. As varreduras subseqüentes foram executadas sem qualquer tentativa de limpar o cache.
ZFS: 900, 804, 748, 745, 743, 752, 741
btrfs: 545, 33, 31, 30, 31, 31
ext2: 1091, 30, 30, 30, 30, 30...
ext3: 1014, 30, 30, 30, 30, 30...
ext4: 554, 31, 31, 32, 32, 31, 31...
jfs: 454, 31, 31,31,31...
xfs: 480, 32, 32, 32, 32 ,31 ,32, etc.
No FreeBSD 10, unidade única WD20EZRX-00D8PB0, máquina mais veloz, 16GB de memória, ARC permitido aumentar para 12GB:
ufs: 500, 18, 18...
zfs: 733, 659, 673, 786, 805, 657
Embora as variáveis acima tenham, às vezes, um efeito na varredura inicial do cache frio de os dados, são as execuções subseqüentes que parecem todas iguais. Sistemas de arquivos padrão armazenam em cache tudo e, portanto, enquanto nada mais faz com que o cache execute um raio rápido. O ZFS não exibe esse comportamento.
Comece por desativar o atime , se ainda não o fez.
Você também pode investigar a configuração primarycache=metadata impact.
No FreeBSD, instale sysutils / zfs-stats
A ferramenta 'zfs-mon' que faz parte desse pacote fornecerá detalhes sobre as taxas de acertos / erros do cache para cada um dos diferentes tipos de cache no ZFS (ARC, ARC Metadata, ZFETCH, Pré-busca, etc).
Além disso, 'zpool iostat 1' durante a digitalização pode ajudar
Por padrão, o cache de 'metadados' é limitado a 1/4 do ARC, você pode ajustar este valor com o sintetizador vfs.zfs.arc_meta_limit loader.conf
No FreeBSD 10, as estatísticas do ARC estão incluídas no 'top', observando como esses valores mudam enquanto você está digitalizando pode fornecer alguma visão
Tags zfs zfsonlinux freebsd