Hola estamos en v2.9.4. y el Guaraní está muy lento y a veces hasta cancela.
Para mi es un problema de la base de datos porque no se modificó hace tiempo nada en la aplicación.
Me podrían decir que deberían hacer los DBA por dicen que no saben de Informix.
Muchas gracias.
Hola me podrían decir que herramientas de monitoreo podemos usar.
gracias
Hola Gabriela!!
Te adjunto un scrpt de actualización de estadísticas…
Otra cosa que deberías hacer cada tanto es verificar los indices con el comando oncheck desde el mismo servidor de base de datos y logueandote con un usuario que este en el grupo Informix-Admin.
oncheck -ciI nombre_base
Espero sea de ayuda…!!
UPDATE_STATISTICS_PLAN.SQL (7.77 KB)
¿Podrías adjuntar la configuración del servidor ($INFORMIXDIR/etc/oncofig_[nombre_de_la_instancia]?
Sumado a lo que dice Folky podrías revisar cuantos extents tienen las tablas mas pobladas:
Para sacar las tablas con mas filas:
SELECT tabid, tabname, nrows
FROM systables
WHERE tabid >99
ORDER BY nrows DESC
Para cada una de las filas devueltas por la consulta podrías revisar el número de extents asignados
oncheck -pt nombre_de_base_de_datos:nombre_de_tabla
o bien
select dbsname,
tabname,
count(*) num_of_extents,
sum( pe_size ) total_size
from systabnames, sysptnext
where partnum = pe_partnum
and dbsname = 'nombre_de_base_de_datos' group by 1, 2
order by 3 desc, 4 desc;
Desfragmentar las tablas o índices con mas de, digamos 7 extents, puede ser de ayuda a mejorar el rendimiento.
La forma de desfragmentar depende de la versión del producto que tengan en la institución.
Saludos
Ademas para verificar si es problema de optimización de la base de datos o problema de red, desde el mismo servidor accediendo a la base, probaron acceder a la base y verificar si también tarda mucho las consultas?
Por un lado debes actualizar las estadísticas, corre lo siguiente:
UPDATE STATISTICS HIGH
o sino el archivo que adjunto correlo en un editor sql, eso va a dar una serie de sentencias que debes correlas en la base.
Por otro lado, luego de realizar esto fijate este tema del acceso desde las pcs, en el setnet32 donde tenes la configuración de conexion al servidor, fijate que en vez del nombre del server de informix este la direccion IP.
UPDATE_STATISTICS_PLAN.SQL (7.75 KB)
Buen día,
Dónde podemos descargar una versión de Informix más nueva y qué versión recomiendan instalar? Tenemos una versión muy vieja (10.0.0) corriendo en un servidor RH4
Vamos a instalar un servidor nuevo y hacer un import de la base productiva actual.
Adjunto la salida del onconfig de de nuestra DB actual
Gracias.
onconfig.ol_hitaliano.txt (12 KB)
Hola, nos podrán ayudar, el sistema está muy complicado y es época de inscripciones y carga de notas.
Queremos empezar la instalación de un nuevo entorno y hasta tenerlo tunear lo más posible el actual. En este momento con 67 sesiones concurrentes se hace imposible trabajar. Esto empezó a pasar hace algunas semanas, no hubo cambio de versión ni actualizaciones. Se corrieron las estadísticas de la base varias veces. Se hizo el import del backup de una base, pero no hay mejoras. El tema de los extends no aplica según lo que investigué a la versión que tenemos de Informix si no a partir de la 11.
Muchas gracias
Pablo, te adjunto un archivo que al ejecutarlo arma una sentencias que actualizan las estadisticas en las tablas de las bases por cada indice que tiene cada tabla.
Por favor correrlo y vean si mejora. Archivo: UPDATE_STATISTICS_PLAN.sql
Igualmente me parece que el problema no viene por aca sino es algun problema de red.
Esto suele pasar cuando el servidor informix no encuentra cual fue la pc donde esta la sesión que le hizo una solicitud y entonces va pc por pc de la red hasta encontrar cual fue la que se lo pidió.
Por eso les pediamos que hagan lo siguiente:
Si los dos estan lentos, entonces el problema es de performance de la base. Corran esa actualizacion de estadisticas y vuelvan a probar. Si aun esta lento puede ser que haya indices que falten (que se hayan borrado… es raro)…
Si 1 es rapido y 2 es lento, entonces vean si en la configuracion del cliente (SetNet32) que en la solapa Server Information, en los datos Host Name, ingresar la ip del servidor informix en vez del nombre del server, y en Service Name el nro de puerto en vez del nombre, dato
Adjunto una imagen.
UPDATE_STATISTICS_PLAN.SQL (7.75 KB)
Por lo que comentas en el ultimo mensaje, instalaron una nueva version de informix?
Realizaron cambios en la configuracion del motor adaptandolo al server donde esta corriendo? (memoria, cpu, disco)…
Pueden enviar algunas caracteristicas del servidor (cantidad de memoria fisica, cantidad de cpu, sistema operativo…) y el archivo ONCONFIG ?
Para ver si es simplemente un problema de la configuracion y optimización de esa instancia de informix.
Hola Alejandro,
El archivo onconfig lo envié en el anterior posteo. No hicimos modificaciones al servidor ni a la base. El archivo update_statistics ya lo ejecutamos en su momento.
El equipo es un Red Hat Enterprise Linux release 4 (Nahant) virtualizado 4GB de memoria, CPU Xeon de 4 núcleos (el red hat usa solo 2)
Saludos
Perdon Pablo, no habia visto el onconfig, hay bastante por hacer sobre este archivo, pero comencemos por algo que puede mejorar rapidamente :
ROOTNAME rootdbs # Root dbspace name
ROOTPATH /dbspaces/rootdbs # Path for device containing root dbspace
ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes)
ROOTSIZE 30000 # Size of root dbspace (Kbytes)
Este es muy poco espacio del rootdbspace. Ya que el motor usa lo que queda libre de este dbspace para temas temporales en creaciones de indices, tablas temporales, etc.
Vean de agregar un chunk de 2gb a este dbspce.
MIRROR 0 # Mirroring flag (Yes = 1, No = 0)
MIRRORPATH # Path for device containing mirrored root
MIRROROFFSET 0 # Offset into mirrored device (Kbytes)
PHYSDBS dbs_phy # Location (dbspace) of physical log
PHYSFILE 49946 # Physical log file size (Kbytes)
LOGFILES 29 # Number of logical log files
LOGSIZE 2000 # Logical log size (Kbytes)
LOG_BACKUP_MODE MANUAL # Logical log backup mode (MANUAL, CONT)
Debería estar en continuo (CONT). Para que cuando se llene cada logical logs de esos 29 se realice backup automatico.Por lo que veo ahora esta en NULL (Parámetro LTAPEDEV)
#DBCREATE_PERMISSION informix
IFX_EXTEND_ROLE 0 # To control the usage of EXTEND role.
TBLTBLFIRST 0 # First extent size (Kbytes) (0 = default)
TBLTBLNEXT 0 # Next extent size (Kbytes) (0 = default)
MSGPATH /opt/informix/online.log # System message log file path
CONSOLE /dev/console # System console message path
ALARMPROGRAM /usr/informix/etc/alarmprogram.sh # Alarm program path
#ALARMPROGRAM /usr/informix/etc/no_log.sh # Alarm program path
ALRM_ALL_EVENTS 0 # Triggers ALARMPROGRAM for any event occur
TBLSPACE_STATS 1 # Maintain tblspace statistics
TAPEDEV /dev/null # Tape device path
TAPEBLK 32 # Tape block size (Kbytes)
TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes)
LTAPEDEV /dev/null # Log tape device path
LTAPEBLK 32 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)
Deberian crear un archivo donde hacer backup de los logical logs si quieren tener el los y amplicar ese tamaño del archivo al espacio maximo que tenga el disco donde vayan a hacer backup.
Pueden serguir dejandolo en null (LTAPEDEV /dev/null) lo mismo que el TAPEDEV, pero en algun momento luego que superen este tema de la performance es configurar bien este tema de los backups.
STAGEBLOB # Informix Dynamic Server staging area
SERVERNUM 0 # Unique id corresponding to a OnLine instance
DBSERVERNAME ol_hitaliano # Name of default database server
DBSERVERALIASES # List of alternate dbservernames
NETTYPE soctcp,4,90,NET
NETTYPE ipcshm,4,90,CPU
DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env.
RESIDENT 0 # Forced residency flag (Yes = 1, No = 0)
MULTIPROCESSOR 0 # 0 for single-processor, 1 for multi-processor
Si el servidor tiene mas de un procesador, aqui deberia tener el valor 1
NUMCPUVPS 1 # Number of user (cpu) vps
Este valor deben cambiarlo por la cantidad de procesadores disponibles:
Ver: https://www.ibm.com/support/knowledgecenter/en/SSGU8G_11.50.0/com.ibm.perf.doc/ids_prf_091.htm
SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one
NOAGE 0 # Process aging
AFF_SPROC 0 # Affinity start processor
AFF_NPROCS 0 # Affinity number of processors
LOCKS 2000 # Maximum number of locks
Aumentar este valor a 50000:
LOCKS 50000
NUMAIOVPS # Number of IO vps
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 32 # Logical log buffer size (Kbytes)
CLEANERS 1 # Number of buffer cleaner processes
SHMBASE 0x44000000L # Shared memory base address
SHMVIRTSIZE 8192 # initial virtual shared memory segment size
Ampliar este valor a 256mb
SHMVIRTSIZE 262144
SHMADD 8192 # Size of new shared memory segments (Kbytes)
Ampliar este valor a 64mb
SHMADD 65536
SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
TXTIMEOUT 300 # Transaction timeout (in sec)
STACKSIZE 32 # Stack size (Kbytes)
DYNAMIC_LOGS 2
LTXHWM 70
LTXEHWM 80
OFF_RECVRY_THREADS 10 # Default number of offline worker threads
ON_RECVRY_THREADS 1 # Default number of online worker threads
DRAUTO 0 # DR automatic switchover
DRINTERVAL 30 # DR max time between DR buffer flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /usr/informix/etc/dr.lostfound # DR lost+found file path
DRIDXAUTO 0 # DR automatic index repair. 0=off, 1=on
CDR_EVALTHREADS 1,2 # evaluator threads (per-cpu-vp,additional)
CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds)
CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR queue (Kbytes)
CDR_NIFCOMPRESS 0 # Link level compression (-1 never, 0 none, 9 max)
CDR_SERIAL 0 # Serial Column Sequence
CDR_DBSPACE # dbspace for syscdr database
CDR_QHDR_DBSPACE # CDR queue dbspace (default same as catalog)
CDR_QDATA_SBSPACE # List of CDR queue smart blob spaces
CDR_MAX_DYNAMIC_LOGS 0 # Dynamic log addition disabled by default
BAR_ACT_LOG /usr/informix/bar_act.log # ON-Bar Log file - not in /tmp please
BAR_DEBUG_LOG /usr/informix/bar_dbug.log # ON-Bar Debug Log - not in /tmp please
BAR_MAX_BACKUP 0
BAR_RETRY 1
BAR_NB_XPORT_COUNT 20
BAR_XFER_BUF_SIZE 31
RESTARTABLE_RESTORE ON
BAR_PROGRESS_FREQ 0
ISM_DATA_POOL ISMData
ISM_LOG_POOL ISMLogs
RA_PAGES # Number of pages to attempt to read ahead
RA_THRESHOLD # Number of pages left before next group
DBSPACETEMP dbs_tmp # Default temp dbspaces
Verifiquen que el dbspace temporal “dbs_tmp” este online.
Corran el comando: onstat -d
Podran ver si el dbspace temporal dbs_tmp esta siendo utilizado
DUMPDIR /tmp # Preserve diagnostics in this directory
DUMPSHMEM 1 # Dump a copy of shared memory
DUMPGCORE 0 # Dump a core image using ‘gcore’
DUMPCORE 0 # Dump a core image (Warning:this aborts OnLine)
DUMPCNT 1 # Number of shared memory or gcore dumps for
# a single user’s session
FILLFACTOR 90 # Fill factor for building indexes
USEOSTIME 0 # 0: use internal time(fast), 1: get time from OS(slow)
MAX_PDQPRIORITY 100 # Maximum allowed pdqpriority
DS_MAX_QUERIES # Maximum number of decision support queries
DS_TOTAL_MEMORY # Decision support memory (Kbytes)
DS_MAX_SCANS 1048576 # Maximum number of decision support scans
DS_NONPDQ_QUERY_MEM 128 # Non PDQ query memory (Kbytes)
DATASKIP # List of dbspaces to skip
OPTCOMPIND 2 # To hint the optimizer
DIRECTIVES 1 # Optimizer DIRECTIVES ON (1/Default) or OFF (0)
ONDBSPACEDOWN 2 # Dbspace down option: 0 = CONTINUE, 1 = ABORT, 2 = WAIT
OPCACHEMAX 0 # Maximum optical cache size (Kbytes)
HETERO_COMMIT 0
SBSPACENAME # Default smartblob space name - this is where blobs
# go if no sbspace is specified when the smartblob is
# created. It is also used by some datablades as
# the location to put their smartblobs.
SYSSBSPACENAME # Default smartblob space for use by the Informix
# Server. This is used primarily for Informix Server
# system statistics collection.
BLOCKTIMEOUT 3600 # Default timeout for system block
SYSALARMPROGRAM /opt/informix/etc/evidence.sh # System Alarm program path
OPT_GOAL -1
ALLOW_NEWLINE 0 # embedded newlines(Yes = 1, No = 0 or anything but 1)
#Create Index Online Shared Memory usage limitation
ONLIDX_MAXMEM 5120 # Per pool per index (Kbytes)
#Timeout for client connection request
LISTEN_TIMEOUT 10 # Timeout (in Seconds)
#Following are the deprecated configuration parameters, instead of these
#use BUFFERPOOL configuration parameter
#BUFFERS, LRUS, LRU_MIN_DIRTY, LRU_MAX_DIRTY
#VPCLASS jvp,num=1 # Number of JVPs to start with
JVPJAVAHOME /usr/informix/extend/krakatoa/jre # JRE installation root directory
JVPHOME /usr/informix/extend/krakatoa # Krakatoa installation directory
JVPPROPFILE /usr/informix/extend/krakatoa/.jvpprops # JVP property file
JVPLOGFILE /usr/informix/jvp.log # JVP log file.
JDKVERSION 1.3 # JDK version supported by this server
JVPJAVALIB /bin
JVPJAVAVM jsig:hpi:jvm:java:net:zip:jpeg
#To display jni call
#JVPARGS -verbose:jni
#JVPCLASSPATH /usr/informix/extend/krakatoa/krakatoa_g.jar:/usr/informix/extend/krakatoa/jdbc_g.jar
JVPCLASSPATH /usr/informix/extend/krakatoa/krakatoa.jar:/usr/informix/extend/krakatoa/jdbc.jar
BUFFERPOOL default,buffers=1000,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.000000
BUFFERPOOL size=2K,buffers=1000,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.000000
Gracias Alejandro, vamos a aplicar los cambios y ver como resultan.
Por otro lado la ejecución del update_statistics arrojó como resultado 2946 row unloaded
Saludos
Pablo
Ese script del update statistics lo que hace arma la sentencias UPDATE STATISTICS sobre cada tabla e indices…
Lo que tienen que hacer es recuperar el resultado que devuelve esa query y ejecutarla en la base.
Ok, entiendo lo del SQL de update statistics. Lo hacemos.
Por otro lado quería consultarte sobre este punto del onconfig:
ROOTSIZE 30000 # Size of root dbspace (Kbytes)
Este es muy poco espacio del rootdbspace. Ya que el motor usa lo que queda libre de este dbspace para temas temporales en creaciones de indices, tablas temporales, etc.
Vean de agregar un chunk de 2gb a este dbspce.
Nos podrías indicar de que manera hacer eso?
Slds
Hola, suponiendo que lo tengan configurado con coocked files, deben crear un archivo vacío con los permisos adecuados (dueño informix, 770)
por ejemplo en /dbspaces/rootdbs.001
Luego con el comando onspaces agregar un chunk al rootdbs
onspaces -a rootdbs -p /dbspaces/rootdbs.001 -o 0 -s 2048000
Saludos
Luego de agregar el nuevo chunk al rootdbs, tienen que hacer un backup de nivel 0 para que lo tome.
Lo haces con el comando:
Ontape -s -L 0
Recorda, que ahora tenes el backup a NULL, es decir que no estas haciendo backup sino que el informix marca como que hiciste backup pero no esta bajando los datos a ningun archivo.
Para configurar esto es que tenes que cambiar los parametros:
TAPEDEV /dev/null # Tape device path >> LTAPEDEV /dev/archivo_backup.bak
TAPEBLK 32 # Tape block size (Kbytes)
TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes) TAPESIZE <espacio a asignar al archivo de backup, como maximo debería ser el espacio libre que tengas en ese disco, expresado en Kbytes.
TAPESIZE
Lo mismo para el backup de los logical logs, los parametros:
LTAPEDEV /dev/null # Log tape device path
LTAPEBLK 32 # Log tape block size (Kbytes)
LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes)
Para verificar que el espacio del nuevo chunk en el dbspace “rootdbs” fue agregado y el motor lo esta usando, corre el comando onstat -d y deberias verlo alli listado. adjunto un ejemplo:
En la imagen veras que el dbspace “datosdbs” (dbspace 3) tiene 7 chunks (archivos fisicos), el rootdbs y el dbspace temporal solo un chunk cada uno.
Hola Pablo
Sumo una recomendacion , que a mi criterio es importante para la performance, ya que apunta a disminuir los accesos a disco
Las lineas del onconfig:
BUFFERPOOL default,buffers=1000,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.000000
BUFFERPOOL size=2K,buffers=1000,lrus=8,lru_min_dirty=50.000000,lru_max_dirty=60.000000
Modificarlas a
BUFFERPOOL default,buffers=20000,lrus=8,lru_min_dirty=5.000000,lru_max_dirty=10.000000
BUFFERPOOL size=2K,buffers=10000,lrus=8,lru_min_dirty=5.000000,lru_max_dirty=10.000000
Si después de levantar informix, todavia hay memoria libre en el server, entonces es posible seguir incrementando los parámetros buffers de ambas lineas. principalmente aumentar el que dice default.
Saludos
Ignacio
Pablo, pudiste hacer los cambios en el ONCONFIG?
Hola Alejandro, Damián,
Implementamos todos los cambios excepto el de ampliar el ROOTSIZE, que lo vamos a hacer cuando podamos reiniciar el servidor. Con todos los demás la performance mejoró notablemente.
No hay lentitud y en horario pico mantiene la performance,
Muchas gracias!
Saludos