Aclaracion de AMM (Automatic Memory Management)

[Ivan Dario Acosta]

Hola que tal.....bueno esta vez le escribo a la comunidad para solicitar una ayuda o aclaracion de un tema que no he podido entender. Bueno he estado proactivo con las tareas como DBA y active una maquina que tiene 3 instancias el AMM de Oracle para cada una de las estas instancias. Actualmente mi configuracion es asi:

S.O Linux 5.6 (64 bits)

Oracle Database Server 11.2.0.1.0

3 Intancias ( PALO, SAPO, BURRO)

16 GB RAM

16 GB SWAP

Realice la activacion de estos parametros para activar AMM y actualmente estan asi en la instancia PALO

memory_max_target big integer  =    8G
memory_target big integer          =    6G

PGA_AGGREGATE_TARGET    =  0
SGA_TARGET                          =  0

Cuando active estos parámetros, note con curiosidad que la el filesytem tmpfs (/dev/shm) que tiene espacio asignado de 8GB comenzó a llenarse y actualmente esta al 50%. Y aqui vienen mis preguntas:

Conozco que esta area del tmpfs es de memoria volatil, por lo tanto las instancias comienzan a experimentar mejor desempeño, pero como hace ORACLE SERVER para administrar este espacio...?? cada cuanto borrar esos archivos  ..??? Se hace automatico...?? 

Estos archivo se tiene bajo esta descripcion (ora_PALO_5701640_187) y esta (JOXSHM_EXT_87_PALO_XXXXXXX)

Gracias por la aclaracion que me puedan brindar sobre el tema. Muchas Gracias

[Juan Andrés Mercado]

Como Estas Ivan ?

Quisiera , en lo posible si podes subir la salida de :

ls -ltrah 

del filesystem que comentas.

A posterior con el usuario root ( en el caso de que puedas acceder a esa cuenta )

la salida del comando lsof /tmpfs

Saludos Cordiales.

Juan Andres Mercado

twt: enjoydana
blog: http://burzaco.wordpress.com
about me: http://www.linkedin.com/in/juanandres

[Juan Andrés Mercado]

Ivan:

Me olvide de decirte que tengo en un ambiente productivo el mismo escenario que contas y poseemos solo 4 GB de tmpfs y jamas ocurrio lo que comentas. Con la salida del comando podriamos analizar mejor que esta ocurriendo por que por ejemplo el comando lsof te muestra que procesos acceden a que archivos en ese fileystem y asi podemos conocer el origen de quien este escribiendo en disco.

Disculpa la desprolijidad pero hoy estamos como una de tus instancias, al PALO =D

Juan Andres Mercado

twt: enjoydana
blog: http://burzaco.wordpress.com
about me: http://www.linkedin.com/in/juanandres

 

[Ivan Dario Acosta]

Cordial Saludo Juan Andres

Primero agradecerte por responder y ayudarme tan pronto. Mil Gracias....bueno te comento que ejecute el siguiente comando :

# lsof -n | grep /dev/shm | wc -l
131563

# df -h | grep /dev/shm
tmpfs 8,0G 5,6G 2,5G 69% /dev/shm

Bueno hay te anexo la salida del comando ls -ltrah .

 

Gracias

Juan Andrés Mercado dice:

Ivan:

Me olvide de decirte que tengo en un ambiente productivo el mismo escenario que contas y poseemos solo 4 GB de tmpfs y jamas ocurrio lo que comentas. Con la salida del comando podriamos analizar mejor que esta ocurriendo por que por ejemplo el comando lsof te muestra que procesos acceden a que archivos en ese fileystem y asi podemos conocer el origen de quien este escribiendo en disco.

Disculpa la desprolijidad pero hoy estamos como una de tus instancias, al PALO =D

Juan Andres Mercado

twt: enjoydana
blog: http://burzaco.wordpress.com
about me: http://www.linkedin.com/in/juanandres

 

[Juan Andrés Mercado]

Ivan:

Cuando haces :

lsof -n | grep /dev/shm | wc -l

 

ejecutalo ahora de esta manera por favor : 

 

lsof -n | grep /dev/shm | grep NOMBRE_INSTANCIA | wc -l

 

y mostrame cuantos te salen.

Por otro lado al hacer :

 

lsof -n | grep /dev/shm | grep NOMBRE_INSTANCIA 

 

ahi podes ver el proceso con el path que esta originandolo, pudiendo asi empezar a indagar:

Ejemplo:

Suponete la base BI

 

lsof -n | grep /dev/shm | grep BI

te puede llegar a salir algo asi 

/u01/app/oracle/xx/xx/db_BI/bin/ALGUN_COMANDO o

pmon, mmon , etc

ahi podemos descubrir que esta originando esos archivos que subiste.

Gracias,

Saludos Cordiales.

Juan Andres Mercado

twt: enjoydana
blog: http://burzaco.wordpress.com
about me: http://www.linkedin.com/in/juanandres

[Ivan Dario Acosta]

Cordial Saludo

Juan Andres

Gracias nuevamente por responder, mira de acuerdo a lo que me envias y al ejecutar este comando se genera lo siguiente

