Problema con la memoria

[jachguate]

Empezado por mlara

expr = '(378999.00+(37899.90+75978.00+...*0.0337';
  WHILE (counter < 100000) DO BEGIN
    calcvalue = evalexpr(expr);
    counter = counter + 1;
  END

Estas seguro que la expresión es tan compleja como las que se pasan en la aplicación real al evaluador...

Creo que debes tratar de simular la situación real antes de asegurar que no es la UDF la del problema...

Has sido vos mismo quien la ha hecho?

Si es así, creo que también podrias probarla desde otra aplicación hecha por vos, o sin meterla en una dll, para ver su comportamiento con respecto de la memoria.

hasta luego.

[guillotmarc]

Personalmente, en vista de todos los indicios, sigo opinando que la causa más probable de todos estos problemas, es que no has creado los índices adecuados para que el optimizador de consultas interno del motor de interbase, pueda ejecutar de forma eficiente las consultas involucradas dentro de los procedimientos almacenados.

Es muy distinto ejecutar una consulta, pudiendo aprovechar un índice para su ejecución, que hacerlo sin la ayuda de un índice. En el primer caso la localización de los registros involucrados es practicamente instantánea, puesto que la localización de un registro dentro de un árbol B-Tree balanceado solo requiere unas pocas lecturas de disco. En cambio si no se puede aprovechar ningún índice, hay que localizar los registros involucrados por fuerza bruta, leyendo todos los registros de la tabla, y ordenandolos en memória si el resultado está ordenado. Como puedes imaginar en este segundo caso, el consumo de memória y de CPU puede ser desorbitado, no es nada extraño ver consultas que tardan 1 hora en ejecutarse, y que después de crear un índice conveniente, pasan a ejecutars en décimas de segundo.

NOTA : En muchos casos, el índice para optimizar consultas complejas, y subconsultas, tiene que ser múltiple, es decir que conste de varios campos (como el ejemplo que propuse).

Deberías hacer unas cuantas comprobaciones muy sencillas. Por ejemplo, sustituir las UDFS por operaciones simples dentro de las consultas. Aunque evidentemente el resultado no será el mismo, el tiempo que tarden en ejecutarse los procedimientos sin UDFs te indicará claramente si el problema está en las UDFs o en los propios procedimientos.

Respecto a la memória, a mi no me parece tan raro que no se devuelva. Es algo bastante habitual ver sistemas en que una vez ampliado un buffer de memória, no la devuelven hasta finalizar el proceso, aunque ya no sea necesaria esa memória. Simplemente se la reservan por si acaso vuelve a ser necesaria.

Quizá puedas encontrar una función del API que te devuelva la memória, pero mientras tanto deberías probar la opción de cerrar la conexión, puesto que no necesitas más de 30 segundos para probarlo. Además es una solución que puede no gustar (evidentemente no es nada elegante), pero que funciona. Si no puedes cerrar la conexión porqué tienes datasets abiertos y no quieres que se cierren, entonces puedes tener simplemente dos conexiones. Una conexión para el funcionamiento normal de la aplicación, y otra para ejecutar estos procedimientos almacenados, que se abre antes de ejecutarlos y se cierra después.

Saludos.

[[mlara]]

Con respecto a lo que dice jachguate debo decir que el valor de expr es muy parecido a los valores reales con que trabaja la aplicación. Incluso en ocasiones las cadenas son mucho más largas y con más paréntesis y signos aritméticos (+, -, *, /). Por otro lado, fui yo quien construyó la UDF y la he probado como una aplicación de consola y también la he compilado en C++ Builder. Funciona bien. Pero bueno... retomando el tema...

...ya he he realizado pruebas sin hacer ningún llamado a la UDF. El resultado es el mismo. y entonces...? Lo que dice guillotmarc me parece muy acertado. De acuerdo a esto revisaré la implementación de la base de datos, y veré si efectivamente me hace falta algún índice. Debo comentar que el índice de los campos "Code", "Degree", y "Year" al que se hacía referencia más arriba sí existe:

CONSTRAINT "PayFunctDeg_PK_Year_Code_Degree" PRIMARY KEY ("Year", "Code", "Degree")

Pero claro, no es la única tabla que se consulta (recordar que ese procedimiento era sólo una muestra), así que voy a revisar las demás e informo de lo sucedido.

