ZFS com L2ARC (SSD) mais lento para pesquisas aleatórias do que sem L2ARC

Question

No momento, estou testando o ZFS (Opensolaris 2009.06) em um servidor de arquivos antigo para avaliar seu uso de acordo com nossas necessidades. Nossa configuração atual é a seguinte:

• Dual core (2,4 GHz) com 4 GB de RAM
• Controlador SATA de 3x com 11 HDDs (250 GB) e um SSD (OCZ Vertex 2 100 GB)

Queremos avaliar o uso de um L2ARC, então o atual ZPOOL é:

$ zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME         STATE     READ WRITE CKSUM
        afstank      ONLINE       0     0     0
          raidz1     ONLINE       0     0     0
            c11t0d0  ONLINE       0     0     0
            c11t1d0  ONLINE       0     0     0
            c11t2d0  ONLINE       0     0     0
            c11t3d0  ONLINE       0     0     0
          raidz1     ONLINE       0     0     0
            c13t0d0  ONLINE       0     0     0
            c13t1d0  ONLINE       0     0     0
            c13t2d0  ONLINE       0     0     0
            c13t3d0  ONLINE       0     0     0
        cache
          c14t3d0    ONLINE       0     0     0

onde c14t3d0 é o SSD (claro). Nós executamos testes IO com o bonnie ++ 1.03d, o tamanho é configurado para 200 GB (-s 200g) para que a amostra de teste nunca seja completamente em ARC / L2ARC. Os resultados sem SSD são (valores médios em várias execuções que não mostram diferenças)

write_chr       write_blk       rewrite         read_chr        read_blk        random seeks
101.998 kB/s    214.258 kB/s    96.673 kB/s     77.702 kB/s     254.695 kB/s    900 /s

Com o SSD, torna-se interessante. Minha suposição era que os resultados deveriam estar no pior dos casos pelo menos iguais. Enquanto as taxas de escrita / leitura / reescrita não são diferentes, a taxa de busca aleatória difere significativamente entre execuções + bonnie individuais (entre 188 / s e 1333 / s até agora), a média é 548 + - 200 / s, portanto abaixo do valor sem SSD.

Então, minhas perguntas são principalmente:

1. Por que as taxas de busca aleatória diferem muito? Se as buscas são realmente aleatórias, elas não devem diferir muito (minha suposição). Portanto, mesmo que o SSD esteja prejudicando o desempenho, ele deve ser o mesmo em cada execução do bonnie ++.
2. Por que o desempenho de busca aleatória é pior na maioria das execuções bonnie ++? Eu suponho que alguma parte dos dados do bonnie ++ esteja no L2ARC e buscas aleatórias nesses dados tenham um desempenho melhor, enquanto buscas aleatórias em outros dados apenas funcionam da mesma forma como antes.

Answer 1

Não sei por que você está vendo o comportamento que está vendo, mas posso dizer por que eles não indicam necessariamente o desempenho terrível do ZFS no mundo real. Bonnie é projetado para medir o desempenho dos discos reais e intencionalmente tenta não aproveitar o cache de disco / memória. Você está tentando usá-lo para medir o cache de disco.

Pode levar horas para um dispositivo L2ARC ficar quente. Dependendo da quantidade de memória principal que você tem para o ARC e do desempenho do disco com sua carga de trabalho, um SSD de 100 GB para o L2ARC levará de 1 a 2 horas para ficar quente e talvez até mais ( Origem ). Em segundo lugar, o L2Arc é projetado para armazenar em cache leituras aleatórias e não transmitir cargas de trabalho de leitura. "Se você usar o L2ARC para uma carga de trabalho sequencial ou de fluxo contínuo, o L2ARC irá ignorá-lo e não armazená-lo em cache" ( Source ). Eu ficaria realmente surpreso se grande parte da sua boa carga de trabalho chegasse ao L2ARC. Em vez de usar o bonnie ++, tente gerar uma carga que se pareça com o uso real do sistema.

Embora seja improvável, executar as últimas versões de desenvolvimento do Bonnie ++ (1.96 x 1.03d) pode produzir algo mais próximo aos resultados esperados. Você também pode querer dar uma olhada neste post sobre blogs sobre bonnie ++ com a série Sun 7000 , embora eles passem por cima do NFS e não localmente.

    

Answer 2

Você também pode ativar o cache de dados de streaming no L2ARC no seu SSD.

O parâmetro l2arc_noprefetch é útil para isso.

Este ajuste determina se os dados de streaming são armazenados em cache ou não. O padrão é não armazenar em cache os dados de fluxo (o valor padrão é true). Se você defini-lo como false, provavelmente verá sua taxa de acertos do cache do L2ARC aumentar significativamente.