Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
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
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.
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 :
Exemple :
Cette commande définit le nombre maximal de flux 200000 pour la base de règles :
flow limit-across-applications 200000