Logiciels Cisco IOS et NX-OS : Cisco IOS 15.1M&T

Les erreurs MALLOCFAIL et les problèmes de mémoire généraux dépannent

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document discute des erreurs MALLOCFAIL sur le Cisco IOS® indigène, aussi bien que des étapes pour prendre et des informations à recueillir avant que vous ouvriez une valise du centre d'assistance technique Cisco (TAC) ou rechargiez le périphérique afin d'accélérer la résolution des problèmes. Ce document n'est pas exhaustif, mais fournit une recommandation générale utilisée afin de dépanner des questions de mémoire avec beaucoup de Routeurs et de Commutateurs.

Contribué par Brandon Lynch, ingénieur TAC Cisco.

Erreurs MALLOCFAIL

Les problèmes de mémoire se manifestent de plusieurs manières sur des Commutateurs et des Routeurs. Dans de nombreux cas, un périphérique qui éprouve des erreurs de mémoire est rechargé avant que les données appropriées soient recueillies.

Les numéros de mémoire apparaissent généralement sous forme d'erreurs MALLOCFAIL dans les logs de votre routeur ou commutateur. Ces erreurs sont importantes parce qu'elles fournissent des « panneaux routiers » de diriger l'enquête. Voici une erreur de l'échantillon MALLOCFAIL :

%SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed
from 0x60103098,
alignment 0
Pool: Processor  Free: 5453728  Cause: Memory fragmentation
Alternate Pool: None  Free: 0  Cause: No Alternate pool

La première chose à noter est combien la mémoire vous doit allouer et combien de mémoire disponible vous avez. Cet exemple affiche à un scénario où vous devez allouer 65KB d'un groupe qui a seulement approximativement 5.45MB libre. La sortie indique que, quoiqu'il y ait assez de mémoire disponible, le plus grand bloc contigu est plus petit que 65KB, et l'allocation de mémoire a manqué. Tandis que, par définition, ceci est considéré fragmentation de mémoire, ce n'est pas habituellement la cause. Le plus souvent, il est simplement provoqué par la mémoire basse dans le groupe elle-même.

La deuxième chose à noter est le type de groupe. L'exemple de prevoius eu affaire avec le pool de processeurs. C'est important parce que c'est le premier panneau routier qui dirige l'enquête et les quels besoins d'être vérifié. Le groupe spécifié devrait être processeur ou E/S. Voici un exemple d'une erreur de mémoire E/S :

%SYS-2-MALLOCFAIL: Memory allocation of 65548 bytes failed from 0x400B8564, 
alignment 32
Pool: I/O  Free: 39696  Cause: Not enough free memory
Alternate Pool: None  Free: 0  Cause: No Alternate pool

Les sections suivantes affectent ces groupes en outre. Une fois le groupe est identifié, vous peut focaliser vos efforts en conséquence dans les zones droites.

Pool de processeurs

Le pool de processeurs est utilisé, pendant que le nom implique, pour les divers processus qui fonctionnent sur le routeur ou le commutateur. Il y a des processus spécifiques qui sont à la base de la plupart des versions et Plateformes de Cisco IOS qui utilisent la mémoire. Par exemple, Init est un processus établi sur l'amorce de la plupart des périphériques, et est présent à travers de diverses Plateformes. D'autres processus qui pourraient être présent sont basés sur la configuration du périphérique individuel. Par exemple, sur des Plateformes dans lequel exprimez est configuré et utilisé, des processus de Voix-particularité consomment la mémoire, alors que dans des configurations plus généralisées sans Voix, ces processus ne tiennent pas autant, ou n'importe quelle mémoire du tout.

Certains processus tiennent plus de mémoire que d'autres. S'il y a des questions ou préoccupations au sujet d'un processus particulier, il est le meilleur d'ouvrir une valise TAC pour la faire étudier.

