Solucionar problemas de memória no IOS XE via Callsite

Introdução

Este documento descreve como solucionar problemas de memória em dispositivos baseados no Cisco IOS® XE, como roteadores e switches para um local de chamada com vazamento.

Pré-requisitos

Conhecimento em gerenciamento de memória em dispositivos baseados no software Cisco IOS XE.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas. Ele se aplica a plataformas baseadas no software Cisco IOS XE de roteamento e switching.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O monitoramento do uso da memória de produção do dispositivo para incrementos delta e a confirmação de se ele é esperado é demorado. Este documento explica o que é um local de chamada e como ele ajuda a solucionar problemas de memória rapidamente.

Observação: este documento se concentra principalmente na solução de problemas de uso de memória da Memória Dinâmica de Acesso Aleatório (DRAM) do processador de roteamento.

O que é o Callsite?

O local de chamada é uma marca usada pelo Cisco Technical Assistance Center (TAC) para verificar e rastrear quais funções do código-fonte estão sendo chamadas durante alocações de memória feitas pelos processos relacionados ao Cisco IOS-XE.

Os clientes podem fornecer essa marca antes de abrir um caso de TAC para uma resolução mais rápida e também podem ajudar na depuração pelos comandos apresentados mais adiante neste artigo.

Chamadas de comparação e bytes de comparação

Chamadas de comparação monitoram a disparidade entre o número de chamadas para alocações e desalocações de memória. Normalmente, um alto volume de chamadas diff pode significar um problema relacionado à memória. Isso ocorre quando há quantidades excessivas de diffs, indicando que o sistema não está liberando memória e as alocações estão se acumulando.

Tanto as chamadas diff quanto os bytes diff podem ser vistos com commandshow processes memory platform accounting:

test1#show processes memory platform accounting 
  Hourly Stats

  process                   callsite_ID(bytes)          max_diff_bytes    callsite_ID(calls)   max_diff_calls  tracekey                                  timestamp(UTC)    
  -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
  sessmgrd_rp_0               F8E78C86E08C8003                 1579683      E6A19D3ED0064000            12269  1#90e06c15b54d23761b2b3b480e5fd704        2025-05-28 05:30  
  cli_agent_rp_0              A5E99693AA3B8004                 1268440      5D11C89CA87A8003             3197  1#3afb1165961ee7daf4af986e47f2f32c        2025-05-28 05:40  
  smand_rp_0                  3DFF8F3C424F400A                  918144      C34A609190E3C001              420  1#51a1581a8ac23e847e66fe8f268c66d1        2025-05-29 06:31  
  

O sistema tem limites internos de uso de memória que acionam avisos de memória e syslogs de nível crítico. O percentual de uso da memória com base nesses limites pode ser visualizado usando o comando show platform resources.

test1#show platform resources 
**State Acronym: H - Healthy, W - Warning, C - Critical                                             
Resource                 Usage                 Max             Warning         Critical        State
----------------------------------------------------------------------------------------------------
RP0 (ok, active)                                                                               H    
 Control Processor       1.17%                 100%            80%             90%             H    
  DRAM                   2639MB(34%)           7753MB          88%             93%             H    
  bootflash              856MB(13%)            6338MB          88%             93%             H    
  harddisk               0MB(0%)               0MB             88%             93%             H    
ESP0(ok, active)                                                                               H    
 QFP                                                                                           H    
  TCAM                   10cells(0%)           131072cells     65%             85%             H    
  DRAM                   89761KB(2%)           3670016KB       85%             95%             H    
  IRAM                   13525KB(10%)          131072KB        85%             95%             H    
  CPU Utilization        1.00%                 100%            90%             95%             H    
  Crypto Utilization     3.00%                 100%            90%             95%             H    
  Pkt Buf Mem (0)        67KB(0%)              524288KB        85%             95%             H    

test1#

