Sistema se pone lento con el paso de los dias.

[jcapitan]

Hola amigos, tengo un problemita que todavía no consigo dar con la solución.
Les cuento: Tengo un sistema que esta trabjando las 24 hrs los 365 dias del año, usuarios se logean y salen del sistema de acuerdo a sus horarios, el sistema funciona bien, con rapidez al momento de hacer una consulta, al momento de guardar un registro, etc... pero al paso de los dias, aproximadamente 2 meses o un poquito más, el sistema se pone lento. Me he dado cuenta que si renicio el server de firebird que obviamente se encuentra en un servidor todo vuelve a la normalidad. Sin embargo me han comentado que cuando hay muchos ingresos, es decir unos 7 usuarios están metiendo información sienten que se pone un poquito lento no tanto como al paso de los dias. Cabe mencionar que el sistema refresca tablas cuando un usuario mete información, es decir los demás usuarios ven el cambio en pantalla.

Que puede estar pasando en el servidor que al reiniarlo vuelve a la normalidad???? Porque cuando coinciden muchos usuarios al meter información lo siente el sistema?? Qué me pueden aconsejar para monitorizar y saber el problema??? Qupe pruebas puedo y debo hacer???

Mil gracias por su apoyo de antemano.

[Casimiro Notevi]

Deberías informarnos de que versión de firebird estás hablando, el tipo (SS o CS), qué parámetros en transacciones, si tienes forcedwrites activo o no, si usas cache, si has cambiado algún parámetro predeterminado, qué características físicas (discos, memoria, etc.) tiene el servidor, qué sistema operativo tiene, etc, etc, etc...

[jcapitan]

Ok. Gracias por su pronta respuesta.
Servidor:
En el servidor tengo instalado FireBird 2.5.0.25920 CS, en los equipos (el ciente de la misma versión), el servidor tiene Windows Server 2003 R2 Enterprise Edition SP2, 4Gb en RAM, Intel XEON 3Ghz, cuenta con dos particiones C: de 12 Gb con espcio libre en estos momentos de 6.20 Gb y D: (donde radican la base de datos) con 668 GB y 656 GB libres.
Servidor Firebird: La configuración es la que trae desde el momento de la instalación (predeterminado), lo unico que he modificado es el archivo de alias para las rutas.
Borland Delphi 2010.
En cuanto al componente que utilizo para conectarme es el FIBPlus 6.9.9
Y los parámetros de:
Transacción:
...
..
Timeout | 0
TimeoutAction | TARollback
TPBMode | tpbReadCommitted
TRParams | Empty
UserKindTransaction | NoUserKind

En cuanto a las tablas les tengo habilitada la opción de autocommit
Manejo eventos, estos para hacer los refresh de las tablas modificadas por los usuarios y con esto que se refleje en todos.

No uso cache.

[rastafarey]

Hermanito con ese equipo que tienes todo deberia funcionar bien. A menos que se estes quedando muchas transacciones en el limbo.

Lee esto Optimizando firebird

[Neftali [Germán.Estévez]]

Deberías utilizar la herramientas de Windows Server para monitorizar las conexiones al servidor, datos de subida y bajada, estado de la RAM,... para saber si puede haber algun cuello de botella (debido al servidor).

Dentro de las herramientas Administrativas tienes el "Performance Tools" para poder activar diferentes Alertas y sensores.

[guillotmarc]

Estoy de acuerdo con rastafarey.

Como suele ocurrir en la inmensa mayoría de ocasiones que se dan estos síntomas (lentitud gradual de la base de datos), la razón más probable es una pobre implementación de las transacciones que no las cierra adecuadamente.

Lee este hilo para comprobar las transacciones que aún tienes abiertas y su antiguedad.

http://www.clubdelphi.com/foros/showthread.php?t=55887

NOTA: En el hilo también se muestra una sentencia para finalizar todas las transacciones, cuyo efecto sería parecido a reiniciar el Servidor.

Si como todo apunta, te encuentras que tienes muchas transacciones abiertas, y algunas muy antiguas, tendrás que corregir el programa para arreglar el problema.

Las transacciones se tienen que finalizar lo antes posible.

Con Timeout a 0 las transacciones no se cierran hasta que tú no se lo digas. Pon el Timeout a 1 si quieres que se cierren enseguida (es como lo tengo yo).

Saludos.

[Casimiro Notevi]

Empezado por guillotmarc

[..]
Lee este hilo para comprobar las transacciones que aún tienes abiertas y su antiguedad.
http://www.clubdelphi.com/foros/showthread.php?t=55887
NOTA: En el hilo también se muestra una sentencia para finalizar todas las transacciones, cuyo efecto sería parecido a reiniciar el Servidor.
[..]

No había seguido ese hilo hasta el final, ¡qué interesante!.

[jcapitan]

Mil gracias por su apoyo y consejos, checaré bien lo que me recomiendan, y les comento como me fue.
De nuevo, Casimiro Notevi, rastafarey, Neftali, guillotmarc y a toda la comunidad de Club Delphi Gracias Mil.

