Solaris memory leaks due shared memory segments

recent am avut o problemă cu una din Solaris global zone care se execută cu Oracle/SAP .În mod normal, utilizarea sistemului pentru a rula cu 40gb~ la 50GB~ de memorie fizică liberă.Dar când am avut un soft hang, am constatat că sistemul este de a face mai mult de paginare pe disc și memorie fizică liberă a scăzut la 6 la 8GB.
am rulat aproape toate instrumentele de monitorizare pentru a afla ce proces consumă memoria, dar fără noroc .Apoi, în cele din urmă, am ridicat cazul cu oracle pentru a găsi cauza principală .
configurare sistem:
memorie fizică sistem: 256gb
Swap: 480GB

ca pe partea de sus,prstat, memoria fizică utilizată este aproape în jurul valorii de 200GB~ .

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

în cele din urmă Oracle kernel engineer a constatat că segmentele de memorie partajată a fost consumat 103 GB de memorie fizică. În acea memorie de 35 GB utilizată de segmentul de memorie nevalid în care niciun proces nu o folosea .

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

conversia în GB

#bc
111073374219/1024/1024/1024
103.44514084886759519577

el a găsit există câteva segmente de memorie partajate, care nu sunt în uz, dar care deține spațiul de memorie.

# 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

segment de memorie partajată 83886120 consumat 34gb & 83886125 consumat 200MB în cazul în care nu există nici un proces îl folosesc .Câmpul evidențiat va explica mai multe. Primele trei segmente sunt valabile unul, deoarece există atât de multe proces au fost folosind-o(1220) și ultimele două linii de segmente de memorie partajată nu au fost utilizați de către orice proces. (0)

NATTCH (a,a,o)

numărul de procese atașate segmentului de memorie partajată asociat.

ISMATTCH (a,i)
numărul de ISM se atașează segmentelor de memorie partajată asociate.

deci, după ce am primit confirmarea de la echipa bazei de date, am eliminat segmentul de memorie partajată nevalid folosind comanda de mai jos .
# ipcrm -m 83886120
# ipcrm -m 83886125

după eliminarea acestuia, sistemul înapoi la normal și schimbarea lot redus și a primit aproape 50GB memorie fizică liberă .

Vă mulțumim că ați citit acest articol.Vă rugăm să lăsați un comentariu dacă aveți vreo îndoială, voi reveni la tine cât mai curând posibil.

Leave a Reply

Adresa ta de email nu va fi publicată.