wycieki pamięci Solaris z powodu segmentów pamięci współdzielonej

ostatnio mieliśmy problem z jedną z Solaris global zone, która działa z Oracle / SAP .Zwykle system działa z 40 GB~ do 50 GB~ wolnej pamięci fizycznej.Ale kiedy mieliśmy miękkie zawiesić , okazało się, że system robi więcej stronicowania na dysku i wolna pamięć fizyczna spadła do 6 do 8GB.
uruchomiliśmy prawie wszystkie narzędzia monitorujące, aby dowiedzieć się, który proces zużywa pamięć, ale bez powodzenia .W końcu poruszyliśmy sprawę z wyrocznią, aby znaleźć przyczynę .
konfiguracja systemu:
pamięć fizyczna systemu: 256 GB
Zamień: 480 GB

zgodnie z top, prstat, używana pamięć fizyczna wynosi prawie około 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

wreszcie inżynier jądra Oracle stwierdził, że segmenty pamięci współdzielonej zostały zużyte 103 GB pamięci fizycznej. W tej pamięci 35GB używany przez nieprawidłowy segment pamięci, w którym żaden proces nie używał go .

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

konwertując do GB

#bc
111073374219/1024/1024/1024
103.44514084886759519577

odkrył, że istnieje kilka segmentów pamięci dzielonej, które nie są używane, ale trzymają przestrzeń pamięci.

# 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 pamięci współdzielonej 83886120 zużyty 34GB & 83886125 zużyty 200MB tam, gdzie nie ma procesu z niego korzystającego .Podświetlone pole wyjaśni więcej. Pierwsze trzy segmenty są poprawne, ponieważ wiele procesów z nich korzystało(1220), a dwie ostatnie linie segmentów pamięci współdzielonej nie były używane przez żaden proces. (0)

NATTCH (A,a,o)

liczba procesów dołączonych do powiązanego segmentu pamięci współdzielonej.

ISMATCH (a,i)
liczba ISM dołączanych do powiązanych segmentów pamięci współdzielonej.

więc po otrzymaniu potwierdzenia od zespołu bazy danych, usunęliśmy nieprawidłowy segment pamięci współdzielonej za pomocą poniższego polecenia .
# ipcrm -m 83886120
# ipcrm -m 83886125

po jego usunięciu system wrócił do normy i zamienił się dużo i dostał prawie 50GB wolnej pamięci fizycznej.

Dziękujemy za przeczytanie tego artykułu.Zostaw komentarz, jeśli masz jakiekolwiek wątpliwości, skontaktuję się z Tobą tak szybko, jak to możliwe.

Leave a Reply

Twój adres e-mail nie zostanie opublikowany.