Tenho 4 cabeçalhos de arquivamento NetApp 2240-4. Eles são "cluster em uma caixa" chassis único assim duas unidades separadas.
Nos últimos dias, mais ou menos na mesma época - todos começaram a registrar muitos pontos de consistência de marca d'água baixa.
A execução de wafl_susp -w me dá cp_from_low_water de clock a uma taxa de 10 / s ou mais. Antes disso, eles eram quase inteiramente cp_from_timer a uma taxa de 1 a cada 10 ou mais.
Duas das minhas caixas pararam de responder e foram reiniciadas, e o problema desapareceu novamente. Não tenho 100% de certeza de que esteja conectado, mas parece uma aposta razoável quanto a um culpado.
Os outros dois - estão completamente ociosos, já que eles têm um sistema operacional básico e alguns vfilers - e nada mais. Mas ainda - marca d'água baixa, sugere que eles estão ficando sem memória, por algum motivo. Eu só posso supor que algum tipo de negação de condição de serviço está ocorrendo (talvez 'logins SSH com falha'?).
Alguém pode oferecer uma visão sobre como solucionar isso? Especificamente de uma perspectiva da NetApp, estou procurando algumas dicas sobre como extrair o que está ocupando minha memória.
Abra um ticket - isso é uma indicação de que há uma falta de memória do sistema , e se há pouco trabalho sendo feito e você ainda tem caixas não respondem, há algo de errado acontecendo. Eu andei pelo processo de inspecionar o uso da memória interna antes com o suporte na linha, mas não é algo que os clientes devem fazer sozinhos. Você precisaria usar um comando priv set e verificar os processos em execução.
Caso aberto com o fornecedor em relação ao problema.
CPs com ponto de vista baixo são o resultado do esgotamento da memória: (link para o fornecedor)
CP caused by low water mark; the amount of memory available for routine housekeeping tasks is low enough that it is ideal to start a CP to release some more
Para fazer a interface com o fornecedor, executamos um 'perfstat' - uma ferramenta para download da NetApp que permite enviar informações de suporte relacionadas ao perf. Isso nos levou a bug ID 697790 (login de suporte necessário), presente na versão do código em que estávamos, corrigido no ONTAP 8.2.3
Especificamente, um vazamento de memória no caso específico em que a autenticação LDAP estava falhando. Porque todos os 4 hosts estavam usando a mesma conta, e porque em algum momento o bloqueio tinha tropeçado, todos eles estavam falhando absurdamente freqüentemente. (E foram especificamente sistemas de memória muito baixa em primeiro lugar).
Eu olhei para outros sistemas onde este bug esteve presente, e há alguns sinais disso acontecer, mas mesmo em sistemas com mais de 700 dias de atividade, uma quantidade insignificante ocorreu.
Em geral (e com uma ressalva de que os comandos 'diag' são potencialmente perigosos para usar, isso deve ser feito com extrema cautela sem falar com o fornecedor) - poderíamos identificar o problema observando mem_stat - a segunda coluna é ' bytes 'e procure por' sasl '.
1306719 5268691008 maytag.ko::sasl_client_new+149
Eu não sei em que nível o problema surge - estou esperando que os sistemas colidam novamente para verificar. Mas sugeriria que mais de 5% de utilização de memória você deveria estar pensando em tomar medidas. Uma reinicialização é corrigida, assim como uma atualização de código.
Agora estou capturando cp_types e footprint de memória como parte do meu regime de monitoramento, para que eu possa observá-lo ocorrendo. Também sendo um pouco mais proativo sobre detectar bloqueios de conta LDAP.