# lsof -n | grep /dev/shm | grep BI | wc -l
88515

Pero al ejecutar este comando 

# lsof -n | grep /dev/shm | grep BI

 Genera una lista de archivos localizados alli, este es un ejemplo de ellos

oracle    32433    oracle  mem       REG               0,24    16777216   24461129 /dev/shm/ora_BI_5734409_254

Pienso que estas base de datos genera mucha paginacion, por lo tanto se genera estos archivos. Eso es lo que se me ocurre pero no se si impacta esto en el performance de las instancias.

Gracias por tu ayuda.

[Juan Andrés Mercado]

Ivan:

Como tenes distribuida las memorias en oracle ? Cuanto para cada instancia ? Ademas:

el comando :

free -m

iostat -N

.. que te dan ?

Tenes en ASM todo ?

podes mostrar como tenes configurado el archivo :

/etc/sysctl.conf

Saludos

Juan Andres Mercado

twt: enjoydana
blog: http://burzaco.wordpress.com
about me: http://www.linkedin.com/in/juanandres

[Ivan Dario Acosta]

Cordial Saludo

Juan Andres

Mira de acuerdo a lo que envias esto es lo que tengo

free -m

total used free shared buffers cached
Mem: 16050 15903 147 0 78 11477
-/+ buffers/cache: 4347 11702
Swap: 16002 3068 12933

iostat -N

Linux 2.6.18-274.el5 (server) 05/07/12

avg-cpu: %user %nice %system %iowait %steal %idle
33,24 0,01 1,87 3,36 0,00 61,52

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 148,78 3373,34 4488,59 13159548744 17510194136
sda1 0,43 1,00 11,89 3897346 46370336
sda2 147,40 3348,68 4455,01 13063374814 17379208776
sda3 0,96 23,65 21,69 92275496 84615024
sdb 1,07 232,43 372,42 906728469 1452815700
sdb1 1,07 232,43 372,42 906725846 1452815692
U01 170,47 207,10 1349,69 807915650 5265203568
TEMP 0,04 0,01 0,30 26458 1174328
U04 162,25 797,07 1230,90 3109417626 4801787176
VAR 1,69 17,93 9,69 69963842 37803272
USR 0,97 3,25 6,44 12689282 25139488
U03 166,33 1322,68 1229,52 5159835626 4796399696
HOME 0,04 0,08 0,23 308210 903000
U02 86,59 1000,56 628,24 3903217274 2450798272
archive 47,74 232,43 371,50 906724970 1449254392

No actualmente no manejamos ASM en ninguna instancia.

PARAMETROS                   PALO      SAPO      BI
MEMORY_TARGET                6                 1             1,5
MEMORY_MAX_TARGET       8                 2               3

Dentro de los parametros de sysctl tengo lo siguiente:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 4294967295
kernel.shmall = 268435456
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_max = 1048586
fs.aio-max-nr = 1048576

Muchas Gracias

[Enrique Orbegozo]

Hola Ivan, no es 100% seguro que sea tu caso, pero en MOS el documento: In the /tmp Directory a lot of Strange Files Named *JOX* or *PESHM* can be Found [ID 1120143.1], indica que los archivos *JOX* pueden quedarse sin borrar y con el tiempo ir haciendo que el espacio ocupado aumente en /dev/shm, la solucion indicada es detener la bd y borrar los contenidos de esa carpeta (manualmente), tambien es conveniente aplicar un patch para el bug 13574534.

Saludos.

[Ivan Dario Acosta]

Cordial Saludo

Enrique

Muchas gracias por tu recomendacion, aunque no se me ha llenado este filesystem tmpfs ya que actualemente se encuentra en 70% pero lo tendren en cuenta. Muchas gracias por tu recomendacion.

[Fernando J. Andrade]

Esto se debe a un cambio de arquitectura en Linux.

La gestión de memoria con 10g utiliza los parámetros SGA_TARGET y SGA_MAXSIZE que a su vez utiliza la memoria compartida declarada en /etc/sysctl que es utilizada por las funciones de gestión de memoria que abren, cierran y utilizan la memoria compartida, esto está disponible desde hace mucho tiempo.

Ahora bien cuando te lanzas a los parámetros de 11g MEMORY_TARGET y MEMORY_MAXSIZE utilizas el /dev/shm y /dev/tmpfs que es igual memoria compartido para los procesos pero presentada como un filesystem, esto seguramente se debe a un cambio en el uso del library para le gestión de memoria compartida para linux internamente para estar más acorde a los estándares de implementación.

Así que si usas AMM tienes que estar atento con el /dev/ashm ( o /dev/tmpfs) que es la memoria compartida que utiliza la SGA. Aquí se me ocurren algunos problemas de seguridad porque en teoría otros procesos podrían leer esta memoria compartida y antes era más complicado pero al exponerse como filesystem puede ser mas sencillo.

Slds

FJA

[Ivan Dario Acosta]

Cordial Saludo

Fernando....

Muchas gracias por tu aclaracion esta muy util buscare mas informacion sobre el tema pero me das un buen elemento guia.

Gracias nuevamente.