[jcapitan]

Bueno aqui estoy de nuevo..

Estuve monitoreando la base de datos con Sinática Monitor, y veo solo una transacción viva por ip.

Mencionan que tengo que cerrar la transacción lo mas pronto posible, pero como mantengo información en tiempo real en un grid para los usuarios, es decir cuando alguien modifique un registro se refleje en los demás.

Ando muy perdido en cuanto las transacciones segun veo. Ojala me puedan recomendar una lectura o ejemplos. Para aplicaciones de este tipo.

Les menciono la aplicación, los usuarios estan divididos en 2 grupos.
Grupo 1. Reciben llamadas y capturan información en "papeletas".
Grupo 2. Visualizan en tiempo real lo que el Grupo 2 está capturando, y atiende una de ellas metiendo información también en esta papeleta; si un usuario del grupo 1 cambió un campo del registro, en el grid que tiene en pantalla se muestra el cambio en tiempo real.

(Realmente todos ven lo que los demas capturan, pues tienen ventanas abiertas con grids que muestran información de folio, dirección, etc)

Cuando se cierran las papeletas (ya fueron atendidas) se mueve la información a otra tabla que es el historial (esta no la tienen pantalla pues son una cantidad muy grande de registros), de esta manera los refresh sera sobre la tabla que no tiene tantos registros, creo que de esta manera es más óptimo, si estoy mal por favor me corrigen.

En este caso como debo manejar las transacciones si es necesario que la información se esté refrescando y en pantalla.

[Gallosuarez]

JCapitan:

Tengo un pregunta: ¿Cual es el mecanismo que utilizas para poder ver que alguien ha hecho un inserción o modificación en las tablas de datos?

Quiero suponer que ese mecanismo lo estás implementando utilizando Eventos desde el mismo motor de la base de datos. Si no es así, el hacerlo a través de un "pooling" te degrada muchísimo el desempeño de la base de datos. Y por ahí puede estar el problema.

Saludos,
Gerardo Suárez Trejo

PD. Es mas eficiente ver la información en tiempo real cuando cualquier usuario hace un "commit" (ya sea para insertar o modificar un registro) y se lanza un aviso a través de un evento a todos los usuarios que se hayan suscrito a dicho evento.

PD2. Ouch!, no había leido bien tu "post" donde dices que manejas eventos, para poder ver cuando hay cambios en la base de datos. Me imagino entonces que implementaste una forma de leer solo el registro que se haya modificado o insertado (no cargar nuevamente todo el Dataset). Y asegurate de cambiar el Time Out a 1 (es de suma importancia para que las transacciones se hagan inmediatamente). Saludos nuevamente ...

[jcapitan]

Efectivamente lo hago através de eventos desdela base de datos.

Los cuales los tengo nombrados como
post_mod_regs_reales
post_mod_regs_detalles
...
..
. etc

los cuales los tengo capturados en el sistema con el componente TSIBfibEventAlerter, pero como mencionas realmente hago un fullrefresh de la tabla es decir de la consulta.

Esta de esta forma: en un ventana muestro registros que estan en espera de ser atendidos (con estatus 1), en otra ventana los registros que estan siendo atendidos (estatus 2), y se pasan a la tabla de historial cuando el estatus es 3 (cerrados)

por lo que las consultas de las 2 ventanas (en espera y en atención) es una consulta sobre la misma tabla solo con parametro diferente (el estatus).

Estuve buscando información para actualizar como tu dices solo el registro que se modifico y no traer toda la consulta de nuevo pero no supe como hacerlo, es decir saber el folio (la llave) que sifrio cambio y traer solo ese registro. Si es posible esto le agradeceré me iluminen para aplicarlo.


Ahora, esto es lo que posiblemente me este alentando la aplicación con el paso de los dias???

Gracias, si necesitan mas información de la aplicación la pongo de inmediato.

[jcapitan]

Espero y no haya problema por poner una imagen mostrando como funciona la aplicación (a groso modo obviamente).

Pues como se muestra en la imagen, se muestran dos ventanas con su respectivo grid mostrando la información de acuerdo a la consulta (estatus 1 o estatus 2), el usuario puede tener abierta 1,2 o mas papeletas si así lo requiere y a la vez modificar cualquiera, y ese cambio se refleja en los grids y en las papeletas que tengan abiertas los demas usuarios, esto lo hago a través de eventos. y si pongo el timeout a 1 la información en los grid y las papeletas no se muestra y me dice que la tabla esta cerrada.

Espero y se pueda mejorar esto con su ayuda. Gracias.

[jcapitan]

He checado con gfix -list , para que me muestre las transacciones que esten en el limbo y no me muestra alguna, esto quiere decir que no va por ese lado. Estuve leyendo por ahi que utilizando el gfix -sweep de manera manual me ayudara en que mi sistema no se sienta lento ya que por default lo tiene activado de manera automatica y puede ejecutarse en un momento en que los usuario esten haciendo mucho movimientos, y lo sientan lento.