Note: Registre um caso de TAC para determinar se as chamadas ou bytes de comparação dizem respeito a um processo em particular. Geralmente, se houver pouca memória livre no sistema, conforme visível com o comando show processes memory platform sorted,vale a pena verificar mais.

Sintomas de consumo de memória ou problemas de vazamento

Quando há um problema de consumo de memória ou de vazamento no Cisco IOS XE, geralmente é gerado um alarme crítico ou um aviso, por exemplo:

Nov 22 11:37:16.770: %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: Used Memory value 89% exceeds warning level 88%. Top memory allocators are: Process: iomd_cc_0. Tracekey: 1#7eed26e49896115921b704a6d9780e72  Callsite ID: 4163698691 (diff_call: 395435). Process: iomd_cc_0. Tracekey: 1#7eed26e49896115921b704a6d9780e72  Callsite ID: 4163698691 (diff_call: 29). Process: btman_rp_0. Tracekey: 1#e7e4075661e7b1cbf867dc220f1b120c  Callsite ID: 407738370 (diff_call: 23).

Esse tipo de alarme destaca informações valiosas como ponto de partida para a solução de problemas:

• Data e hora em que o alarme foi recebido
• Porcentagem de uso
• Componente afetado
• Principais processos do Cisco IOS XE que o sistema detectou como principais consumidores com base em chamadas de comparação.

Note: O alarme %PLATFORM-4-ELEMENT_WARNING não é necessariamente um ponto de dados conclusivo para obter a RCA (análise da causa raiz) de um problema de consumo de memória.

Note: Há outros tipos de sintomas e alarmes de uso de memória associados a diferentes componentes, como o Temporal File System (TMPFS), o Quantum Flow Processor (QFP) e o daemon do Cisco IOS (IOSd), no entanto, eles estão fora do escopo deste documento. 

Note: Este documento não aborda o troubleshooting de mensagens de syslog SYS-2-MALLOCFAIL que indicam problemas de memória sob o daemon do Cisco IOS (IOSd).

Cenários de Troubleshooting

O dispositivo travou devido à falta de memória

Quando o dispositivo trava devido à falta de recursos de memória, é importante verificar os últimos logs antes do travamento para confirmar e ver se a mensagem do syslog %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: O valor de Memória Usada X% excede o nível de aviso Y% está presente.

Note: Observe que os syslogs do buffer DRAM local são apagados após um travamento devido à falta de memória, portanto, é necessário verificar os logs de arquivamento do servidor syslog antes do evento de travamento. Se o Servidor syslog ainda não estiver configurado, consulte Como configurar o registro no Cisco IOS. 

Note: O %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: O valor da memória usada X% excede o nível de aviso do alarme Y% depois que um evento de travamento também pode ser visto nos registros de rastreamento decodificados do Cisco IOS. Consulte Coletar e Gerenciar Logs de Rastreamento com Aprimoramento de Log Unificado para obter mais informações.

Devido à memória insuficiente, ocorreu um travamento no sistema. Consequentemente, um relatório do sistema é gerado. Este relatório é um arquivo .tar.gz que contém dados pertinentes que podem ser utilizados para investigar o problema de memória. Consulte Solução de problemas usando relatórios do sistema para obter mais informações.

Quando descompactado, o relatório do sistema contém um diretório chamado maroon stats dentro do diretório tmp. O maroon stats é uma facilidade de manutenção implementada em código que rastreia alocações e desalocações de memória em chamadas e bytes diferentes para diferentes processos do Cisco IOS XE.

O instantâneo de estatísticas maroon contido no relatório do sistema ajuda a identificar um site de chamada culpado em potencial para determinar o consumo de memória ou o problema de vazamento RCA ou depurá-lo ainda mais e entendê-lo melhor.

Note: A decodificação do diretório maroon stats a partir de um relatório do sistema só pode ser feita pelo TAC, pois ele contém funções internas e confidenciais de código que ajudam o engenheiro do TAC a entender quais funções de código estão alocando a memória. Registre um caso de TAC e forneça o relatório do sistema.

