Fuites de mémoire Solaris dues à des segments de mémoire partagée

Récemment, nous avons eu un problème avec l’une des zones globales Solaris fonctionnant avec Oracle/ SAP.Normalement, le système fonctionne avec 40 Go ~ à 50 Go ~ de mémoire physique libre.Mais quand nous avons eu un blocage en douceur, nous avons constaté que le système faisait plus de pagination sur le disque et que la mémoire physique libre était réduite à 6 à 8 Go.
Nous avons exécuté presque tous les outils de surveillance pour trouver quel processus consomme la mémoire, mais pas de chance.Puis finalement, nous avions soulevé le cas avec oracle pour trouver la cause profonde.
Configuration du système:
Mémoire physique du système: 256 Go
Swap: 480 Go

Selon top, prstat, la mémoire physique utilisée est presque d’environ 200 Go ~.

root@ ~]# sar -r 5 5
SunOS 5.10 Generic_144500-19 sun4u 09/05/2012
16:40:11 freemem freeswap
16:40:16 885031 399256061
16:40:22 883764 399240091
16:40:27 882266 399212586
16:40:33 882487 399223267
16:40:38 882453 399221275
Average 883193 399230658
root@ ~]# echo "::memstat" | mdb -k
Page Summary Pages MB %Tot
----------- ---------------- ---------------- ----
Kernel 1696877 13256 5%
Anon 24796106 193719 75%
Exec and libs 150104 1172 0%
Page cache 5814314 45424 18%
Free (cachelist) 437928 3421 1%
Free (freelist) 79348 619 0%
Total 32974677 257614
Physical 32952777 257443

Enfin, l’ingénieur du noyau Oracle a constaté que les segments de mémoire partagée consommaient 103 Go de mémoire physique. Dans cette mémoire de 35 Go utilisée par un segment de mémoire invalide où aucun processus ne l’utilisait.

# ipcs -ZmA |awk '{x=x+} END {print x}'
111073374219

Conversion en Go

#bc
111073374219/1024/1024/1024
103.44514084886759519577

Il a constaté qu’il existe deux segments de mémoire partagée qui ne sont pas utilisés mais qui contiennent l’espace mémoire.

# ipcs -mA |grep myora1
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME ISMATTCH
m 19777443 0x8795c49c --rw-rw---- myora1 db myora1 db 1220 24576 23178 21487 9:15:48 9:16:07 14:15:49 1220
m 19777472 0 --rw-rw---- myora1 db myora1 db 1220 34292629504 23178 21487 9:15:48 9:16:07 14:15:58 1220
m 20331903 0 --rw-rw---- myora1 db myora1 db 1220 201326592 23178 21487 9:15:48 9:16:07 14:16:47 1220
m 83886120 0 --rw-rw---- myora1 db myora1 db 0 34292629504 24490 24490 9:56:37 9:56:37 9:56:09 0
m 83886125 0 --rw-rw---- myora1 db myora1 db 0 201326592 24490 24490 9:56:09 9:56:37 9:56:09 0

Le segment de mémoire partagée 83886120 a consommé 34 Go & 83886125 a consommé 200 Mo là où aucun processus ne l’utilise.Le champ en surbrillance expliquera plus. Les trois premiers segments sont valides car il y a tellement de processus qui l’utilisaient (1220) et les deux dernières lignes de segments de mémoire partagée n’étaient utilisées par aucun processus. (0)

NATTCH(a, a, o)

Le nombre de processus attachés au segment de mémoire partagée associé.

ISMATTCH(a, i)
Le nombre d’ISM attachés aux segments de mémoire partagée associés.

Donc, après avoir reçu la confirmation de l’équipe de base de données, nous avons supprimé le segment de mémoire partagée non valide à l’aide de la commande ci-dessous.
# ipcrm -m 83886120
# ipcrm -m 83886125

Après l’avoir retiré, le système est revenu à la normale et l’échange a réduit le lot et a presque 50 Go de mémoire physique gratuite.

Merci d’avoir lu cet article.Veuillez laisser un commentaire si vous avez le moindre doute, je reviendrai vers vous dès que possible.

Leave a Reply

Votre adresse e-mail ne sera pas publiée.