Problema engorde y rendimiento

[Toni]

Hola Guillotmarc,

Como comentaba este procedimiento recalcula (suma y agrupa el contenido de unas tablas y actualiza con el resultado otras) las tablas que agrupan tienen al rededor de 11000 registros y la que actualiza tambien.

He comprobado que no hay triggers implicados.

Se que esto no es lo mas optimo, pero inicialmente funciona bastane bien. A medida que va 'acumulando' versiones de los registros y va aumentando el tamaño de la base de datos, cuando el tamaño se multiplicado ya 5 el rendimiento cae en picado.

¿Pero estos registros no tendrian que influirle tanto, no?

¿la unica manera de mejorar el rendimiento sera hacer backup-restore?

Muchas gracias.

[[duilioisola]]

Habría que ver cómo es ese procedimiento. Tendrías que ver si puedes aplicar esta idea a tu procedimiento:

Código SQL [-]
/*Por cada registro tratado hago un update*/
declare variable importe double precision;
begin
   for select importe from tabla
       where ...
       into :importe
   do
   begin
       update totales 
       set importe=importe + :importe
       where ...;
   end
end

Código SQL [-]
/*Acumulo en una variable y hago un solo update final*/
declare variable importe double precision;
declare variable total double precision;
begin
   for select importe from tabla
       where ...
       into :importe
   do
   begin
       Total = Total + importe;
   end
   update totales 
   set importe=total
   where ...;
end

[Toni]

Hola duilioisola,

En el procedimiento realizo un for select que agrupa por los campos clave de la tabla que actualizo, con lo que ya realiza una sola actualizacion por registro. Lo que pasa es que hay bastantes registros implicados y cada ejecucion del procedimiento pues supone como unos 50.000 registros actualizados. Y este procedimiento se ejecuta 20-30 veces diariamente.

Muchas gracias por tu interes.

[Estifmauin]

Hola Toni.
Todo lo que estáis discutiendo es muy interesante... yo soy fan de la optimización y depuración de código, pero tu caso me recuerda a algo que me pasó con un proyecto que realicé hace algún tiempo.
Se trataba de un sistema multihilo con muuuchas llamadas a procedimientos almacenados, y tanto la base de datos como la RAM que consumía el proceso fbserver se disparaban.
Revise... investigué... optimicé... pero no se corregía.

Durante unos meses el cliente debía reiniciar una vez por semana el servicio FB para que liberara la RAM, y también compactar la bbdd.

Hasta que salió FB 2.5 y su soporte transaccional para procedimientos almacenados y triggers. Todo solucionado.

Espero que esto te ayude, pues con versiones anteriores la cosa puede que no tenga remedio.

Nota: ojo con los campos blob en vitas!

[guillotmarc]

Hola.

Empezado por Estifmauin

Hola Toni.
Todo lo que estáis discutiendo es muy interesante... yo soy fan de la optimización y depuración de código, pero tu caso me recuerda a algo que me pasó con un proyecto que realicé hace algún tiempo.
Se trataba de un sistema multihilo con muuuchas llamadas a procedimientos almacenados, y tanto la base de datos como la RAM que consumía el proceso fbserver se disparaban.
Revise... investigué... optimicé... pero no se corregía.

Durante unos meses el cliente debía reiniciar una vez por semana el servicio FB para que liberara la RAM, y también compactar la bbdd.

Hasta que salió FB 2.5 y su soporte transaccional para procedimientos almacenados y triggers. Todo solucionado.

Espero que esto te ayude, pues con versiones anteriores la cosa puede que no tenga remedio.

Nota: ojo con los campos blob en vitas!

Por lo que dices, a mi me da la impresión de que seguramente tendrías el mismo problema que Toni : se te quedaban transacciones abiertas. Por eso al utilizar FB 2.5, al gestionar manualmente las transacciones dentro de los procedimientos almacenados, entonces ya se finalizaron correctamente y se acabaron los problemas.

Hasta donde yo sé, no hay nada malo con FB 1.5, no es que pueda soportar menos tamaño de la base de datos ni carga de transacciones que Firebird 2.5.

Saludos.

[Estifmauin]

Marc.
Mi mayor problema era el consumo incontrolado de ram... como era una sistema de funcionamiento ininterrumpido, al cabo de 2 semanas se agotaba la ram, y pof! (y para colmo, un tal Murphy se encargaba de que petase el sábado por la tarde).