Note: Tenha em mente que o relatório do sistema fornece uma boa quantidade de dados para entender um travamento de memória devido à falta de memória, no entanto, em alguns casos, é necessário mais rastreamento de memória, monitoramento, depuração e solução de problemas.

O dispositivo ainda não travou, mas tem avisos de uso de memória

O comando show platform resources mostra limites de uso de memória críticos e de advertência. 

Observação: é uma prática recomendada coletar comandos de saída relacionados à memória para depurar ainda mais, pois, dependendo da velocidade com que o consumo ou vazamento de memória pode ocorrer, o dispositivo pode estar em risco de travamento devido à falta de recursos de memória. 

Note: Quando avisos de uso de memória são vistos, você pode arquivar um caso de TAC e fornecer comandos show tech-support e 

show tech-support memory que ajuda o engenheiro do TAC a fazer a triagem inicial do problema e possivelmente encontrar um RCA imediatamente.

Quando o dispositivo ainda não travou e está gerando os alarmes de memória no buffer de syslog local ou recebido do servidor syslog através da ferramenta de monitoramento, colete a saída de show processes memory platform classificada para determinar os bytes consumidos pelo processo ofensivo, se houver.

Router#show processes memory platform sorted 
System memory: 4027884K total, 2580612K used, 1447272K free,
Lowest: 1447272K
   Pid    Text      Data   Stack   Dynamic       RSS     Total              Name  
--------------------------------------------------------------------------------
 21240  263436    858000     136       308    858000   3632460   linux_iosd-imag  
 27232   12877    195460     136     23592    195460   2231316     fman_fp_image  
 26797      90    157260     136     22308    157260   1741996        cpp_cp_svr  
 19194    7325    102756     136      2376    102756   1318608           fman_rp  
 27179   18745    242708     136       448    242708   1160248    qfp-ucode-utah  

Nesta saída, observe a coluna Tamanho do conjunto residente (RSS). Este é um indicador de quantos kilobytes cada processo do Cisco IOS XE está consumindo.

Identificar o local de chamada

Em seguida, reúna a saída de show processes memory platform accounting que mostra os valores de bytes e chamadas de comparação para processos diferentes. Geralmente, nos concentramos nos valores maiores. 

Os bytes de chamada de comparação são um bom indicador para determinar se pode haver um vazamento de memória potencial, pois mostram quantos bytes de memória ainda são retidos pelo sistema por um processo sem serem liberados de volta para o sistema.

Com base nesses dados, você pode identificar qual é a tag callsite do processo ofensivo que tem os valores maiores de bytes e chamadas diff.

O show process memory platform accounting rastreia essas chamadas e bytes de comparação ao longo do tempo. Em alguns casos, um backtrace é incluído na parte inferior da saída desse comando. Isso é importante para os engenheiros do TAC, pois o backtrace é decodificado com ferramentas internas e ajuda a determinar quais funções do código podem estar causando um vazamento de memória potencial.

Note: A depuração adicional de um processo é frequentemente necessária se o comando show process memory platform accounting não fornecer informações suficientes para solucionar um problema de vazamento de memória.

Consulte também Depurar o site de chamada a partir deste documento para obter um método secundário para identificar o site de chamada.

Processar o consumo de memória em módulos, bancos de dados e mensagens

A reunião desses comandos para um processo específico do Cisco IOS XE pode ser necessária para depurar ainda mais um vazamento de memória do processo do Cisco IOS XE:

# Allocations and frees per module
show platform software memory  
show platform software memory   bri

# Database diff and entries statistics
show platform software memory database    | ex diff:0
show platform software memory database   bri | ex _0_

# Messaging diff and entries statistics
show platform software memory messaging   | ex diff:0
show platform software memory messaging   brief | ex _0_

