Il faut parfois vérifier tous les répertoires dans lesquels énormetlbfs a été monté. Donc,
-
trouver le répertoire monté par la commande
mount | grep huge. -
vérifier tous les répertoires sauf en particulier
/dev/hugepages. -
supprimer tous les fichiers de taille 2M. (2M est la taille d'une énorme page)
Utilisez ipcs -m pour lister les segments de mémoire partagée. Utilisez ipcrm pour supprimer les segments de mémoire partagée restants.
Edit le 24/06/2019 :Ok, donc, la réponse ci-dessus, bien que correcte dans la mesure où elle va, était un peu brève. En particulier, si vous avez un hôte avec plusieurs instances de base de données et qu'une seule est en panne, comment pouvez-vous déterminer quels segments de mémoire (le cas échéant) doivent être nettoyés ?
Eh bien, cela aussi, peut être fait. Pour chaque instance en cours d'exécution, connectez-vous avec / as sysdba , puis faites oradebug setmypid (n'importe quel pid fera l'affaire, car tous les PID Oracle se connectent au SGA). Faites ensuite oradebug ipc . Cela renverra (espérons-le) IPC information written to the trace file . Allez donc dans le répertoire udump (ou diag_dest) et recherchez votre fichier de trace. Il contiendra toutes les informations IPC pour l'instance. Cela inclura ShmId . Recherchez dans le fichier le(s) ShmId(s) utilisé(s) par cette instance. Regardez maintenant la sortie de ipcs -m .
Lorsque vous avez fait cela pour toutes les instances en cours d'exécution, tout segment de mémoire généré par ipcs -m qui affiche une allocation de mémoire non nulle et que vous ne pouvez pas prendre en compte dans le oradebug ipc informations de toute instance en cours d'exécution, doivent être les segments de mémoire restants de l'instance en panne. Utilisez ipcrm pour le/les supprimer.
Lorsque vous faites cela sur un hôte avec plusieurs instances en cours d'exécution, cela peut être un peu lourd. Veuillez procéder avec prudence. Vous ne voulez pas supprimer la SGA d'une instance en cours d'exécution !
J'espère que ça aide....