Fugas de memoria Solaris debidas a segmentos de memoria compartida

Recientemente tuvimos un problema con una de las zonas globales de Solaris que se ejecuta con Oracle/SAP .Normalmente, el sistema se usa para funcionar con 40 Gb~ a 50 GB~ de memoria física libre.Pero cuando tuvimos una caída suave, encontramos que el sistema está haciendo más paginación al disco y la memoria física libre bajó a 6 a 8 GB.
Ejecutamos casi todas las herramientas de monitoreo para encontrar qué proceso está consumiendo la memoria, pero no hubo suerte .Luego, finalmente, planteamos el caso con Oracle para encontrar la causa raíz .
Configuración del sistema:
Memoria física del sistema: 256 GB
Swap: 480 GB

Según la parte superior, prstat, la memoria física utilizada es casi de alrededor de 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

Finalmente, Oracle kernel engineer descubrió que los segmentos de memoria compartida consumían 103 GB de memoria física. En esa memoria de 35 GB utilizada por un segmento de memoria inválido donde ningún proceso la usaba .

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

Convertir en GB

#bc
111073374219/1024/1024/1024
103.44514084886759519577

encontró que hay un par de segmentos de memoria compartida que no están en uso pero manteniendo el espacio de 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 de memoria compartida 83886120 consumidos 34 GB & 83886125 consumidos 200 MB donde no hay ningún proceso que lo esté usando .El campo resaltado explicará más. Los tres primeros segmentos son válidos, ya que hay tantos procesos que lo estaban usando (1220) y las dos últimas líneas de segmentos de memoria compartida no los estaba usando ningún proceso. (0)

NATTCH (a,A,o)

El número de procesos conectados al segmento de memoria compartida asociado.

ISMATCH (a,i)
El número de conexiones ISM a los segmentos de memoria compartida asociados.

Por lo tanto, después de obtener la confirmación del equipo de base de datos, hemos eliminado el segmento de memoria compartida no válido utilizando el siguiente comando .
# ipcrm -m 83886120
# ipcrm -m 83886125

Después de eliminarlo, el sistema volvió a la normalidad e intercambió un lote reducido y obtuvo casi 50 GB de memoria física libre .

Gracias por leer este artículo.Por favor ,deje un comentario si tiene alguna duda, me pondré en contacto con usted lo antes posible.

Leave a Reply

Tu dirección de correo electrónico no será publicada.