Essas saídas de comando complementam a investigação de um vazamento de memória causado por um processo e são frequentemente exigidas se os comandos de triagem básica inicial não fornecerem informações suficientes.

Depurar o site de chamada

Um método secundário para identificar o local de chamada é depurá-lo. Estes comandos são necessários:

debug platform software memory   alloc callsite start
show platform software memory   alloc callsite brief
debug platform software memory   alloc backtrace start  depth 10
show platform software memory   alloc backtrace

O primeiro comando habilita a depuração de alocações para os sites de chamada de um processo. Em versões posteriores, esse comando é habilitado por padrão e não afeta o serviço.

O comando show platform software memory <process> <location> alloc callsite brief fornece uma tabela que mostra os sites de chamada desse processo e as chamadas de comparação e os bytes de cada site de chamada. Por exemplo, aqui mostramos a saída do processo do Cisco IOS, mas ela pode ser coletada para qualquer outro processo:

test1# show platform software memory ios r0 alloc callsite brief
The current tracekey is   : 1#b1ba773f123f8d990fd84c82c1d0e1d3

  callsite            thread    diff_byte               diff_call   
  ----------------------------------------------------------------
  3DFF8F3C424F4004    4115      57384                   1           
  ABB2D8F932038000    4115      57360                   1           
  3869885745FC8000    4115      16960                   1           
  DF884D58A8EF0004    4115      8208                    1           
  DF884D58A8EF0008    4115      8208                    1           
  FAE69298A17B8000    4115      4243                    165         
  FAE69298A17B8001    4115      2640                    165         
  FAE69298A17B8002    4115      1958                    12   

Note: O comando show plat soft memory <process> <location> alloc callsite bri deve ser executado várias vezes ao longo do tempo até encontrar a chamada de comparação ou a coluna de bytes aumentando, pois seria um indicador de que o sistema está mantendo essa memória sem liberá-la.

Depois que o local de chamada identificado como vazamento, o comando debug platform software memory <process> <location> alloc backtrace start <callsite> depth 10 deverá ser executado para esse local de chamada. Esse comando pode ser deixado no lugar e não afeta o serviço.  

A execução do comando show plat soft memory <process> <location> alloc callsite bri novamente até ver aumentos de chamadas/bytes de comparação ainda é necessária depois de habilitar a depuração do callsite identificado, isso para rastrear as funções de alocação de código de memória para esse callsite. Mais tarde, o backtrace pode ser reunido usando show platform software memory <process> <location> alloc backtrace, por exemplo:

show platform software memory install-manager switch active R0 alloc back
  backtrace: 1#83e58872a4792de086bf7191551098d7  maroon:7FCBACB87000+4642 maroon:7FCBACB87000+579C repm_core:7FCBB1F29000+1E146 avl:7FCBB4005000+2989 repm_core:7FCBB1F29000+1DAF6 repm_core:7FCBB1F29000+1BADF repm_core:7FCBB1F29000+37BA6 repm_core:7FCBB1F29000+2A341 tdldb_assist_no_dbdm:7FCBB5EDE000+416E
  callsite: 7BD5593C00E30000, thread_id: 15556
  allocs: 70, frees: 0, call_diff: 70

Note: Forneça essa saída ao TAC para decodificar o backtrace. Em seguida, o engenheiro do TAC pode verificar o comportamento no código, determinar se há um defeito existente ou entender melhor o comportamento. Se necessário, o TAC pode entrar em contato com a equipe de desenvolvedores. 

Observação: certifique-se de que o software esteja atualizado. No caso de um novo defeito de software ser encontrado, o TAC pode trabalhar com a equipe do desenvolvedor para depurar e investigar ainda mais a condição.

Artigos e documentação relacionados

• Guia de solução de problemas de memória do roteador ASR 1000 Series
• Examinar o uso da memória do IOS-XE
• Relatar problemas de utilização de memória via EEM
• Guia de Troubleshooting de Memória para ISRs Cisco 4000 Series