Software Cisco IOS e NX-OS : Cisco IOS 15.1M&T

Os erros MALLOCFAIL e os problemas de memória gerais pesquisam defeitos

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento discute erros MALLOCFAIL no ® nativo do Cisco IOS, assim como etapas para tomar e informação a recolher antes que você abra um exemplo do centro de assistência técnica da Cisco (TAC) ou recarregue o dispositivo a fim expedir a definição de problema. Este documento não é exaustivo, mas fornece uma diretriz geral usada a fim pesquisar defeitos edições da memória com muitos Roteadores e Switches.

Contribuído por Brandon Lynch, engenheiro de TAC da Cisco.

Erros MALLOCFAIL

Os problemas de memória manifestam-se em diversas maneiras no Switches e no Roteadores. Em muitos casos, um dispositivo que experimente erros de memória é recarregado antes que os dados apropriados estejam recolhidos.

As edições da memória aparecem geralmente sob a forma dos erros MALLOCFAIL nos logs de seu roteador ou interruptor. Estes erros são importantes porque fornecem de “sinais estrada” dirigir a investigação. Está aqui um erro MALLOCFAIL da amostra:

%SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed
from 0x60103098,
alignment 0
Pool: Processor  Free: 5453728  Cause: Memory fragmentation
Alternate Pool: None  Free: 0  Cause: No Alternate pool

A primeira coisa a observar é quanto a memória você precisa de atribuir e quanto memória livre você tem. Este exemplo mostra que uma encenação onde você deva atribuir 65KB de um pool que tem somente aproximadamente 5.45MB livra. A saída indica que, mesmo que haja uma memória livre suficiente, o bloco contínuo o maior é menor do que 65KB, e a alocação de memória falhada. Quando, por definição, isto for considerado fragmentação de memória, esta não é geralmente a causa. O mais frequentemente, é causada simplesmente pela memória baixa no pool própria.

A segunda coisa a observar é o tipo do pool. O exemplo do prevoius tratado o conjunto de processador. Isto é importante porque é o primeiro sinal de estrada que dirigem a investigação e os que necessidades de ser verificado. O pool especificado deve ser processador ou I/o. Está aqui um exemplo de um erro de memória de E/S:

%SYS-2-MALLOCFAIL: Memory allocation of 65548 bytes failed from 0x400B8564, 
alignment 32
Pool: I/O  Free: 39696  Cause: Not enough free memory
Alternate Pool: None  Free: 0  Cause: No Alternate pool

As próximas seções detalham estas associações mais. O pool é identificado uma vez, você pode focalizar seus esforços em conformidade nos pontos direitos.

Conjunto de processador

O conjunto de processador é usado, enquanto o nome implica, para os vários processos que são executado no roteador ou no interruptor. Há os processos específicos que são a base da maioria versões do Cisco IOS e de Plataformas que usam a memória. Por exemplo, Init é um processo estabelecido na inicialização da maioria de dispositivos, e esta presente através das várias Plataformas. Outros processos que puderam estam presente são baseados na configuração do dispositivo individual. Por exemplo, em Plataformas em que exprima é configurado e processos usados, Voz-específicos consomem a memória, quando em configurações mais generalizadas sem Voz, estes processos não guardarem tanto quanto, ou a toda a memória de todo.

Determinados processos guardam mais memória do que outro. Se há umas perguntas ou preocupação sobre um processo particular, é o melhor abrir um caso de TAC para tê-lo investigado.

