Commutateurs : Commutateurs Cisco Nexus, s�rie�5000

Commutateurs SYSMGR-2-VOLATILE_DB_FULL de gamme de Nexus 5000 : L'utilisation volatile de base de données de système est inopinément message d'erreur élevée dépannent

30 juillet 2013 - Traduction automatique
Autres versions: PDFpdf | Anglais (2 juillet 2013) | Commentaires

Introduction

Ce document décrit un problème rencontré avec des Commutateurs de gamme de Nexus 5000, et fournit également une solution et un workaround provisoire pour le problème.

Contribué par Shelley Bhalla, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance de Cisco Nexus CLI.

Composants utilisés

Les informations dans ce document sont basées sur les Commutateurs de gamme de Nexus 5000 qui exécutent n'importe quelle version plus tôt que 5.0(3)N2(1).
 
Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Problème

La gamme de Nexus 5000 commute des états cette erreur toutes les trois minutes :

N5k %SYSMGR-2-VOLATILE_DB_FULL: System volatile database usage is
 unexpectedly high at 80%.
N5k %SYSMGR-2-VOLATILE_DB_FULL: System volatile database usage is
 unexpectedly high at 80%.
N5k %SYSMGR-2-VOLATILE_DB_FULL: System volatile database usage is
 unexpectedly high at 80%.
N5k %SYSMGR-2-VOLATILE_DB_FULL: System volatile database usage is
 unexpectedly high at 80%.

Quand vous écrivez l'exposition exécutez la commande (et produisez plus de 190 lignes de sortie) ou la commande de commutateur-profil de passage d'exposition (indépendamment de la taille de sortie), une copie du fichier CSM_ACFG dans le fichier de /dev/shm pourrait se produire. Ces fichiers ne sont pas automatiquement nettoyés. Par la suite ils remplissent la mémoire volatile, qui fait recharger le périphérique. Supplémentaire, la question est aggravée si on utilise un certain tri du script qui périodiquement collecte ou modifie la configuration.

Afin de dépanner cette question, collectez d'abord la sortie de la commande instantanée interne de show system. Il devrait afficher à trafic intense dans le répertoire de /dev/shm :

N5k# show system internal flash
Mount-on                  1K-blocks      Used   Available   Use%  Filesystem
/                            204800    115408       89392     57   /dev/root
/proc                             0         0           0      0   proc
/post                          2048         4        2044      1   none
/sys                              0         0           0      0   none
/isan                       1536000    452496     1083504     30   none
/var/tmp                     307200       704      306496      1   none
/var/sysmgr                 1024000      6320     1017680      1   none
/var/sysmgr/ftp              409600     48604      360996     12   none
/var/sysmgr/ftp/cores        102400         0      102400      0   none
/callhome                     61440         0       61440      0   none
/dev/shm                     524288    427248       97040     80   none  <<<<<<<<<
/volatile                    153600         0      153600      0   none
/debug                        20480         4       20476      1   none
/dev/mqueue                       0         0           0      0   none
/mnt/cfg/0                   114909      4904      104072      5   /dev/sda5
/mnt/cfg/1                   112920      4904      102186      5   /dev/sda6
/var/sysmgr/startup-cfg      307200      9940      297260      4   none
/dev/pts                          0         0           0      0   devpts
/mnt/plog                     56192      1644       54548      3   /dev/mtdblock2
/mnt/pss                     114917      5348      103635      5   /dev/sda4
/bootflash                  1609984    410536     1117664     27   /dev/sda3

Afin de confirmer que le contenu dans le répertoire de /dev/shm est les fichiers de csm_acfg, collectez la sortie de ces commandes :

  • dir interne /dev/shm de show system | csm_acfg i | compte
  • dir interne /dev/shm de show system | csm_acfg i

Si la gamme de Nexus 5000 commute des crash, il signale ce message comme une raison de recharge dans la sortie de commande de show system reset-reason :

Reason: Reset triggered due to HA policy of Reset
System version: 5.0(2)N2(1)
Service: syslogd hap reset

Quand la commande de show logging nvram est sélectionnée, la sortie affiche des erreurs comme :

N5k %$ VDC-1 %$ %PSS-0-PSS_WRITE_LOG_FAILURE: snmpd: failed to write log: No space left on device
N5k %$ VDC-1 %$ last message repeated 4 times

Solution

Mise à jour à la version 5.0(3)N2(1) afin de résoudre ce problème. Pour plus d'informations sur cette question, ID de bogue Cisco CSCtn71292 de référence.

Supplémentaire, comme contournement provisoire :

  • Si possible, ne votez ou exécutez aucune commande qui créent de nouveaux fichiers.
  • Sélectionnez la commande de rétrécissement de pss de système afin d'essayer et réduire la taille du répertoire de /dev/shm.
  • Entrez en contact avec le centre d'assistance technique Cisco (TAC) pour l'assistance. Le TAC peut tenter de retirer les fichiers dans le répertoire de /dev/shm.

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: 116259