Solución de problemas de memoria en IOS XE a través de Callsite

Introducción

Este documento describe cómo resolver problemas de memoria en dispositivos basados en Cisco IOS® XE como routers y switches para un sitio de llamada con fugas.

Prerequisites

Conocimiento de la gestión de memoria en dispositivos basados en el software Cisco IOS XE.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware. Se aplica a las plataformas basadas en el software Cisco IOS XE de routing y switching.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Supervisar el uso de la memoria de producción del dispositivo para los incrementos delta y confirmar si se espera que lleve mucho tiempo. Este documento explica qué es un sitio de llamada y cómo ayuda a resolver problemas de memoria rápidamente.

Nota: Este documento se centra principalmente en la resolución de problemas de uso de memoria de acceso aleatorio dinámico (DRAM) del procesador de routing.

¿Qué es el sitio de llamadas?

El sitio de llamada es una etiqueta que utiliza Cisco Technical Assistance Center (TAC) para verificar y realizar un seguimiento de las funciones de código fuente a las que se llama durante las asignaciones de memoria realizadas por los procesos relacionados con Cisco IOS-XE.

Los clientes pueden proporcionar esta etiqueta antes de abrir un caso del TAC para una resolución más rápida y también pueden ayudar en la depuración mediante los comandos presentados más adelante en este artículo.

Llamadas diff y bytes diff

Las llamadas diff supervisan la disparidad entre el número de llamadas para asignaciones de memoria y desasignaciones. Normalmente, un volumen alto de llamadas diff puede significar un problema relacionado con la memoria. Esto ocurre cuando hay cantidades excesivas de diferencias, lo que indica que el sistema no está liberando memoria y que las asignaciones se están acumulando.

Tanto las llamadas diff como los bytes diff se pueden ver con 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  
  

El sistema tiene umbrales de uso de memoria interna que activan advertencias de memoria y registros del sistema de nivel crítico. El porcentaje de uso de memoria basado en estos umbrales se puede ver usando el 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#

Nota: Presente un caso TAC para determinar si las llamadas diff o bytes diff están preocupados por un proceso determinado. Por lo general, si hay poca memoria libre del sistema como se ve con el comando show processes memory platform sorted, vale la pena verificar más.

Síntomas de consumo de memoria o problemas de fuga

Cuando hay un consumo de memoria o un problema de pérdida en el lado de Cisco IOS XE, generalmente se genera una alarma de advertencia o crítica, como por ejemplo:

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).

Este tipo de alarma resalta información valiosa como punto de partida para la resolución de problemas:

• Fecha y hora de la alarma recibida
• Porcentaje de uso
• Componente afectado
• Los principales procesos de Cisco IOS XE que el sistema detectó como principales consumidores en función de las llamadas de diferencia.

Nota: La alarma %PLATFORM-4-ELEMENT_WARNING no es necesariamente un punto de datos concluyente para obtener el análisis de causa raíz (RCA) de un problema de consumo de memoria.

Nota: Existen otros tipos de síntomas y alarmas de uso de memoria asociados a diferentes componentes como Temporal File System (TMPFS), Quantum Flow Processor (QFP) y Cisco IOS daemon (IOSd); sin embargo, estos están fuera del alcance de este documento. 

Nota: Este documento no cubre la solución de problemas de mensajes syslog SYS-2-MALLOCFAIL que indican problemas de memoria en el daemon de Cisco IOS (IOSd).

Escenarios de resolución de problemas

El dispositivo se ha estrellado debido a un agotamiento de la memoria

Cuando el dispositivo se bloquea debido a recursos sin memoria, es importante verificar los últimos registros antes del bloqueo para confirmar y ver si el mensaje de syslog %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: El valor de memoria usada X% excede el nivel de advertencia Y% está presente.

Nota: Tenga en cuenta que los registros del sistema del búfer DRAM local se borran después de un desperfecto debido a la falta de memoria; por lo tanto, se necesitan registros de archivo del servidor syslog antes del evento de desperfecto. Si el servidor syslog aún no está configurado, consulte Cómo configurar el registro en Cisco IOS. 

Nota: %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: El valor de memoria usada X% excede el nivel de advertencia Y% de alarma después de un evento de desperfecto también se puede ver en los registros de seguimiento decodificados del IOS de Cisco. Consulte Recopilación y administración de registros de seguimiento con Unified Logging Enhancement para obtener más información.

Debido a la memoria insuficiente, el sistema sufrió una caída. En consecuencia, se genera un informe del sistema. Este informe es un archivo .tar.gz que contiene los datos pertinentes que se pueden utilizar para investigar el problema de memoria. Para obtener más información, consulte Resolución de problemas mediante informes del sistema.

Cuando se descomprime, el informe del sistema contiene un directorio llamado maroon stats dentro del directorio tmp. Las estadísticas maroon son una facilidad de mantenimiento implementada en el código que rastrea las asignaciones de memoria y las asignaciones de memoria en llamadas diff y bytes para diferentes procesos de Cisco IOS XE.

La instantánea de estadísticas granujas contiene dentro del informe del sistema, ayuda a identificar un sitio de llamada de un posible culpable para determinar el consumo de memoria o problema de fuga RCA o depurarlo más y comprenderlo mejor.

Nota: La descodificación del directorio de estadísticas granujas de un informe del sistema sólo puede realizarla el TAC, ya que contiene funciones internas y confidenciales de código que ayudan al ingeniero del TAC a comprender qué funciones de código están asignando la memoria. Envíe un caso del TAC y proporcione el informe del sistema.