Otro que se me ocurre es que las actualizaciones (refresh) que le hago a las tablas y a la vez a las papeletas (campos, variables, etc) las haga através de threads para evitar el retardo de actualización, ya que esto creo que es el retardo que ven los usuarios.

Tengo que probar, no se si hay algo más que pueda hacer para mejorar la velocidad de la aplicación. Algo más por checar.

Gracias.

[Gallosuarez]

JCapitan:

Yo lo haría de la siguiente forma:
1.Crear una tabla de cambios (bitácora de cambios). Crear una secuencia para esta tabla (SEC_BITACORA_CAMBIO). Crear un Trigguer (Aferter Insert/Update).

Código SQL [-]
CREATE TABLE BITACORA_CAMBIOS (
    ID            INTEGER NOT NULL,
    TIPO          CHAR(1) COLLATE ES_ES_CI_AI,
    TABLA_NOMBRE  VARCHAR(31) COLLATE ES_ES_CI_AI,
    ID_REGISTRO   INTEGER,
    DIA_HORA      TIMESTAMP,
    USUARIO       VARCHAR(31) COLLATE ES_ES_CI_AI
);

COMMIT;

ALTER TABLE BITACORA_CAMBIOS ADD CONSTRAINT PK_BITACORA_CAMBIOS PRIMARY KEY (ID);

CREATE INDEX BITACORA_CAMBIOS_IDX1 ON BITACORA_CAMBIOS (DIA_HORA);

COMMIT;
SET TERM ^ ;

CREATE OR ALTER TRIGGER BITACORA_CAMBIOS_AIU0 FOR BITACORA_CAMBIOS
ACTIVE AFTER INSERT OR UPDATE POSITION 0
AS
BEGIN
  POST_EVENT 'Cambio';
END
^

SET TERM ; ^

COMMIT;

CREATE SEQUENCE SEC_BITACORA_CAMBIOS;
ALTER SEQUENCE SEC_BITACORA_CAMBIOS RESTART WITH 0;

COMMIT;

2. Crear Procedimiento Almacenado para registrar los cambios

Código SQL [-]
SET TERM ^ ;

CREATE OR ALTER PROCEDURE REGISTRA_CAMBIO(
    TIPO CHAR(1),
    TABLA_NOMBRE VARCHAR(31),
    ID_REGISTRO INTEGER)
AS
BEGIN
  INSERT INTO BITACORA_CAMBIOS
    (ID, TIPO, TABLA_NOMBRE, ID_REGISTRO, DIA_HORA, USUARIO)
  VALUES
    (GEN_ID(SEC_BITACORA_CAMBIOS, 1), :TIPO, :TABLA_NOMBRE, :ID_REGISTRO, CURRENT_TIMESTAMP, CURRENT_USER);
END^

SET TERM ; ^

3. Crear Triggers (After Insert/Update) para TODAS las tablas donde deseas saber si hubo cambios (pongo esto porque no se los detalles de esas tablas)

Código SQL [-]
IF (INSERTING) THEN
  EXECUTE PROCEDURE REGISTRA_CAMBIO 'I', 'Pon aqui el nombre de la tabla', NEW.ID <-(Pones aquí el ID de tu tabla);

IF (UPDATING AND (
  NEW.NOMBRE IS DISTINCT FROM OLD.NOMBRE OR
  NEW.APELLIDO IS DISTINCT FROM OLD.APELLIDO OR
  ETC, ETC, (Debes poner los campos donde quieras saber si hubo un cambio)
)) THEN
  EXECUTE PROCEDURE REGISTRA_CAMBIO 'C', 'Pon aqui el nombre de la tabla', NEW.ID <-(Pones aquí el ID de tu tabla);

3.Con esto tienes para saber exactamente en que tabla, y cual fue el registro que cambió después de una inserción o algún cambio.
Ahora, desde tu aplicación tienes que ejecutar una SQL para traer solo los últimos campos que se han insertado o sufrido un cambio. Al leer el campo de TIPO de la tabla BITACORA_CAMBIOS, si contiene un valor 'I', entonces fue una inserción, si tiene un valor de 'C', entonces fue un cambio.
Hay un parametro (no recuerdo cual es), de tus FIBPlus que te dice cuantas veces se ha disparado el POST_EVENT y este te sirve para saber cuantos campos tienes que leer o refrescar ¿Me explico?

Atte:
Gerardo Suárez Trejo

PD. Espero que te algo te sirva esto. Solo resta hacer una pequeñas adecuaciones para refrescar leer o refrescar el campo que se inserto. Si tienes dudas en esto dime y te lo explico un poco detallado (ya no quiero hacer mas largo este "post").

[jcapitan]

Mil gracias, probaré la solución planteada, si salen algunas dudas te las comunico. Gracias.

[rastafarey]

Hermanito para las notificaciones es un pelo larga la explicacion asi que vamos a la pratica. bajete ibobject. Esos componenete stren un ejemplo que te lo explica como un niño de pechos y si encuentras los fuentras veras el codigo de la notificacin es una soberana estupides pero ocn una solucion muy inteligente y sencilla.