共有メモリセグメントによるSolarisメモリリーク
最近、Oracle/SAPで実行されているSolaris大域ゾーンの1つに問題が通常、システムは40GB〜50GB〜の空き物理メモリで実行するために使用します。しかし、ソフトハングが発生したとき、システムはディスクへのページングを増やしており、空き物理メモリは6-8GBに低下していることがわかりま
ほとんどすべての監視ツールを実行して、どのプロセスがメモリを消費しているかを確認しましたが、運がありません。その後、最終的に私たちは根本的な原因を見つけるためにoracleとのケースを提起していました。
システム構成：
システム物理メモリ：256GB
スワップ：480GB
トップによると、prstat、使用される物理メモリはほぼ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
最後に、Oracle kernel engineerは、共有メモリ-セグメントが103GBの物理メモリを消費していることを発見しました。 プロセスがそれを使用していなかった無効なメモリセグメントによって使用されるその35GBメモリ。
# ipcs -ZmA |awk '{x=x+} END {print x}'
111073374219
GBに変換する
#bc
111073374219/1024/1024/1024
103.44514084886759519577
彼は、使用されていないが、メモリ空間を保持している共有メモリセグメントがいくつかあることを発見しました。
# 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
共有メモリセグメント83886120消費された34GB&83886125消費された200MBプロセスが使用していない場合。強調表示されたフィールドは、より多くを説明します。 最初の3つのセグメントは、非常に多くのプロセスがそれを使用していた（1220）ので、有効なものであり、共有メモリセグメントの最後の2行は、どのプロセ (0)
NATTCH(a,A,o)
関連する共有メモリセグメントに接続されているプロセスの数。
ISMATTCH(a,i)
関連する共有メモリセグメントにアタッチされるISMの数。
関連する共有メモリセグメントにアタッチされるISMの数。
だから、データベースチームから確認を得た後、我々は以下のコマンドを使用して無効な共有メモリセグメントを削除しました。
# ipcrm -m 83886120
# ipcrm -m 83886125
それを削除した後、システムは通常に戻り、スワップはロットを減らし、ほぼ50GBの空き物理メモリを得ました。
この記事を読んでくれてありがとう。あなたが疑問を持っている場合は、コメントを残してください、私はできるだけ早くあなたに戻って取得します。