Causas e que a recolher

  1. Se o dispositivo se tem submetido recentemente a um upgrade do Cisco IOS, a primeira coisa a verificar é o DRAM exigido mínimo para a imagem nova. Este deve ser igual ou menos do que à quantidade de DRAM instalada no dispositivo próprio. O mínimo exigiu o DRAM está listado sob a imagem dentro da ferramenta do download do software. Inscreva o comando show version a fim confirmar a quantidade de DRAM instalada:
    Cisco 2821 (revision 53.51) with 210944K/51200K bytes of memory.

    A fim determinar o DRAM total, adicionar estes números. Este roteador Cisco particular tem 256MB do DRAM.

  2. Uma outra causa possível é um escape de memória causado por um erro do Cisco IOS. Nesta situação, um processo consome uma quantidade excessiva de memória até que seja executado para fora. Incorpore estes comandos quando a memória é baixa a fim recolher a informação:
    show clock
    show mem stat
    show proc mem sorted
    show mem all totals
    show log

    O mem do proc da mostra classificou lista de comando todos os processos no ordem decrescente da quantidade de memória a mais alta guardada ao mais baixo. Identifique o processo o mais alto, mas exclua Init. Uma vez que a investigação está completa, encontre o processo ID (PID) para esse processo no lado esquerdo da saída, e recolha esta informação:
    show proc mem <PID #>

    Se o processo o mais alto está inoperante, recolha esta informação além do que as saídas precedentes:
    show mem dead totals
    show mem dead

    Determinados processos exigem uma investigação mais detalhada, mas não são cobertos neste documento.

  3. Uma outra causa potencial de edições da memória é encontrada quando você é executado fora da memória devido aos processos e à configuração no dispositivo. Um exemplo deste é o roteador (BGP) de protocolo de gateway de borda. Em alguns casos, o BGP guarda uma grande quantidade de memória devido ao número de rotas que recolhe. Isto não é causado por um erro do Cisco IOS. Este problema deve ser corrigido alterando a configuração a fim conseguir o roteamento ótimo e reduzir o consumo de memória.

    Se você é incerto, recolha as saídas alistadas previamente (exclua totais inoperantes do mem da mostra e mostre mortos do mem), e abra um caso de TAC, porque este problema exigirá provavelmente investigações adicionais.

Pool I/O

O pool I/O refere os bufferes I/O vistos com o comando show buffers. Estes bufferes são usados para o tráfego comutado por processo, entre outras coisas, como atualizações de roteamento ou transmissões. A memória de E/S é dividida nas associações, que são mostradas na saída do comando show buffers. Estas associações são baseadas no tamanho do pacote, que permite a atribuição dos mais eficiente da memória baseada nas necessidades.

