Solaris vazamentos de memória devido segmentos de memória compartilhada

Recentemente tivemos um problema com um dos Solaris global da zona que está a ser executado com Oracle/SAP .Normalmente o uso do sistema para correr com 40GB~ a 50GB ~ da memória física livre.Mas quando tivemos uma queda suave, descobrimos que o sistema está fazendo mais paginação para o disco e a memória física livre caiu para 6 a 8 GB.
executamos quase todas as ferramentas de monitoramento para descobrir qual processo está consumindo a memória, mas sem sorte .Então, finalmente, levantamos o caso com a oracle para encontrar a causa raiz .
configuração do sistema:
memória física do sistema :256GB
Swap: 480GB

de acordo com a parte superior,prstat, a memória física usada é quase em torno 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

por fim, o Oracle kernel engineer descobriu que segmentos de memória compartilhada consumiam 103 GB de memória física. Naquela memória de 35 GB usada por segmento de memória inválida onde nenhum processo estava usando .

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

convertendo em GB

#bc
111073374219/1024/1024/1024
103.44514084886759519577

ele descobriu que existem alguns segmentos de memória compartilhados que não estão em uso, mas mantêm o espaço de memória.

# 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 de memória compartilhada 83886120 consumido 34GB & 83886125 consumido 200MB onde não há processo está usando .O campo destacado explicará mais. Os três primeiros segmentos são válidos, pois há tantos processos que o estavam usando (1220) e as duas últimas linhas de segmentos de memória compartilhada não estavam usando por nenhum processo. (0)

NATTCH (a,a,o)

o número de processos anexados ao segmento de memória compartilhada associado.

ISMATTCH (a, i)
o número de ISM anexa aos segmentos de memória compartilhados associados.

Portanto, depois de obter a confirmação da equipe do banco de dados, removemos o segmento de memória compartilhada inválido usando o comando abaixo .
# ipcrm -m 83886120
# ipcrm -m 83886125

depois de removê-lo, Sistema de volta ao normal e trocando lote reduzido e tem quase 50 GB de memória física livre .

Obrigado por ler este artigo.Por favor ,deixe um comentário se você tiver alguma dúvida, vou voltar para você o mais rápido possível.

Leave a Reply

O seu endereço de email não será publicado.