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


9

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 anexado. No total, discos 12x 1TB 7200 SATA, discos SAS de 300 GB e 10k em zpools separados. A RAM total é 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 do ZFS assim:

Um tamanho de arco razoavelmente saudável de cerca de 23 GB - usando a memória disponível para armazenamento em cache.

No entanto, atualizei para o Solaris 11 quando ele foi lançado. Agora, meu gráfico fica assim:

A produção 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)

Ele tem como alvo 119MB enquanto está sentado em 915MB. Tem 30 GB para jogar. 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 obtendo valores ímpares delas.

Editar 2

Acabei de medir novamente o tamanho do arco 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)

O que me impressiona é que o tamanho do alvo é de 119 MB. Olhando para o gráfico, ele tem exatamente o mesmo valor (124,91M de acordo com cactos, 119M de acordo com arc_summary.pl- pense que a diferença são apenas 1024/1000 de arredondamento) desde que o Solaris 11 foi instalado. Parece que o kernel não faz nenhum esforço para mudar o tamanho do alvo para algo diferente. O tamanho atual está flutuando à medida que as necessidades do sistema (grande) lutam com o tamanho desejado, e parece que o equilíbrio está entre 700 e 1000MB.

Portanto, a questão agora é um pouco mais clara - por que o Solaris 11 está definindo com dificuldade o tamanho do meu alvo do ARC para 119MB e como faço para alterá-lo? Devo aumentar o tamanho mínimo para ver o que acontece?

Coloquei a saída de kstat -n arcstatsmais em http://pastebin.com/WHPimhfg

Editar 3

Ok, estranheza agora. Eu sei que o flibflob mencionou que havia um patch para corrigir isso. Ainda não apliquei este patch (ainda resolvendo problemas de suporte interno) e não apliquei outras atualizações de software.

Na quinta-feira passada, a caixa bateu. Como, parou completamente de responder a tudo. Quando eu o reiniciei, ele voltou a funcionar bem, mas eis como está agora o meu gráfico.

Parece ter resolvido o problema.

Este é o material apropriado para a terra agora. Eu literalmente não tenho ideia do que está acontecendo. :(

Respostas:


4

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

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

  • Pelo menos três outras pessoas estão enfrentando o mesmo problema, conforme discutido em http://mail.opensolaris.org/pipermail/zfs-discuss/2012-January/050655.html

  • Há também um relatório de bug aberto (7111576) em "My Oracle Support" ( https://support.oracle.com ). Se o seu servidor estiver sob um contrato de suporte válido, você deve registrar uma solicitação de serviço e consultar esse bug. A partir de agora, qualquer correção ainda parece estar em andamento ...

Fora isso, não há muito que você possa fazer. Se você ainda não atualizou suas versões do zpool / zfs, tente inicializar em seu antigo ambiente de inicialização Solaris 11 Express e executá-lo até que a Oracle finalmente decida lançar uma SRU que corrige o problema.

Edit: Desde que a questão da degradação do desempenho foi discutida acima: Tudo depende do que você está fazendo. Vi latências horríveis no meu compartilhamento Solaris 11 NFS desde a atualização para o Solaris 11 11/11. Comparado ao seu sistema, no entanto, tenho relativamente poucos eixos-árvore e confio bastante no cache do ARC e L2ARC funcionando conforme o esperado (lembre-se de que o problema também faz com que o L2ARC não cresça em um tamanho razoável). Certamente não se trata de estatísticas mal interpretadas.

Mesmo que você não confie muito no ARC / L2ARC, provavelmente poderá reproduzi-lo lendo um arquivo grande (que normalmente caberia na sua RAM) várias vezes com o 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 tamanho ridículo do ARC e às inúmeras expulsões de cache).

Editar: Agora consegui receber um patch IDR da Oracle que resolve esse problema. Se o seu sistema estiver com suporte, solicite o patch IDR para CR 7111576. O patch se aplica ao Solaris 11 11/11 com SRU3.


Eu acho que estou sob apoio, mas eu trabalho em um corporativa enorme, então quem sabe?
— growse

1

Eles mudaram o 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

Portanto, isso poderia ser apenas um problema com seu script.


É um ponto interessante, mas acho que não estou usando nenhuma dessas métricas para relatar esses números. Veja editar.
— growse

Aqueles realmente ainda estão aqui. Considerando isso, isso parece muito estranho. Você vê algum tipo de degradação do desempenho?
— juwi

Eu não posso dizer que tenho. Eu provavelmente deveria medir isso.
— growse

Caso isso não seja um erro no que você está vendo e você realmente tenha uma singularidade lá, observe que PODE modificar esses valores rapidamente em um sistema ativo ou usando permanentemente o / etc / system.
— Nex7 28/02/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.