Causas e que a recolher

  1. A primeira coisa a verificar com as edições da memória de E/S é um vazamento de buffer potencial causado por um erro do Cisco IOS. Isto manifesta-se frequentemente como um pool particular que aumenta sua quantidade de bufferes sem os liberar de novo no pool I/O são precisados uma vez que já não. Está aqui um exemplo deste:
     --------- show buffers --------

    Buffer elements:
         500 in free list (500 max allowed)
         3220350364 hits, 0 misses, 0 created

    Public buffer pools:
    Small buffers, 104 bytes (total 6144, permanent 6144):
         3867 in free list (2048 min, 8192 max allowed)
         248913132 hits, 0 misses, 0 trims, 0 created
         0 failures (0 no memory)
    Medium buffers, 256 bytes (total 86401, permanent 3000, peak 86401 @ 05:18:11):
         0 in free list (64 min, 3000 max allowed)
         9697361 hits, 203293 misses, 2208 trims, 85609 created
         167633 failures (651288 no memory)
    Middle buffers, 600 bytes (total 512, permanent 512):
         0 in free list (64 min, 1024 max allowed)
         9284431 hits, 237750 misses, 0 trims, 0 created
         224619 failures (680486 no memory)
    Big buffers, 1536 bytes (total 1000, permanent 1000):
         0 in free list (64 min, 1000 max allowed)
         69471745 hits, 895218 misses, 0 trims, 0 created
         842142 failures (1821074 no memory)
    VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 122 @ 1w3d):
         0 in free list (0 min, 100 max allowed)
         2120517 hits, 1632477 misses, 112 trims, 112 created
         1632421 failures (3272987 no memory)
    Large buffers, 9240 bytes (total 8, permanent 8, peak 18 @ 1w3d):
         0 in free list (0 min, 10 max allowed)
         9593 hits, 832217 misses, 44 trims, 44 created
         832195 failures (1651309 no memory)
    Huge buffers, 18024 bytes (total 2, permanent 2):
         0 in free list (0 min, 4 max allowed)
         1325 hits, 831497 misses, 0 trims, 0 created
         831494 failures (1649904 no memory)

    A saída precedente mostra claramente que o problema é com o pool médio. Seu valor total é muito mais alto do que a quantidade permanente ajustada para esse pool. A saída mostra que, mesmo com sobre 86,000 bufferes no pool, você tem 0 disponível na lista livre. Finalmente, a saída mostra que o número de guarnições é muito mais baixo do que o número criado, que indica que estes não estiveram liberados de novo no pool I/O para um consumo mais adicional. Para uma explicação mais adicional destes campos, veja as definições para campos do pool de buffers ligar na seção Informação Relacionada na extremidade deste documento.

    Para esta encenação, capture primeiramente estas saídas:
    show clock
    show mem stat
    show buffers
    show log

    Uma vez o pool ou as associações problemáticas são determinado, incorporam este comando a fim centrar-se sobre o conjunto de problema:
    show buffer pool <pool name> packet

    Este comando pôde fornecer a saída extensiva. Você pode geralmente determinar que pacotes residem nestes bufferes e quem os atribuiu dentro de algumas páginas da saída.

  2. Uma outra causa possível é um evento da rede/tráfego. Isto manifesta-se frequentemente como a utilização excessiva nos conjuntos múltiplos. Recomenda-se que as saídas precedentes estejam recolhidas, junto com o comando packet do name> do <pool do show buffer pool output para as associações que mostram esta utilização, e que você abre um caso de TAC. Isto é causado frequentemente por um fluxo de tráfego anormal ou inesperado que deva ser comutado por processo pelo dispositivo. Porque o fluxo pôde ser intermitência e rápido, você pode ser executado fora da memória de E/S relativamente em um período de tempo curto. A fim pesquisar defeitos este tipo de problema, geralmente você deve identificar a fonte do tráfego a fim ver se este fluxo é anormal e, em caso afirmativo, elimina-o ou obstrui-.

  3. Outro, um evento mais raro é que um pool específico pesado-está utilizado mais devido a determinado tráfego que é precisado em um ambiente de rede. Este tráfego pôde, por qualquer motivo, precisar de ser comutado por processo, e não há nenhuma maneira de evitar isto na rede. Esta encenação deve ser confirmada mais, e então a ação apropriada deve ser tomada. As mesmas saídas de etapa 1 aplicam-se aqui.

Artigos a investigar

Na maioria de Roteadores, os exemplos do erro MALLOCFAIL apresentados previamente são padrão. Em Cisco Catalyst 6500 Series Switch e em 7600 Series Router com motores do supervisor (SUP) ou Route Switch Processor (RSP), estes erros puderam variar. Por exemplo, este erro foi tomado do route processor (RP) entra um 6500 Series Switch:

%SYS-SP-2-MALLOCFAIL: Memory allocation of 820 bytes failed from 0x40C83B60,
alignment 32
Pool: I/O  Free: 48  Cause: Not enough free memory
Alternate Pool: None  Free: 0  Cause: No Alternate pool

O erro MALLOCFAIL mostra que o switch processor (SP) do SUP relata o problema, não o RP. Se o problema é associado com o RP, a designação SP no erro não está atual. Por este motivo, as saídas precedentes devem ser tomadas do SP. A fim realizar isto, preceda os comandos com:

remote command switch

O Mensagem de Erro pôde igualmente referir o SUP/RSP à espera RP ou SP como denotado por STDBY, e necessidades ser recolhido em conformidade.

Resumo

Você pôde acelerar a definição do caso e trazer a estabilidade a seu dispositivo mais rapidamente se você recolhe as saídas alistadas neste documento. Se alguma pergunta elevara ou se há uma incerteza sobre o desempenho da memória em um dispositivo, é o melhor abrir um caso de TAC a fim tê-lo investigado.

Informações Relacionadas



Document ID: 116467