Hola! Desde hace un tiempo, se nos llena el disco del servidor con archivos que se llaman tmpshmemxxxxxx, todos comienzan con tmpshmem y luego le siguen unos números. Alguien sabe de que se trata?
Saludos
Hola Jaqui
Me parece que el informix genera esos archivos cuando hace un dump de la memoria por algun fallo.
Fijate en el log de la instancia a ver si no están referenciados.
Emilio
En el log no están referenciados.
Lo que vimos es que en la carpeta e:\tmp (carpeta DUMPDIR en el onconfig) hay archivos que tienen la misma serie de números que los que se generaron en el E:. Por ejemplo, el archivo en el e:\ se llama tmpshmem.6450ff59.0 y en la carpeta e:\tmp el archivo se llama af.6450ff59.0.
Esto está tomado de ibm
Debugging a UDR that crashes the server when it loadsAfter your server crashes, the log file points you to a shmem file in your /tmp directory (e.g. /tmp/shmem.1b94d8.0). This file holds the state of the server at the time of the crash. You can examine it with the onstat command.
The following command produces a list of the threads that were active at the time of the crash:
% onstat -g ath /tmp/shmem.1b94d8.0
onstat -g ath /tmp/shmem.1b94d8.0
You can look at individual threads with:
% onstat -g stk <thread #> /tmp/shmem.1b94d8.0
onstat -g stk <thread #> /tmp/shmem.1b94d8.0
This will give you a stack trace of the thread. One of the threads that is shown as “running” should give you the information you’re after.
An ascii file (/tmp/af.*) also gets generated; your online.log file will give you the specific filename.
ahi dice que se generan dos archivos y no me extrañaría que /tmp/shmem por alguna conversión/lectura se transforme en tmpshmem.
Yo trataría de ejecutar los comandos mencionados y ver si da algo coherente.
Lo que si, se producen tantos crash me pondría a ver que está pasando.
Emilio
Jaqui:
Evidentemente hay problemas con ese servidor Informix. Yo que vos trataría de ver urgente cual es la causa y resolverla, antes que sea tarde y tengan un problema más serio.
Hay que mirar el log del motor, que seguro que allí acusa los problemas que hubieron.
Y quizás te convenga postear tu primer mensaje en el foro de Informix.
Saludos
Gustavo
Hola
Esos archivos son vuelcos del area de shared memory de Informix, que se generan ante una caida o un assert failed (de ahi viene el nombre af del archivo) si todo anda bien no se deberian generar
Estos archivos, les sirven a la gente de soporte para investigar posteriormente el estado del motor al momento de la caida
En tu caso habria que entender primero porque se generan. POr lo que veo el informix no se cae, sino que sigue funcionando.
Si me pasas el onconfig, y el log de Informix veo si puedo encontrar algo en relacion a la causa.
COn respecto al espacio en disco, si es posible borra los mas viejos y quedate con un par de los ultimos generado, que en una de esas sean necesarios.
saludos
Ignacio
gracias a todos por contestar!
te paso el onconfig, el log log desde fines de noviembre y una imagen de los archivos para que veas las fechas.
Saludos y gracias!!
ol_siu_guarani.log desde el 24 de nov.txt (595 KB)
ONCONFIG.ol_siu_guarani.txt (9.56 KB)
HOla Jakie,
Este mensaje aparece varias veces en el log, y esta relacionado con la generacion de estos archivos. Por lo que vi siempre esta relacionado con el chunk11, pero no siempre es en la misma pagina del chunk. Debe haber algun tipo de corrupcion en ese chunk. Podrias pasarme un onstat -d y la salida de un ocheck -pe, para ver que hay en ese chunk
Por ultimo, el mensaje dice “Internally corrected” pero igual hay que buscarle una solucion. Si el problema esta en una tabla de la base, un dbimport o un load puede ser la solucion.
12:27:22 Assert Failed: tmpmsg1
12:27:22 Informix Dynamic Server 2000 Version 9.21.TC4
12:27:22 Who: Session(214977, internet@w3gapache0.ungs.edu.ar, 13968, 0)
Thread(221288, sqlexec, 0, 3)
File: rspartn.c Line: 8621
12:27:22 Results: Internally corrected
12:27:22 stack trace for pid 2072 written to E:\tmp\af.6450ff59
12:27:22 See Also: E:\tmp\af.6450ff59, shmem.6450ff59.0
12:27:26 Releasing server from system block
12:28:11 I/O read chunk 11, pagenum 463567, pagecnt 1 → errno = 5
12:28:11 Assert Failed: tmpmsg1
12:28:11 Informix Dynamic Server 2000 Version 9.21.TC4
12:28:11 Who: Session(214977, internet@w3gapache0.ungs.edu.ar, 13968, 0)
Thread(221288, sqlexec, 0, 3)
File: rspartn.c Line: 8621
12:28:11 Results: Internally corrected
12:28:11 stack trace for pid 2072 written to E:\tmp\af.6450ff59
12:28:11 See Also: E:\tmp\af.6450ff59
Hola Jacqui
Lo que haría yo es:
1.- sacar los logical logs 1-10 que estan en el root dbspace y pasalos al dbspace que tiene los otros logical logs.
2.- buscaría dropear el chunk 11, si es posible y crear otro SIN borrar el archivo físico. Aparentemente tenes un problema de disco que te está molestando.
Alguien podrá dar alguna otra receta.
Emilio
Hola Jakie,
Hay algo raro con ese chunk 11 que esta dando errores. Te sugiero borrar el chunk. Antes de eso hace un backup con ontape y dbexport.
Como borrar el chunk:
1- Primero hay que vaciarlo, por suerte solo tiene una tabla (siu_guarani_gra:‘dba’.temp_actas). Para borrar esa tabla, deberian hacer un UNLOAD previamente y luego un DROP de la tabla. Ojo: quizas no exista mas, porque tiene pinta de ser tabla temporal que estaba en el momento de sacar el oncheck.
2- Verifica que el chunk esta vacio, hace un onstat -d y fijate que el FREE sea 499997
3- Una vez vacio el chunk desde la linea de comando deberian ejecutar:
onspaces -d rootdbs -p e:\ifmxdata\ol_siu_guarani\rootdbs_dat.002 -o 0
4- verificar que se borro haciendo un onstat -d
5- volver a hacer un ontape -s, ya que el anteior no sirve mas pues incluye en chunk 11
Por otro lado hay un par de cosas que se deberian revisar:
1- mover todos los logs al dbspace de logs.
2- verificar que las tablas temporales se esten creando en el dbspace temporal y no en el rootdbs.
3- revisar porque tienen 3 chunks de 2 GB en el rootdbs y no en guarani_dbs
si necesitas ayuda cuando borren el chunk, llamame y coordinamos
saludos
Ignacio
gracias!! Lo voy a programar para estos días y te cuento!
saludos
Jacqui
Volviendo a este tema luego de las vacaciones, estoy como en blanco, no me acuerdo nada!!!
tengo algunas dudas en las cositas a revisar:
- Los borro y los vuelvo a crear?? o como los muevo?
2)como verifico que las tablas temprales se crean en eldbspace temporal? - Esos chunck los hicimos porque se llenaban en la inscripción (debe tener que ver con el punto 2 se me ocurre…)
Hoy arrancamos las inscripciones y tenemos el problema de que quedan las sesiones de internet bloqueadas, y los dbspace de rootdbs se quedan vacíos… pero lo raro es que esta vez no se generaron esos archivos tmpshmemXXXX que iniciaron este foro…
MIl gracias!
saludos
Jacqui
Básicamente en este momento tenemos este problema:
los chunck de root se llenan todos cuando habilitamos la inscripción por internet, y haciendo el oncheck -pe me encuentro con esto:
Chunk Pathname Size Used Free
12 e:\ifmxdata\ol_siu_guarani\rootdbs_dat.003 500000 500000 0
Description Offset Size
RESERVED PAGES 0 2
CHUNK FREELIST PAGE 2 1
siu_guarani_gra:‘dba’._temptable 3 499997
Total Used: 500000
Total Free: 0
tenemos esa temptable que llena todo el espacio. A que se debe? que podemos cambiar para solucionarlo?? Help!!!
Hola Jacqui
Hay que ver quien está cargando datos en esa tabla. Y porque no los está borrando.
Aunque se llame temptable me huele que no es una tabla temporal.
Emilio
hola! les cuento la situación a julio… cambiamos el servidor, tenemos uno nuevo ya que tuvo problemas en el disco.
pero sigue dejando el rootdbs sin espacio. Ahora haciendo un onckeck -pe veo que en el temdbs me tira este error:
DBspace Usage Report: tempdbs Owner: informix Created: 04/10/2012
ERROR: Failed to get header page for partnum 0x300021 (buffer may be locked).
Please limit DDL/DML activity when running this command.
Alguna sugerencia? gracias!
Agrego que cuando el rootdbs se llena (tenemos 5 ya y todos quedan vacíos) en todos se genera una única tabla llamada _TEMPTABLE. Les copio uno de ellos, pero todos son iguales:
Chunk Pathname Size Used Free
12 C:\IFMXDATA\ol_siu_guarani\rootdbs_dat.002 500000 500000 0
Description Offset Size
RESERVED PAGES 0 2
CHUNK FREELIST PAGE 2 1
siu_guarani_gra:‘dba’._temptable 3 499997
Total Used: 500000
Total Free: 0
gracias!
Jacqui:
Podrás pasar más información? El Informix es sobre Windows o Linux? Que versión del Guaraní?
Por otra parte, intentaste ver que información tiene esa temptable? Y en que momento se genera y se va poblando?
Yo nunca vi nada igual, tengo muchísimas instalaciones a cuestas del Guaraní, incluso algunas con una cantidad muy grande de alumnos y registros de historia académica. Y en ninguna tuve problemas de espacio en un rootdbs y los rootdbs son a lo sumo de 2 GB. Obviamente los logical logs y physical log están en otro dbspace y tanbién tengo habilitados dbspaces para las temporales. Incluso te diría que no es fácil llenar un dbspace con 1 sola base del Guaraní.
Es todo muy raro lo que te pasa y pienso que debe ser algún parámetro especial de configuración que se ha modificado distinto de lo recomendado.
Saludos
Gustavo
Gracias por contestar!
te paso los datos, el servidor de base de datos es un Windows 2003 virtualizado en VMWare esxi 5 con 2 procesadores de 4 núcleos asignados. 4Gb de RAM. U disco de 60 Gb en el cual nos quedan 11 Gb libres.
El servidor Web es un Debian 5 virtualizado en VMWare esxi 5 con 4Gb de memoria.
Te subo una salida de oncheck -pe para que veas la _TEMPTABLE de la que te hablo.
también te paso el ONCONFIG.
ONCONFIG.ol_siu_guarani.txt (11.1 KB)
onchek2.txt (262 KB)
Hola Jacqui,
Por que no probas de generar un par mas de dbspace temporales y declaralos en el onconfig. tipo tempdbs2 y tempdbs3 con 2 o 4 Gb cada uno
Por lo que veo en la salida del oncheck, dice que tiene algun problema con el temporal, al no poder usarlo se va a usar el rootdbs.
Cuando pasa esto que se llena el rootdbs, hay alguna operacion puntual corriendo en esos momentos.
Quizas con otros temporales podemos rodear el problema.
saludos