Solaris-Speicherlecks aufgrund von gemeinsam genutzten Speichersegmenten

Kürzlich hatten wir ein Problem mit einer der globalen Solaris-Zonen, die mit Oracle / SAP ausgeführt wird.Normalerweise wird das System mit 40 GB ~ bis 50 GB ~ freiem physischem Speicher ausgeführt.Aber als wir einen weichen Hang hatten , stellten wir fest, dass das System mehr Paging auf die Festplatte ausführt und der freie physische Speicher auf 6 bis 8 GB gesunken ist.
Wir haben fast alle Überwachungstools ausgeführt, um herauszufinden, welcher Prozess den Speicher belegt, aber kein Glück .Dann hatten wir endlich den Fall mit Oracle angesprochen, um die Ursache zu finden .
System konfiguration:
System Physikalische Speicher: 256 GB
Swap: 480 GB

Wie pro top, prstat, verwendet physikalische speicher ist fast um 200 GB ~.

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

Schließlich Oracle Kernel Engineer festgestellt, dass Shared-Memory-Segmente verbraucht wurde 103 GB physischen Speicher. In diesem 35-GB-Speicher, der von einem ungültigen Speichersegment verwendet wird, in dem kein Prozess es verwendet.

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

Konvertieren in GB

#bc
111073374219/1024/1024/1024
103.44514084886759519577

Er stellte fest, dass es einige gemeinsam genutzte Speichersegmente gibt, die nicht verwendet werden, aber den Speicherplatz halten.

# 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

Shared Memory Segment 83886120 verbraucht 34GB & 83886125 verbraucht 200MB, wo es keinen Prozess gibt, der es benutzt .Hervorgehobenes Feld wird mehr erklären. Die ersten drei Segmente sind gültig, da so viele Prozesse sie verwenden (1220) und die letzten beiden Zeilen gemeinsam genutzter Speichersegmente von keinem Prozess verwendet wurden. (0)

NATTCH (a,A,o)

Die Anzahl der Prozesse, die an das zugehörige gemeinsam genutzte Speichersegment angehängt sind.

ISMATTCH (a,i)
Die Anzahl der ISM-Anhänge an die zugeordneten gemeinsam genutzten Speichersegmente.

Nachdem wir die Bestätigung vom Datenbankteam erhalten haben, haben wir das ungültige gemeinsam genutzte Speichersegment mit dem folgenden Befehl entfernt.
# ipcrm -m 83886120
# ipcrm -m 83886125

Nach dem Entfernen, System wieder normal und Swapping reduziert viel und bekam fast 50 GB freien physischen Speicher .

Vielen Dank für das Lesen dieses Artikels.Bitte hinterlassen Sie einen Kommentar, wenn Sie Zweifel haben, ich werde mich so schnell wie möglich bei Ihnen melden.

Leave a Reply

Deine E-Mail-Adresse wird nicht veröffentlicht.