Causes et ce qui à collecter

  1. Si le périphérique a récemment subi une mise à jour de Cisco IOS, la première chose à vérifier est la mémoire vive dynamique exigée minimum pour la nouvelle image. Ceci devrait être égal ou moins qu'à la quantité de mémoire vive dynamique installée sur le périphérique lui-même. La mémoire vive dynamique exigée minimum est répertoriée sous l'image dans l'outil de téléchargement logiciel. Sélectionnez la commande de show version afin de confirmer la quantité de mémoire vive dynamique installée :
    Cisco 2821 (revision 53.51) with 210944K/51200K bytes of memory.

    Afin de déterminer la DRAM totale, ajoutez ces nombres. Ce routeur de Cisco de détail a 256MB de mémoire vive dynamique.

  2. Une autre cause possible est une fuite de mémoire provoquée par une bogue de Cisco IOS. Dans cette situation, un processus consomme une quantité excessive de mémoire jusqu'à ce qu'il s'épuise. Sélectionnez ces commandes quand la mémoire est basse afin de collecter des informations :
    show clock
    show mem stat
    show proc mem sorted
    show mem all totals
    show log

    Les listes de commandes triées par mem de show proc tous les processus dans l'ordre décroissant de la quantité de mémoire la plus élevée tenue au plus bas. Identifiez le processus le plus élevé, mais excluez Init. Une fois que l'enquête est complète, trouvez l'ID de processus (PID) pour ce processus du côté gauche de la sortie, et collectez ces informations :
    show proc mem <PID #>

    Si le processus le plus élevé est mort, collectez ces informations en plus des sorties précédentes :
    show mem dead totals
    show mem dead

    Certains processus exigent une enquête plus en profondeur, mais ils ne sont pas couverts dans ce document.

  3. Une autre cause potentielle des questions de mémoire est produite quand vous manquez de mémoire due aux processus et à la configuration sur le périphérique. Un exemple de ceci est le routeur de Protocole BGP (Border Gateway Protocol). Parfois, le BGP tient un grand nombre de mémoire en raison du nombre d'artères qu'il rentre. Ceci n'est pas provoqué par une bogue de Cisco IOS. Ce problème doit être corrigé en modifiant la configuration afin de réaliser le routage optimal et réduire la consommation de mémoire.

    Si vous êtes incertain, collectez les sorties répertoriées précédemment (excluez les totaux morts de mem d'exposition et affichez les morts de mem), et ouvrez une valise TAC, parce que ce problème exigera probablement des recherches plus approfondies.

Groupe E/S

Le groupe E/S se réfère aux mémoires tampons E/S vues avec la commande de shows buffer. Ces mémoires tampons sont utilisées pour le trafic commuté par processus, notamment, comme des mises à jour de routage ou des émissions. La mémoire E/S est décomposée en groupes, qui sont affichés dans la sortie de commande de shows buffer. Ces groupes sont basés sur la longueur de paquet, qui permet une allocation plus efficace de mémoire basée sur les besoins.

Causes et ce qui à collecter

  1. La première chose à vérifier avec des questions de mémoire E/S est une fuite potentielle de mémoire tampon provoquée par une bogue de Cisco IOS. Ceci se manifeste souvent en tant que groupe particulier qui augmente sa quantité de mémoires tampons sans les libérer de nouveau dans le groupe E/S une fois qu'elles ne sont nécessaires plus. Voici un exemple de ceci :
     --------- show buffers --------

    Buffer elements:
         500 in free list (500 max allowed)
         3220350364 hits, 0 misses, 0 created

    Public buffer pools:
    Small buffers, 104 bytes (total 6144, permanent 6144):
         3867 in free list (2048 min, 8192 max allowed)
         248913132 hits, 0 misses, 0 trims, 0 created
         0 failures (0 no memory)
    Medium buffers, 256 bytes (total 86401, permanent 3000, peak 86401 @ 05:18:11):
         0 in free list (64 min, 3000 max allowed)
         9697361 hits, 203293 misses, 2208 trims, 85609 created
         167633 failures (651288 no memory)
    Middle buffers, 600 bytes (total 512, permanent 512):
         0 in free list (64 min, 1024 max allowed)
         9284431 hits, 237750 misses, 0 trims, 0 created
         224619 failures (680486 no memory)
    Big buffers, 1536 bytes (total 1000, permanent 1000):
         0 in free list (64 min, 1000 max allowed)
         69471745 hits, 895218 misses, 0 trims, 0 created
         842142 failures (1821074 no memory)
    VeryBig buffers, 4520 bytes (total 10, permanent 10, peak 122 @ 1w3d):
         0 in free list (0 min, 100 max allowed)
         2120517 hits, 1632477 misses, 112 trims, 112 created
         1632421 failures (3272987 no memory)
    Large buffers, 9240 bytes (total 8, permanent 8, peak 18 @ 1w3d):
         0 in free list (0 min, 10 max allowed)
         9593 hits, 832217 misses, 44 trims, 44 created
         832195 failures (1651309 no memory)
    Huge buffers, 18024 bytes (total 2, permanent 2):
         0 in free list (0 min, 4 max allowed)
         1325 hits, 831497 misses, 0 trims, 0 created
         831494 failures (1649904 no memory)

    La sortie précédente prouve clairement que le problème est avec le groupe moyen. Sa valeur totale est beaucoup de supérieur à que la quantité permanente a placé pour ce groupe. La sortie prouve que, même avec plus de 86,000 mémoires tampons dans le groupe, vous avez 0 disponible dans la liste libre. En conclusion, la sortie prouve que le nombre d'équilibres est beaucoup inférieur au nombre créé, qui indique que ceux-ci n'ont pas été libérés de nouveau dans le groupe E/S pour davantage de consommation. Pour davantage d'explication de ces champs, voyez les définitions pour des champs de pool de mémoire tampon joindre dans la section Informations connexes à la fin de ce document.

    Pour ce scénario, saisissez d'abord ces sorties :
    show clock
    show mem stat
    show buffers
    show log

    Une fois le groupe ou les groupes problématiques sont déterminés, sélectionnent cette commande afin de se concentrer sur les groupes de problème :
    show buffer pool <pool name> packet

    Cette commande pourrait fournir la sortie étendue. Vous pouvez habituellement déterminer quels paquets résident dans ces mémoires tampons et qui les a allouées dans quelques pages de la sortie.

  2. Une autre cause possible est un événement de réseau/trafic. Ceci se manifeste souvent en tant qu'utilisation excessive dans les plusieurs pools. L'il est recommandé que les sorties précédentes soit collecté, avec la sortie de commande de paquet de name> de <pool de groupe de show buffer pour les groupes qui affichent cette utilisation, et qui vous ouvrez une valise TAC. Ceci est souvent provoqué par une circulation anormale ou inattendue qui doit être commutée par processus par le périphérique. Puisque l'écoulement pourrait être bursty et rapide, vous pouvez manquer de mémoire E/S dans relativement une courte période. Afin de dépanner ce type de problème, habituellement vous devez identifier la source de trafic afin de voir si cet écoulement est anormal et, si oui, l'élimine ou bloque.

  3. Un autre, un événement plus rare est qu'un groupe spécifique davantage lourd-est utilisé en raison de certain trafic qui est nécessaire dans un environnement de réseau. Ce trafic pourrait, pour quelque raison, devoir être commuté par processus, et il n'y a aucune manière d'éviter ceci dans le réseau. Ce scénario doit être confirmé plus loin, et alors la mesure appropriée doit être prise. Les mêmes sorties de l'étape 1 s'appliquent ici.

Éléments à étudier

Sur la plupart des Routeurs, les exemple d'erreur MALLOCFAIL présentés précédemment sont standard. Sur le Commutateurs de la gamme Cisco Catalyst 6500 et les Routeurs de gamme 7600 avec les engines de superviseur (SUP) ou le processeur de commutation routage (RSPs), ces erreurs pourraient varier. Par exemple, cette erreur a été prise du processeur d'artère (RP) ouvre une session une gamme 6500 commutent :

%SYS-SP-2-MALLOCFAIL: Memory allocation of 820 bytes failed from 0x40C83B60,
alignment 32
Pool: I/O  Free: 48  Cause: Not enough free memory
Alternate Pool: None  Free: 0  Cause: No Alternate pool

L'erreur MALLOCFAIL prouve que le processeur de commutateur (fournisseur de services) de la PETITE GORGÉE signale le problème, pas le RP. Si le problème est associé avec le RP, la désignation de fournisseur de services dans l'erreur n'est pas présente. Pour cette raison, les sorties précédentes doivent être prises des ESPÈCES afin d'accomplir ceci, précèdent les commandes avec :

remote command switch

Le message d'erreur pourrait également se rapporter au standby SUP/RSP RP ou au fournisseur de services comme dénoté par STDBY, et aux besoins d'être collecté en conséquence.

Résumé

Vous pourriez accélérer la résolution de cas et apporter la stabilité à votre périphérique plus rapidement si vous collectez les sorties répertoriées dans ce document. Si des questions se posent ou s'il y a incertitude au sujet de représentation de mémoire sur un périphérique, il est le meilleur d'ouvrir une valise TAC afin de la faire étudier.

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 116467