Lo probé casi todo. Incluso llegué a que cada vez que un hilo necesitaba ejecutar un pa, creaba una conexión y los objetos necesarios, abría y cerraba las transacciones y luego destruía todo. Y tampoco funcionaba.
Sé que en alguna parte había algo mal, pero me volví loco y no lo encontré.

Debo aclarar que era un sistema ado+odbc, y pensé que el problema estaba en odbc. probé otros drivers y también oledb, pero la cosa seguía igual...

Cuando estaba a punto de suicidarme, apareció fb 2.5 y ¡aleluya! todo perfecto. Creo que me moriré sin saber dónde estaba el fallo, pero como tengo otras cosas en marcha... Tal vez en otra vida retome el tema.

Por esto, y por muchos otros motivos recomiendo migrar a Firebird 2.5.

Y ahora una queja al cielo: Estoy un poco harto de leer que ado no es adecuado para conectarse a bbdd grandes. Yo he usado de todo, y creo que ado es muy válido. Si os parece, podemos abrir un hilo para discutir esto.

[guillotmarc]

Hola.

Pues sí, tienes razón, con lo que probaste está claro que no eran las transacciones. Además si el problema solo estaba en el consumo de RAM, entonces no tengo ni idea, no recuerdo haber leído nada relacionado.

Saludos.

[Toni]

Hola a todos,

Posiblemente tenga razon Estifmauin, porque esta aplicacion con la misma base de dato esta instalada en varios sitios sin problema alguno. Y en este caso que me da problemas la unica personalizacion importante es el dichoso procedimiento que actualiza muchos registros. Es en el unico caso que se nota la falta de rendimiento, aunque tambien he de decir que principalmente la falta de rendimiento donde mas se nota es al llamar al mismo procedimiento curiosamente. El resto de la aplicacion que realiza todo tipo de consultas a la base de datos funciona con normalidad.

He programado diariamente con programador de tareas de Windows, que realice un gfix cada dia por la noche y el rendimiento mejora, pero no ha llegado al medio dia y ya se nota que se vuelve a poner lenta.

Ya me gustaria migrarla la base de datos a FB2.5 pero creo que puede ser una locura la de problemas que me puedo encontrar y que dificilmente voy poder preveer en modo test.

Muchas gracias a todos.

[guillotmarc]

Empezado por Toni

Hola Guillotmarc,

Como comentaba este procedimiento recalcula (suma y agrupa el contenido de unas tablas y actualiza con el resultado otras) las tablas que agrupan tienen al rededor de 11000 registros y la que actualiza tambien.

He comprobado que no hay triggers implicados.

Se que esto no es lo mas optimo, pero inicialmente funciona bastane bien. A medida que va 'acumulando' versiones de los registros y va aumentando el tamaño de la base de datos, cuando el tamaño se multiplicado ya 5 el rendimiento cae en picado.

¿Pero estos registros no tendrian que influirle tanto, no?

¿la unica manera de mejorar el rendimiento sera hacer backup-restore?

Muchas gracias.

Todo apunta a que sigues teniendo como mínimo una transacción que se queda siempre abierta, por lo que no se puede ejecutar la recolección de basura de Firebird, y no se recupera el espacio usado por el versionado de productos, aparte de finalmente caerse el rendimiento de la base datos.

Tienes todos los síntomas relatados en este artículo de Firebird :

http://www.ibphoenix.com/main.nfs?a=...x&page=ibp_oit

Tienes que revisar todas las transacciones de tu programa, y verificar que se finalicen inmediatamente una vez terminada su tarea. Nunca dejes transacciones abiertas a la espera de que el usuario haga algo, y no confíes en las transacciones implícitas de los componentes, puesto que si hay una transacción abierta, ejecutarán su consulta dentro de esa transacción y la dejarán como estaba, es decir abierta. Programa tu mismo el inicio y commit de las transacciones en cada actualización de la base de datos.

Saludos.

[Casimiro Noteví]

Estoy de acuerdo con lo comentado por guillotmarc, hay alguna transacción que se te está escapando, no es lógico que disminuya el rendimiento de la base de datos porque ocupe más. Está claro, por lo que cuentas de que al hacer backup/restore (o una 'limpieza') todo vuelve a ir bien.