Solaris memory leaks due shared memory segments

Recentemente abbiamo avuto un problema con una delle Solaris global zone in esecuzione con Oracle/SAP .Normalmente l’uso del sistema per funzionare con 40GB~ a 50GB~ di memoria fisica libera.Ma quando abbiamo avuto un blocco morbido, abbiamo scoperto che il sistema sta facendo più paging su disco e la memoria fisica libera è sceso a 6 a 8GB.
Abbiamo eseguito quasi tutti gli strumenti di monitoraggio per trovare quale processo sta consumando la memoria, ma senza fortuna .Poi finalmente avevamo sollevato il caso con oracle per trovare la causa principale .
Configurazione del sistema:
Memoria fisica del sistema: 256GB
Swap: 480GB

Come da top,prstat, la memoria fisica utilizzata è quasi di circa 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

Infine Oracle kernel engineer ha scoperto che i segmenti di memoria condivisa sono stati consumati 103 GB di memoria fisica. In quella memoria da 35 GB utilizzata dal segmento di memoria non valido in cui nessun processo lo stava usando .

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

Conversione in GB

#bc
111073374219/1024/1024/1024
103.44514084886759519577

Ha scoperto che ci sono un paio di segmenti di memoria condivisi che non sono in uso ma che contengono lo spazio di memoria.

# 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

Segmento di memoria condivisa 83886120 consumato 34 GB & 83886125 consumato 200 MB in cui non vi è alcun processo lo stanno utilizzando .Il campo evidenziato spiegherà di più. I primi tre segmenti sono validi poiché ci sono così tanti processi che lo stanno usando (1220) e le ultime due righe di segmenti di memoria condivisa non sono state utilizzate da alcun processo. (0)

NATTCH (a,A,o)

Il numero di processi collegati al segmento di memoria condivisa associato.

ISMATTCH (a,i)
Il numero di connessioni ISM ai segmenti di memoria condivisa associati.

Quindi, dopo aver ricevuto la conferma dal team del database, abbiamo rimosso il segmento di memoria condivisa non valido utilizzando il comando seguente .
# ipcrm -m 83886120
# ipcrm -m 83886125

Dopo averlo rimosso, il sistema torna alla normalità e scambia un lotto ridotto e ottiene quasi 50 GB di memoria fisica gratuita .

Grazie per aver letto questo articolo.Si prega di lasciare un commento se avete qualche dubbio, mi metterò di nuovo voi il più presto possibile.

Leave a Reply

Il tuo indirizzo email non sarà pubblicato.