si, pero en este momento no puedo hacer esto, estamos en inscripciones!
te paso otro onchek del momento donde los chuncks no se llenan porque ahi el tempdbs tiene datos…
onch31.txt (261 KB)
Jacqui:
Que tamaño tiene el tempdbs? Yo en tu lugar haría lo que te dice Ignacio, solo tenés que crear los dbspaces temporales (no te olvides usar el parámetro -t) y después parar y arrancar el servicio de Informix, esto no lleva más de 5 minutos y nadie se va a morir por eso. Si no lo hacés ahora, no tenés manera de verificar si el problema se supera ya que fuera de las inscripciones no tenés problemas aparentemente. Yo no dudaría y lo haría ya.
Por otro lado, en que versión del Guaraní están?
Otra cosa que me llamó la atencion del ONCONFIG son las variables:
SHMVIRTSIZE 8192 # initial virtual shared memory segment size
SHMADD 8192 # Size of new shared memory segments (Kbytes)
Ignacio sabe mucho más que yo, pero para mi gusto y teniendo en cuenta la memoria que dispones podrían tener valores más altos, probablemente 4 u 8 veces esos valores. No se si afecta a este problema, pero seguro que el motor va a trabajar más descansado.
En algún hilo del foro Informix yo subí algunos archivos de optimización del motor. Este es el hilo:
http://foro.comunidad.siu.edu.ar/index.php?topic=5976.0
Y estos los links que más recomiendo:
http://www.informix.com.ua/articles/monitor/monitor.htm
http://www.ibm.com/developerworks/data/zones/informix/library/techarticle/0303fan/0303fan.html
Aquí hay otros:
http://www.guarani.unt.edu.ar/wp-content/uploads/2012/10/Adm-y-Opt-de-Base-Datos-INFORMIX1.pdf
Saludos
Gustavo
hola! estamos en la 2.6.5 .
Lo voy a hacer y les cuento…
Jacqui:
En este link tenés una explicación y una respuesta a un caso similar al tuyo.
https://groups.google.com/forum/#!msg/comp.databases.informix/BBjDXlqDzxA/QsrBqmDyWnwJ
Como nunca vi esto en ninguna implementación me inclino a pensar que es un problema de tu base de datos (de los indices de la misma) o un problema con alguna personalización / tabla agregada al Guaraní.
En ese link está clara la explicación y la punta del ovillo para que investigues que tabla / index está causando el problema y veas la solución.
Saludos
Gustavo
hola! hice los cambios en la memoria, y agregue el tempdbs2 y me informan en bedelia que estaría funcionando mejor, igualmente se llenan los rootdbs, asi que veremos por el lado del hilo que me hiciste ver…
mil gracias! seguiremos con este tema aunque hoy terminan las inscripciones.
saludos
Jacqui
hola! luego de las vacaciones y hoy nuevamente con inscripciones y encima, cupo en las comisiones, el servidor funcionaría bárbaro!
Encontramos que habia un Sp_encuestas_pend que sería el que generaba que se llenen los chunks. La semana pasada en una inscripción pequeña lo eliminamos, y pareció funcionar, pero hoy fue la prueba de fuego ya que es más masiva la inscripción que la de la semana pasada y encima con cupo. Hoy arrancamos bárbaro (sacando el sp) y hace un rato lo habilitamos para ver si realmente era eso, y comenzaron a llenarse los chunk… Asi que lo sacamos definitivamente!
Muchas gracias a todos los que colaboraron!!
Saludos
Jacqui y Alberto
Jacqui, justamente aca estaban comentando sobre el proceso que hablas de encuestas pendientes, ese módulo de encuestas se modificó para obtener mas performance:
http://foro.comunidad.siu.edu.ar/index.php?topic=6156.0
Tal vez deban actualizarse a la ultima versión.
Jacqui:
Como dice Ale Delú, lo que debieran hacer es actualizar la versión del Guaraní, que en la 2.7.0 estaría resuelto el problema, por eso te preguntaba con anterioridad en que versión estaban.
Saludos
Gustavo
Hola,
Buscando en el foro encontré esta conversación.
Nosotros hace 15 días o mas venimos sufriendo como locos porque se nos estan cayendo todas las bases. todos los dias una nueva.
Asumimos que el problema viene de la sobrecarga de conexiones a internet, Ahora los docentes acceden a cargar notas y antes no lo hacian.
Alguna idea de como buscar que sp es que el que nos llena los /tmp?
Desde ya muchas gracias.
Lic Sandra Ferrando
Uncoma
Hola Sandra, buen dia. Podras indicar en que version de Guarani 2 se encuentran?
Como para poder ver si encontramos si hubo alguna solución al problema planteado en versiones posteriores.
Hola Alejandro,
estamos en la versión 2.9.3 de Guaraní.
Tenemos servidores Linux, corriendo Informix 9.1 sobre una maquina vitual con Debian 4 de 32 bits.
Estamos leyendo de todo, y sospechando todo. Hemos agrandado los chunk a 2 Gb y se nos llenan.
Lo diferente este año ademas de la pandemia:
- Tenemos encuestas , aunque finalizaron el 1 de junio del 2020.
- Los docentes cargaran notas de cursados y examénes
- Se utiliza la mensajería provista por la aplicación.
Hicimos una búsqueda en el foro de que podria ser que nos llenara los temp
Estuvimos revisando si teníamos problemas con un sp que ustedes optimizaron. el sp sp_encuestas_pen y no lo tenemos y tampoco el sp sp_carga_enc_list.
Tenemos definido sp_carga_encue_pen, no se si el problema esta ahi,
En un servidor se nos llenaron los /tmp
Y en otro caso se llenaron los chunk
Desde ya gracias y aceptamos sugerencias
Lic Sandra Ferrando
Eso es el chunk de un dbspace temporal?
Crearon el dbspace con nombre _temptable
Dejen corriendo el comando onstat -d con la opcion -r 1(cada 1 segundo) para ver los dbspaces y en particular vayan viendo el dbspace temporal como se va llenando.
onstat -d -r 1
En tal caso si se llena vean de agregar otro chunk a ese dbspace temporal.
Corri el comando y no veo nada raro, el /tmp esta usado en 94%
Que es el “/tmp” ?
Podes enviar una captura de imagen de la salida del comando “onstat -d” y adjuntar el ONCOFIG?
Los procedures del modulo de encuestas todos comienzan con el prefijo sp_enc_. No hay ninguno con los nombres que mencionaste, quizas estaban antes hasta version 2.7.0
Sandra, fijate en este otro foro lo relacioando a los parametros SHMVIRTSIZE y SHMADD del ONCONFIG:
http://foro.comunidad.siu.edu.ar/index.php?topic=3225.msg11691
Uds lo tienen configurado con un valor muy bajo, casi el que viene por defecto. Vean de modificarlo y ajustarlo a la configuracion de ese server. Para que tome el cambio deben bajar y levantar el motor.
¿En las imagenes corriste el comando “onstat -d” ?
Porque deberia primero listarte los dbspaces con sus nombres logicos y luego los chunks asociados a cada dbspace.
El /dev/hda7 corresponde al dbspace temporal “dbspacetemporal” que tienen definido en el onconfig?
DBSPACETEMP dbspacetemporal # Default temp dbspaces
3
Alejandro
si, estos datos coinciden
El /dev/hda7 corresponde al dbspace temporal “dbspacetemporal” que tienen definido en el onconfig?
DBSPACETEMP dbspacetemporal # Default temp dbspaces
Tambien;
¿En las imagenes corriste el comando “onstat -d” ? si, te mande el resultado de onstat -d,
dba@serverciencias:~$ onstat -d
Informix Dynamic Server 2000 Version 9.21.UC4 – On-Line – Up 2 days 19:32:38 – 217176 Kbytes
Dbspaces
address number flags fchunk nchunks flags owner name
1ad557d0 1 0x1 1 1 N informix rootdbs
1b476cc0 2 0x1001 6 2 N informix dbspacecseduca
1ad94b48 3 0x2001 3 2 N T informix dbspacetemporal
1ad94c90 4 0x1 4 2 N informix dbs_phy
1ad94dd8 5 0x1 5 2 N informix dbspacelogs
5 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
1ad55918 1 1 0 400000 397724 PO- /usr/data/chunk_siu
1ad942a8 2 4 0 1024288 1024285 PO- /usr/data/chunk_phy2
1ad94418 3 3 0 262144 261991 PO- /usr/data/chunk_temp
1ad94588 4 4 0 51200 0 PO- /usr/data/chunk_phy
1ad946f8 5 5 0 204800 27 PO- /usr/data/chunk_logs
1b476e08 6 2 0 1024288 3 PO- /usr/data/chunk_ciencias
1ad94868 7 3 0 1024288 1024285 PO- /usr/data/chunk_temp2
1ad949d8 8 5 0 1024288 1024285 PO- /usr/data/chunk_logs2
1b315380 9 2 0 1024288 619365 PO- /usr/data/chunk_ciencias2
9 active, 2047 maximum
Esta mal la salida?
Alejandro,
hicimos el cambio de las variables SHMVIRTSIZE y SHMADD en Turismo, que tambien se nos cayo este findex, luego de haberlo levantado el viernes.
pero en este caso no quiere levantar
la diferencia fue que los chunk se llenaron, por eso estaba buscando que puede ser que nos llene en 24 horas .
Dbspaces
address number flags fchunk nchunks flags owner name
1ad5d7d0 1 0x1 1 1 N informix rootdbs
1ad5da88 2 0x1 6 1 N informix dbspaceposgturismo
1ad5dbd0 3 0x2001 3 2 N T informix dbspacetemporal
1ad5dd18 4 0x1 4 2 N informix dbs_phy
1ad5de60 5 0x1 5 2 N informix dbspacelogs
1ad8d830 6 0x5 9 2 ND informix dbspaceturismo
6 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
1ad5d918 1 1 0 400000 397716 PO- /usr/data/chunk_siu
1ad9c2a8 2 4 0 1024288 1024285 PO- /usr/data/chunk_phy2
1ad9c418 3 3 0 262144 262091 PO- /usr/data/chunk_temp
1ad9c588 4 4 0 51200 0 PO- /usr/data/chunk_phy
1ad9c6f8 5 5 0 204800 27 PO- /usr/data/chunk_logs
1ad9c868 6 2 0 524288 468263 PO- /usr/data/chunk_posgturismo
1ad9c9d8 7 3 0 1024288 1024285 PO- /usr/data/chunk_temp2
1ad9cb48 8 5 0 1024288 1024285 PO- /usr/data/chunk_logs2
1ad9ccb8 9 6 0 1024288 0 PD- /usr/data/chunk_turismo
1ad9ce28 10 6 0 1024288 0 PD- /usr/data/chunk_turismo2
10 active, 2047 maximum
Los dos chunks del dbspace estan llenos o no se puede mostrar cuan llenos estan porque le dbspace esta caido (PD = Down):
Dbspaces
address number flags fchunk nchunks flags owner name
1ad8d830 6 0x5 9 2 ND informix dbspaceturismo
6 active, 2047 maximum
Chunks
address chk/dbs offset size free bpages flags pathname
1ad9ccb8 9 6 0 1024288 0 PD- /usr/data/chunk_turismo
1ad9ce28 10 6 0 1024288 0 PD- /usr/data/chunk_turismo2
Con esta consulta recuperas el tamaño de la base:
select sum(size)* 4096 from sysextents where dbsname = “nombre_base”; – Windows
select sum(size)* 2048 from sysextents where dbsname = “nombre_base”; – Linux
Multiplica por 4096 (4kb) si el servidor esta en Windows o 2048 (2kb) si el servidor es un Linux.
Fijate que tablas son las que mas ocupan:
select sum(size) * 4096 from sysextents where dbsname = “nombre_base”; – Esto esta expresado en bytes
– Tablas de log
select sum(size)*4096 from sysextents where dbsname = ‘nombre_base’
and tabname[1,4] = ‘log_’; – Esto esta expresado en bytes
– Tamaño de la base de las tablas del guarani
SELECT tabname, sum(size)*4096
from sysextents
where dbsname = ‘nombre_base’
and tabname[1,3] not in (‘log’, ‘sys’) – Esto esta expresado en bytes
group by tabname
order by 2 desc
¿Estan haciendo exports de las bases?
Porque el backup no se esta realizando, esta seteado a nul
TAPEDEV /dev/null # Tape device path
Y este parametro debiera estar en 1 en el caso que hagan backup de logical logs en forma automatico, para que permita hacer backup si se llenan todos menos el ultmo logical log, aunque tambien el backup de logical logs esta definido en nul:
LBU_PRESERVE 0 # Preserve last log for log backup
Log Archive Tape Device
LTAPEDEV /dev/null # Log tape device path
Alejandro
Que dia!! Tenemos dos problemas graves.
-
el servidor de Ciencias fue el que el cambios la configuracion de las variables, lo bajamos y ahora no quiere levantarse.
-
el servidor de Turismo esta actualmente en modo Quiescent (CKPT REQ) porque se quedo en 24 hora sin espacio en los chunk.
Imaginate como estamos,
Agradezco tus consultas para conocer el tamaño de la base, pero ahora no los puede ejecutar