Introduction
Ce document décrit le problème sur sessmgr qui passe à l'état WARN en raison d'un grand nombre de flux HTTP. Ce problème est signalé sur les routeurs à services agrégés Cisco (ASR) 5x00.
Problème
L'état de Sessmgr est WARN et utilisation élevée de la mémoire.
******** show task resources *******
Thursday July 24 17:44:58 IST 2014
task cputime memory files sessions
cpu facility inst used allc used alloc used allc used allc S status
----------------------- --------- ------------- --------- ------------- ------
4/0 sessmgr 3 26% 100% 1.86G 1.86G 34 500 1766 28160 I warn
Ces journaux d'erreurs sont générés dans le processus.Aucun impact sur l'abonné n'est dû à ce journal d'erreurs. Selon la conception, une fois l'appel rejeté de sessmgr qui est en état WARN, le système essaie à différentes sessions et l'appel passe.
[sessmgr 10018 error] [4/0/6812 <sessmgr:3> sessmgr_func.c:44683] [software internal system syslog] Sessmgr-3 full (35200 effective number of calls, 1777 calllines in use, 51146 free flows, 31221 free aaa_sessions, 1777 used-mem-credits, 1777 used-sess-credits, 1948360 mem-usage, 1945600 mem-limit, 0 ecs-queue-usage, 70400 ecs-queue-limit, 16850 ecs-num-flows, 400000 ecs-max-flows, 2334720 ecs-mem-limit[ecs-flow/mem-values:valid], 0x86 limit-flags) - call rejected
Dépannage
Capturez show support details output et vérifiez les sorties de la commande pour dépanner plus loin.
Le problème de mémoire est lié à la quantité de flux que sessmgr gère. La corrélation peut être vue entre sessmgr ayant une consommation élevée de mémoire et une grande quantité de flux.
******** debug acsmgr show memory usage *******
Thursday July 24 17:50:06 IST 2014
------------------------------------------------------------------------------
! ! Caches Count !
Instance Memory ! Flows ! Callline Data-Session TCP OOO !
! Current Max ! Total Free Total Free Total Free!
--------------------------------------------------------------------------------
1 865.68M 43365 64360 5500 1178 56140 12775 1102 1064
2 852.05M 43879 64767 5500 1178 60150 16271 1102 1067
3 1902.68M 17252 276519 4400 2631 44110 26858 551 541
Pour les sessions affectées (et pour une non affectée), collectez ces sorties de commande, où x est l'instance de Sessmgr.
show messenger proclet facility sessmgr instance <x> heap
show messenger proclet facility sessmgr instance <x> system heap
task core facility sessmgr instance <x>
show active-charging flows instance <x>
show profile facility sessmgr active depth 8 head 201
show task resources faciltity sessmgr instance <x> max
Vérifiez si les règles non optimisées et le groupe de règles consomment beaucoup de mémoire.
debug acsmgr show rule-optimization-information
debug acsmgr show grp-of-rdef-optimization-information
La consommation de mémoire la plus élevée est due à ces fonctions en fonction des sorties de commande.
acs_http_pkt_inspection()
acsmgr_alloc_buffer()
snx_add_dbufs()
sn_aaa_alloc_session_block()
sgx_imsa_bind_user()
Vous pouvez également vérifier le nombre maximal de flux HTTP simultanés atteint par les lignes d'appel
******** debug acsmgr show flow-stats max-simultaneous-flows http *******
Thursday July 24 17:50:04 IST 2014
Histogram of Max No of Simultaneous HTTP Flows attained by Calllines
No Of Flows No Of Calllines
1 to 10 964712518
11 to 20 384105002
21 to 40 232987189
41 to 100 148938918
101 to 200 115919586
201 to 500 86729303
501 to 1000 69975385
1001 to 2000 59635906
2001 to 5000 50743511
5001 to 10000 44566999
> 10000 1044671491
******** debug acsmgr show flow-stats cumulative http *******
Thursday July 24 17:50:03 IST 2014
Histogram of Total Cumulative HTTP Flows by Calllines
No Of Flows No Of Calllines
1 to 10 964712485
11 to 20 384104980
21 to 40 232987175
41 to 100 148938911
101 to 200 115919583
201 to 500 86729297
501 to 1000 69975377
1001 to 2000 59635907
2001 to 5000 50743509
5001 to 10000 44567004
> 10000 1044671452
Vous pouvez conclure qu'il y a un grand nombre de sessions HTTP allouées et cela peut être dû au trafic HTTP important. Il existe également près de 1044671491 lignes d'appel, qui ont plus de 10000 flux HTTP à la fois. Cela entraîne une utilisation élevée de la mémoire.
Solution
Vous avez l'interface de ligne de commande pour limiter le nombre de flux par abonné
flow limit-across-applications
Cisco recommande de configurer la limite de flux entre les applications à 5000 comme recommandé dans toutes les bases de règles affectées où un nombre énorme de trafic HTTP peut être vu.
Voici la procédure à suivre pour configurer la commande
In local context under Global configuration.
# active-charging service ECS
(config-acs)# rulebase GOLIVE
(config-rule-base)# flow limit-across-applications 5000
Plus d'informations sur cette commande.
flux Limiter les applications
Cette commande vous permet de limiter le nombre total de flux simultanés par Abonné/APN envoyés à une base de règles quel que soit le type de flux, ou de limiter les flux en fonction du type de protocole sous la fonction de contrôle de session.
Produit :
ACS
Privilège :
Administrateur de la sécurité, Administrateur
Mode :
Exec > ACS Configuration> Rulebase Configuration
active-charging service service_name > rulebase rulebase_name
Entering the above command sequence results in the following prompt:
[local]host_name(config-rule-base)#
Syntaxe
flow limit-across-applications { limit | non-tcp limit | tcp limit }no flow limit-across-applications [ non-tcp | tcp ] no
Si elle a été précédemment configurée, supprime la configuration de la limite de flux entre les applications de la base de règles actuelle.
flux Limite de limite entre les applications
Spécifie le nombre maximal de flux entre toutes les applications pour la base de règles.
limite doit être un entier compris entre 1 et 4000000000.
Par défaut : Aucune limite
limite non tcp
Spécifie la limite maximale des flux de type non TCP.
limite doit être un entier compris entre 1 et 4000000000.
Par défaut : Aucune limite
limite tcp
Spécifie la limite maximale des flux TCP.
limite doit être un entier compris entre 1 et 4000000000.
Par défaut : Aucune limite
Utilisation :
Utilisez cette commande pour limiter le nombre total de flux autorisés pour une base de règles quel que soit le type de flux, ou limiter les flux en fonction du protocole - non TCP (sans connexion) ou TCP (orienté connexion).
Si un abonné tente de dépasser ces limites, le système rejette les paquets du nouveau flux. Ce traitement de limite de cette commande a les aspects suivants pour UDP, TCP, ICMP et certains des flux exemptés :
- UDP/ICMP : Le système attend le délai d'attente du flux avant de mettre à jour le compteur et de le supprimer du nombre de flux.
- TCP: Après la fin d’un flux TCP, le système attend un court laps de temps pour permettre la retransmission de tout paquet manqué d’une extrémité. Les flux TCP qui sont terminés, mais qui sont toujours en période d'attente pour le délai d'attente sont exemptés pour ce traitement de limite.
- Flux exemptés : System exempte tous les autres flux spécifiés avec la commande flow limit-for-flow-type dans le mode de configuration de l'action de chargement ACS défini sur no.
Exemple :
Cette commande définit le nombre maximal de flux 200000 pour la base de règles :
flow limit-across-applications 200000