Table des matières

Introduction

Aperçu

Journaux/vérifications de base

Contrôles de base

Journaux

Analyse

plan d'action

Scénario 1. Utilisation élevée de la mémoire

Scénario 2. En raison d'une utilisation CPU élevée

Introduction

Ce document décrit comment dépanner sessmgr ou aamgr qui sont dans l'état "warn" ou "over".

Aperçu

Gestionnaire de session (Sessmgr) : système de traitement des abonnés qui prend en charge plusieurs types de session et qui est chargé de gérer les transactions des abonnés. Sessmgr est généralement associé à AAAManagers.

Gestionnaire d'autorisations, d'authentification et de comptabilité (Aamgr) : est responsable de l'exécution de toutes les opérations et fonctions du protocole AAA pour les abonnés et les utilisateurs administratifs du système.

Figure 1 : Distribution des ressources Staros

Journaux/vérifications de base

Contrôles de base

Pour obtenir plus de détails sur le problème, vous devez vérifier ces informations avec l'utilisateur :

1. Depuis combien de temps le sessmgr/aamgr est-il à l'état « warn » ou « over » ?

2. Combien de sessmgrs/aamgrs sont concernés par ce problème ?

3. Vous devez confirmer si sessmgr/aamgr est dans l'état "warn" ou "over" en raison de la mémoire ou du CPU.

4. Vous devez également vérifier s'il y a eu une augmentation soudaine du trafic, qui peut être évaluée en examinant le nombre de sessions par sessmgr.

En obtenant ces renseignements, vous pourrez mieux comprendre et régler le problème en question.

Journaux

1. Procurez-vous Show Support Details (SSD) et syslogs pour capturer l'horodatage problématique. Il est recommandé de collecter ces journaux au moins 2 heures avant l'apparition du problème afin d'identifier le point de déclenchement.

2. Capturez les fichiers de base pour les sessmgr/aamgr problématiques et non problématiques. Vous trouverez plus d'informations à ce sujet dans la section Analyse.

Analyse

Étape 1. Pour vérifier l'état des commandes sessmgr/aamgr affectées.

show task resources         -

--------- to check detail of sessmgr/aamgr into warn/over state and from the same you also get to know current memory/cpu utlization

Output ::

******** show task resources *******

Monday May 29 08:30:54 IST 2023

task          cputime      memory         files      sessions

cpu facility inst used  alloc used alloc    used allc    used allc   S   status

----------------------- ----------- ------------- --------- ------------- ------

2/0 sessmgr  297  6.48% 100% 604.8M 900.0M  210 500     1651 12000   I     good

2/0 sessmgr  300  5.66% 100% 603.0M 900.0M  224 500     1652 12000   I     good

2/1 aaamgr   155  0.90% 95%  96.39M 260.0M   21 500     -- --        -     good

2/1 aaamgr   170  0.89% 95%  96.46M 260.0M   21 500     -- --        -     good

Remarque : le nombre de sessions par sessmgr peut être vérifié par cette commande comme indiqué dans le résultat de la commande.

Ces deux commandes aident à vérifier l'utilisation maximale de la mémoire depuis le rechargement du noeud :

show task resources max

show task memory max

******** show task memory max *******

Monday May 29 08:30:53 IST 2023

task   heap     physical                     virtual

cpu facility inst   max          max     alloc           max    alloc status

----------------------- ------ ------------------ ------------------ ------

2/0 sessmgr  902   548.6M   66% 602.6M  900.0M     29%  1.19G    4.00G good

2/0 aaamgr   913   68.06M   38% 99.11M  260.0M     17%  713.0M   4.00G good

Remarque : la commande memory max indique la mémoire maximale utilisée depuis le rechargement du noeud. Cette commande nous aide à identifier les modèles liés au problème, par exemple si le problème a commencé après un rechargement récent ou s'il y a eu un rechargement récent qui nous permet de vérifier la valeur de mémoire maximale. D'un autre côté, « show task resources » et « show task resources max » fournissent des résultats similaires, à la différence que la commande max affiche les valeurs maximales de mémoire, de CPU et de sessions utilisées par un sessmgr/aamgr spécifique depuis le rechargement.

show subscriber summary apn <apn name> smgr-instance <instance ID> | grep Total

-------------- to check no of subscribers for that particular APN in sessmg

plan d'action

Scénario 1. Utilisation élevée de la mémoire

1. Collectez SSD avant de redémarrer/tuer l'instance sessmgr.

2. Collectez le vidage de mémoire pour l'un des sessmgr affectés.

