Volumes Solaris ZFS: carga de trabalho que não atinge o L2ARC

6

Configurei uma máquina Solaris Express 11 com alguns discos rígidos razoavelmente rápidos atrás de um controlador RAID, configurei o dispositivo como um zpool com a compactação ativada e adicionei um registro espelhado e dois dispositivos de armazenamento em cache a ele. Os conjuntos de dados são expostos como FC alvos para uso com o ESX e eu o preenchai com alguns dados para brincar. O L2ARC foi parcialmente preenchido (e por algum motivo não preenche mais), mas eu dificilmente vejo qualquer uso dele. zpool iostat -v mostra que pouco foi lido no cache no passado:

tank           222G  1.96T    189     84   994K  1.95M
  c7t0d0s0     222G  1.96T    189     82   994K  1.91M
  mirror      49.5M  5.51G      0      2      0  33.2K
    c8t2d0p1      -      -      0      2      0  33.3K
    c8t3d0p1      -      -      0      2      0  33.3K
cache             -      -      -      -      -      -
  c11d0p2     23.5G  60.4G      2      1  33.7K   113K
  c10d0p2     23.4G  60.4G      2      1  34.2K   113K

e o script arcstat.pl habilitado para L2ARC mostra 100% perde para L2ARC para a carga de trabalho atual:

./arcstat.pl -f read,hits,miss,hit%,l2read,l2hits,l2miss,l2hit%,arcsz,l2size 5
read  hits  miss  hit%  l2read  l2hits  l2miss  l2hit%  arcsz  l2size
[...]
 243   107   136    44     136       0     136       0   886M     39G
 282   144   137    51     137       0     137       0   886M     39G
 454   239   214    52     214       0     214       0   889M     39G
[...]

Primeiro suspeitei que poderia ser um impacto do registro ser muito grande para que O L2ARC reconhece tudo como uma carga de streaming, mas o zpool não contém nada além de volumes zfs (criei-os como "esparsos" usando zfs create -V 500G -s <datasetname> ) que nem sequer têm um parâmetro recordset para alterar.

Eu também encontrei muitas noções sobre L2ARC precisando de 200 Bytes de RAM por registro para seus metadados, mas foi até agora incapaz de descobrir o que L2ARC consideraria um "registro" com um conjunto de dados de volume - um único setor de 512 Bytes? Pode estar sofrendo de falta de memória RAM para metadados e apenas até agora ser preenchido com lixo que nunca é lido novamente?

Editar: Adicionando 8 GB de RAM aos 2 GB instalados já funcionou muito bem - a RAM adicional é usada com alegria mesmo em uma instalação de 32 bits e o L2ARC agora cresceu e está ser atingido:

    time  read  hit%  l2hit%  arcsz  l2size
21:43:38   340    97      13   6.4G     95G
21:43:48   185    97      18   6.4G     95G
21:43:58   655    91       2   6.4G     95G
21:44:08   432    98      16   6.4G     95G
21:44:18   778    92       9   6.4G     95G
21:44:28   910    99      19   6.4G     95G
21:44:38  4.6K    99      18   6.4G     95G

Obrigado ao ewwhite .

    
por the-wabbit 12.09.2011 / 14:36

1 resposta

7

Você deve ter mais memória RAM no sistema. Ponteiros para L2ARC precisam ser mantidos na RAM (ARC), então eu acho que você precisaria de cerca de 4GB ou 6GB de RAM para utilizar melhor os ~ 60GB de L2ARC que você tem disponível.

Isto é de um tópico recente na lista do ZFS:

link

L2ARC is "secondary" ARC. ZFS attempts to cache all reads in the ARC 
(Adaptive Read Cache) - should it find that it doesn't have enough space 
in the ARC (which is RAM-resident), it will evict some data over to the 
L2ARC (which in turn will simply dump the least-recently-used data when 
it runs out of space). Remember, however, every time something gets 
written to the L2ARC, a little bit of space is taken up in the ARC 
itself (a pointer to the L2ARC entry needs to be kept in ARC). So, it's 
not possible to have a giant L2ARC and tiny ARC. As a rule of thumb, I 
try not to have my L2ARC exceed my main RAM by more than 10-15x (with 
really bigMem machines, I'm a bit looser and allow 20-25x or so, but 
still...). So, if you are thinking of getting a 160GB SSD, it would be 
wise to go for at minimum 8GB of RAM. Once again, the amount of ARC 
space reserved for a L2ARC entry is fixed, and independent of the actual 
block size stored in L2ARC. The jist of this is that tiny files eat up 
a disproportionate amount of systems resources for their size (smaller 
size = larger % overhead vis-a-vis large files).
    
por 12.09.2011 / 18:22