Nota: Tenga en cuenta que el informe del sistema proporciona una buena cantidad de datos para comprender una caída de memoria debido a la falta de memoria; sin embargo, en algunos casos, se necesita más seguimiento de la memoria, supervisión, depuración y solución de problemas.

El dispositivo aún no se ha estrellado pero tiene advertencias de uso de memoria

El comando show platform resources muestra umbrales de uso de memoria críticos y de advertencia. 

Nota: Se recomienda recopilar comandos de salida relacionados con la memoria para depurar aún más, ya que, en función de la velocidad a la que se produzca el consumo o la pérdida de memoria, el dispositivo puede correr el riesgo de sufrir un fallo debido a que se agotan los recursos de memoria. 

Nota: Cuando se observan advertencias de uso de memoria, puede archivar un caso TAC y proporcionar comandos show tech-support y 

show tech-support memory que ayuda al ingeniero del TAC a resolver inicialmente el problema y potencialmente encontrar un RCA rápidamente.

Cuando el dispositivo aún no se ha estrellado y está generando las alarmas de memoria en el buffer syslog local o recibidas del servidor syslog a través de la herramienta de monitoreo, recopile el resultado de show processes memory platform sorted para determinar los bytes consumidos por el proceso ofensivo, si los hubiera.

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  

En esta salida, observe la columna Tamaño del conjunto residente (RSS). Este es un indicador de cuántos kilobytes consume cada proceso de Cisco IOS XE.

Identificar el sitio de llamada

A continuación, recopile el resultado de show processes memory platform accounting que muestra los valores de llamadas y bytes de diferencia para los diferentes procesos. Por lo general, nos centramos en los valores más grandes. 

El comando diff call bytes es un buen indicador para determinar si puede haber una pérdida potencial de memoria, ya que muestra cuántos bytes de memoria aún están retenidos por el sistema por un proceso sin ser liberados de nuevo al sistema.

En función de estos datos, puede identificar cuál es la etiqueta callsite del proceso infractor que tiene los valores de bytes y llamadas diff más grandes.

El comando show process memory platform accounting rastrea estas llamadas y bytes diff a lo largo del tiempo. En algunos casos, se incluye una traza inversa en la parte inferior de este resultado de comando. Esto es importante para el ingeniero del TAC, ya que dicha traza inversa se descodifica mediante herramientas internas y ayuda a determinar qué funciones de código pueden provocar una posible pérdida de memoria.

Nota: A menudo se necesita más depuración para un proceso si el comando show process memory platform accounting no proporciona suficiente información para resolver un problema de pérdida de memoria.

Vea también Depurar el sitio de llamada de este documento para obtener un método secundario para identificar el sitio de llamada.

Consumo de memoria de proceso en módulos, bases de datos y mensajería

Puede ser necesario recopilar estos comandos para un proceso específico de Cisco IOS XE para depurar aún más una fuga de memoria del proceso de 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_

Estos resultados de comandos complementan la investigación de una pérdida de memoria causada por un proceso y a menudo son necesarios si los comandos de triage básicos iniciales no proporcionan suficiente información.

Depurar el sitio de llamada

Un método secundario para identificar el sitio de llamada es depurarlo. Estos comandos son obligatorios:

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

El primer comando habilita la depuración de asignaciones para los sitios de llamadas de un proceso. En versiones posteriores, este comando está habilitado de forma predeterminada y no afecta al servicio.

El comando show platform software memory <process> <location> alloc callsite brief proporciona una tabla que muestra los sitios de llamada para ese proceso y las llamadas y bytes diff para cada sitio de llamada. Por ejemplo, aquí mostramos el resultado del proceso del IOS de Cisco, pero se puede recopilar para cualquier otro proceso:

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   

Nota: El comando show plat soft memory <process> <location> alloc callsite bri debe ejecutarse varias veces en el tiempo hasta que se encuentre la columna diff call o bytes incrementándose, ya que sería un indicador de que el sistema está manteniendo dicha memoria sin liberarla.

Una vez que se ha identificado la fuga del sitio de llamada, el comando debug platform software memory <process> <location> alloc backtrace start <callsite> depth 10 debe ejecutarse para ese sitio de llamada. Este comando se puede dejar en su lugar y no afecta al servicio.  

Aún es necesario ejecutar el comando show plat soft memory <process> <location> alloc callsite bri nuevamente hasta ver aumentos de llamadas/bytes diff después de habilitar la depuración del sitio de llamada identificado, esto para realizar un seguimiento de las funciones de asignación de memoria de código para ese sitio de llamada. Más adelante, la traza inversa se puede recopilar mediante show platform software memory <process> <location> alloc backtrace, por ejemplo:

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

Nota: Proporcione este resultado al TAC para descodificar la referencia inversa y, a continuación, el ingeniero del TAC puede verificar el comportamiento en el código, determinar si existe un defecto o comprender mejor el comportamiento. Si es necesario, el TAC puede ponerse en contacto con el equipo de desarrolladores. 

Nota: Asegúrese de tener el software actualizado. En caso de que se encuentre un nuevo defecto de software, el TAC puede trabajar con el equipo de desarrolladores para depurar e investigar la condición.

Artículos y documentación relacionados

• Guía de resolución de problemas de memoria del router serie ASR 1000
• Examine el uso de la memoria IOS-XE
• Informe de problemas de uso de memoria mediante EEM
• Guía de resolución de problemas de memoria para ISR de Cisco serie 4000