Desde a atualização para o Solaris 11, meu tamanho de ARC tem sido alvo de 119 MB, apesar de ter 30 GB de RAM. O que? Por quê?

Question

Eu executei uma caixa NAS / SAN no Solaris 11 Express antes do lançamento do Solaris 11. A caixa é um HP X1600 com um D2700 conectado. Ao todo, 12 discos 1TB 7200 SATA, discos SAS 10x 300GB 10k em zpools separados. O total de RAM é de 30 GB. Os serviços fornecidos são CIFS, NFS e iSCSI.

Tudo estava bem, e eu tinha um gráfico de uso de memória ZFS assim:

Umtamanhodearcorazoavelmentesaudáveldecercade23GB-fazendousodamemóriadisponívelparaarmazenamentoemcache.

Noentanto,atualizeiparaoSolaris11quandoissofoilançado.Agora,meugráficoéassim:

A saída parcial de arc_summary.pl é:

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26719 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             915 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

Tem como alvo 119MB enquanto está sentado em 915MB. Tem 30GB para brincar. Por quê? Eles mudaram alguma coisa?

Editar

Para esclarecer, arc_summary.pl é de Ben Rockwood, e as linhas relevantes que geram as estatísticas acima são:

my $mru_size = ${Kstat}->{zfs}->{0}->{arcstats}->{p};
my $target_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c};
my $arc_min_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_min};
my $arc_max_size = ${Kstat}->{zfs}->{0}->{arcstats}->{c_max};
my $arc_size = ${Kstat}->{zfs}->{0}->{arcstats}->{size};

As entradas do Kstat estão lá, só estou tirando valores estranhos delas.

Editar 2

Acabei de medir novamente o tamanho do arco com arc_summary.pl - verifiquei esses números com kstat :

System Memory:
     Physical RAM:  30701 MB
     Free Memory :  26697 MB
     LotsFree:      479 MB

ZFS Tunables (/etc/system):

ARC Size:
     Current Size:             744 MB (arcsize)
     Target Size (Adaptive):   119 MB (c)
     Min Size (Hard Limit):    64 MB (zfs_arc_min)
     Max Size (Hard Limit):    29677 MB (zfs_arc_max)

A coisa que me impressiona é que o tamanho do alvo é de 119MB. Olhando para o gráfico, ele tem como alvo exatamente o mesmo valor (124.91M de acordo com os cactos, 119M de acordo com arc_summary.pl - pense que a diferença é apenas 1024/1000 problemas de arredondamento) desde que o Solaris 11 foi instalado. Parece que o kernel está fazendo um esforço zero para mudar o tamanho do alvo para algo diferente. O tamanho atual está flutuando conforme as necessidades do sistema (grande) lutam com o tamanho do alvo, e parece que o equilíbrio está entre 700 e 1000MB.

Então, a questão agora é um pouco mais pontuada - por que o Solaris 11 é difícil de definir meu tamanho de destino de ARC como 119 MB e como alterá-lo? Devo aumentar o tamanho mínimo para ver o que acontece?

Colocamos a saída de kstat -n arcstats no link

Editar 3

Ok, estranheza agora. Eu sei flibflob mencionou que havia um patch para consertar isso. Ainda não apliquei esse patch (ainda resolvo problemas de suporte interno) e não apliquei nenhuma outra atualização de software.

Última quinta-feira, a caixa caiu. Como, completamente parou de responder a tudo. Quando eu reiniciei, ele voltou bem, mas aqui está o meu gráfico agora parece.

Parece ter resolvido o problema.

Isso é apropriado para as coisas da terra agora. Eu literalmente não faço ideia do que está acontecendo. : (

    

Answer 1

Infelizmente, não consigo resolver o seu problema, mas aqui estão algumas informações básicas:

• O tamanho de destino do ARC não parece ser um valor de correção. Eu experimentei o mesmo problema em uma máquina Solaris 11 e após cada reinicialização, em algum momento, o tamanho do alvo parece travar em um valor entre ~ 100 e ~ 500MB.

• Pelo menos mais 3 pessoas estão enfrentando o mesmo problema, conforme discutido em link

• Existe também um relatório de erros aberto (7111576) em "My Oracle Support" ( link ). Se o seu servidor estiver sob um contrato de suporte válido, você deve registrar uma solicitação de serviço e se referir a esse bug. A partir de agora, qualquer bugfix ainda parece estar em progresso ...

Além disso, não há muito que você possa fazer. Se você ainda precisa atualizar suas versões do zpool / zfs, tente inicializar em seu antigo ambiente de inicialização do Solaris 11 Express e executá-lo até que o Oracle finalmente decida lançar um SRU que corrija o problema.

Editar: Como a questão da degradação do desempenho foi discutida acima: Tudo depende do que você está fazendo. Eu vi latências horríveis no meu Solaris 11 NFS desde a atualização para o Solaris 11 11/11. Comparado ao seu sistema, no entanto, eu tenho relativamente poucos fusos e baseio-me strongmente no armazenamento em cache do ARC e L2ARC, funcionando como esperado (lembre-se de que o problema também faz com que o L2ARC não aumente para um tamanho razoável). Isso certamente não é uma questão de estatísticas mal interpretadas.

Mesmo que você não dependa muito do ARC / L2ARC, provavelmente será capaz de reproduzi-lo lendo um arquivo grande (que normalmente caberia em sua RAM) várias vezes com dd . Você provavelmente notará que a primeira vez que ler o arquivo será realmente mais rápida do que qualquer leitura consecutiva do mesmo arquivo (devido ao ridículo tamanho do ARC e incontáveis despejos de cache).

Editar: agora consegui receber um patch de IDR da Oracle que resolve esse problema. Se o seu sistema estiver sob suporte, você deve solicitar o patch de IDR para o CR 7111576. O patch se aplica ao Solaris 11 11/11 com SRU3.

    

Answer 2

Eles mudaram os kstats.

O Oracle Solaris 11 removeu as seguintes estatísticas do zfs: 0: arcstats:

• evict_l2_cached
• evict_l2_eligible
• evict_l2_ineligible
• evict_skip
• hdr_size
• l2_free_on_write
• l2_size recycle_miss

e adicionou o seguinte ao zfs: 0: arcstats:

• buf_size
• meta_limit
• meta_max
• meta_used

Então, isso basicamente pode ser apenas um problema com seu script.