Finalmente, quisiera definitivamente encontrar una función que me permitiera liberar la memoria, pues aunque probé abriendo otra conexión con otro componente TIBDatabase tampoco funcionó. La única forma de liberar la memoria de Uso de PF y aumentar la memoria física disponible es cerrando TODAS las conexiones a la base de datos, es decir que si cierro todas las conexiones hechas desde la aplicación, pero por ejemplo IBConsole está conectado a la base de datos (no sólo al servidor sino también a la base de datos), la memoria no se libera, lo que me hace suponer que si tengo varios clientes conectados a la base de datos, y uno de ellos inicia el proceso de liquidación de nómina, no se podrá liberar la memoria a no ser de que todos los clientes se desconecten (me falta probarlo). Esto sí que es un problema, no creen?

Entonces sólo me queda por el momento revisar los índices de todas las tablas consultadas, y luego... pues ojalá encuentre la manera de liberar la memoria.

A pesar de no haber solucionado mi problema, hasta el momento sus aportes han sido muy valiosos. Gracias.

[[mlara]]

Debo decir que ha sido provechoso pero aún nos encontramos un poco lejos de poder liberar la memoria. Creé unos índices que hacían falta y este es el resultado:

Sin índices:

Diferencia entre valor de Uso de PF inicial y final: 235 MB
La memoria física disponible baja hasta: 5 MB
Tiempo de ejecución: 00:04:25

Con índices:

Diferencia entre valor de Uso de PF inicial y final: 215 MB
La memoria física disponible baja hasta: 5 MB
Tiempo de ejecución: 00:02:50

Como se puede ver lo más notorio es la disminución del tiempo de ejecución. Esto quiere decir que efectivamente por ese lado había problemas, pero el uso de PF baja sólo 20 MB. Y cuando termina el proceso de nuevo, todos los clientes deben estar desconectados para que el Uso de PF vuelva a su valor inicial, y para que la memoria física disponible suba hasta los 150 MB promedio (no había comentado que las pruebas las hago en un equipo con 256 MB de RAM).

Bueno, y por otro lado, consultando he encontrado que el componente TDatabaseInfo da alguna información acerca del uso de la memoria. Los parámetros que he monitoreado antes y después del proceso son:


Parámetro·········Valor antes···Valor después
---------·········-----------···-------------
CurrentMemory·······4.886.528·······6.078.464
MaxMemory···········5.028.960······31.273.632
NumBuffers··············1.013···········1.013

La interpretación la dejo pendiente. Por ahora... como dije, espero encontrar la solución.

[jachguate]

Quizas esto sea una burrada... pero has dejado un tiempo el servidor y aún asi no ha liberado la memoria? Siguiendo la línea de pensamiento sujerida por Marcos... quizas Interbase no devuelve inmediatamente la memoria... pero luego de un tiempo, debiera hacerlo, no?

Por otro lado... que otra cosa hace el servidor que es tan importante que la memoria vuelva a ser disponible tan rápido?

hasta luego.

[[mlara]]

El servidor (creo que el sistema operativo, y no interbase) pasado un tiempo devuelve la memoria física disponible, es decir que al terminar el proceso tenemos aprox. 5MB. Luego poco a poco se va devolviendo a razón de aprox. 500 KB o 1 MB por sg. hasta llegar a... bueno, no he esperado lo suficiente. Pero la memoria de Uso de PF (archivo de página) no se devuelve hasta que todos los clientes han desconectado de la base de datos.

El servidor no hace nada más importante que eso. El problema es que se realice el proceso de nuevo. Hice una prueba lanzando el SP principal 5 veces consecutivas, entonces el sistema anuncia que no tiene más memoria, que se está ampliando el tamaño del archivo de página en disco, y que el sistema podría no responder a peticiones de cualquier aplicación, y finalmente después de unos 30 sg. de haber anunciado esto el cliente se desconecta de la base de datos generando n errores (como 8 mensajes relacionados con accesos no permitidos a memoria). El archivo de página se libera (Uso de PF) y todo vuelve a la normalidad, pero entonces debo iniciar el cliente de nuevo para volver a comenzar. Esto no es precisamente una carta de presentación de un sistema que hace las cosas bien.