task core facility sessmgr instance <instance-value>

3. Collectez la sortie du tas à l'aide de ces commandes en mode masqué pour les mêmes sessmgr et aamgr affectés.

show session subsystem facility sessmgr instance <instance-value> debug-info verbose

show task resources facility sessmgr instance <instance-value>

Heap outputs:

show messenger proclet facility sessmgr instance <instance-value> heap depth 9

show messenger proclet facility sessmgr instance <instance-value> system heap depth 9

show messenger proclet facility sessmgr instance <instance-value> heap

show messenger proclet facility sessmgr instance <instance-value> system

show snx sessmgr instance <instance-value> memory ldbuf

show snx sessmgr instance <instance-value> memory mblk

4. Redémarrez la tâche sessmgr à l'aide de la commande suivante :

task kill facility sessmgr instance <instance-value>

Attention : si plusieurs sessmgrs sont à l'état « avertir » ou « sur », il est recommandé de les redémarrer avec un intervalle de 2 à 5 minutes. Commencez par redémarrer seulement 2 à 3 sessmgrs, puis attendez jusqu'à 10 à 15 minutes pour voir si ces sessmgrs reviennent à l'état normal. Cette étape permet d'évaluer l'impact du redémarrage et de surveiller la progression de la restauration.

5. Vérifiez l'état du sessmgr.

show task resources facility sessmgr instance <instance-value> -------- to check if sessmgr is back in good state

6. Collectez un autre SSD.

7. Collectez le résultat de toutes les commandes CLI mentionnées à l’étape 3.

8. Collectez le vidage de mémoire pour toutes les instances sessmgr saines à l'aide de la commande mentionnée à l'étape 2.

Remarque : Pour obtenir des fichiers de base pour les installations problématiques et non problématiques, vous avez deux options. Premièrement, vous pouvez collecter le fichier de base du même sessmgr après son retour à la normale après un redémarrage. Vous pouvez également capturer le fichier de base à partir d'un autre sessmgr sain. Ces deux approches fournissent des informations précieuses pour l'analyse et le dépannage.

Une fois que vous avez collecté les sorties de tas, veuillez contacter le TAC Cisco pour trouver le tableau exact de consommation de tas.

À partir de ces sorties de tas, vous devez vérifier la fonction qui utilise plus de mémoire. Sur cette base, le TAC étudie le but prévu de l'utilisation des fonctions et détermine si son utilisation correspond à l'augmentation du trafic/volume de transactions ou à toute autre raison problématique.

Les sorties de tas peuvent être triées en utilisant un outil accessible par le lien donné comme Memory-CPU-data-sorting-tool.

Remarque : cet outil propose plusieurs options pour les différentes installations. Cependant, vous devez sélectionner "Table de consommation de tas" où vous téléchargez des sorties de tas et exécutez l'outil pour obtenir la sortie dans un format trié.

Scénario 2. En raison d'une utilisation CPU élevée

1. Collectez SSD avant de redémarrer ou de tuer l'instance sessmgr.

2. Collectez le vidage de mémoire pour l'un des sessmgr affectés.

task core facility sessmgr instance <instance-value>

3. Collectez la sortie de tas de ces commandes en mode masqué pour le même sessmgr/aamgr affecté.

show session subsystem facility sessmgr instance <instance-value> debug-info verbose

show task resources facility sessmgr instance <instance-value>

show cpu table

show cpu utilization

show cpu info ------ Display detailed info of CPU.

show cpu info verbose ------ More detailed version of the above

Profiler output for CPU

This is the background cpu profiler. This command allows checking which functions consume

the most CPU time. This command requires CLI test command password.

show profile facility <facility instance> instance <instance ID> depth 4

show profile facility <facility instance> active facility <facility instance> depth 8

4. Redémarrez la tâche sessmgr avec cette commande :

task kill facility sessmgr instance <instance-value>

5. Vérifiez l'état du sessmgr.

show task resources facility sessmgr instance <instance-value> -------- to check if sessmgr is back in good state

6. Collectez un autre SSD.

7. Collectez le résultat de toutes les commandes CLI mentionnées à l’étape 3.

8. Collectez le vidage de mémoire pour toutes les instances sessmgr saines à l'aide de la commande mentionnée à l'étape 2.

Pour analyser les scénarios de mémoire élevée et de CPU, examinez les statistiques groupées afin de déterminer s'il y a une augmentation légitime des tendances de trafic.

En outre, vérifiez les statistiques de volume pour les statistiques de niveau carte/processeur.