Problema con la memoria

[mlara]

Hola foro.

Estaría muy agradecido si alguien me pudiera ayudar con un caso que me trae medio trasnochado. Como el cuento hay que detallarlo un poco he puesto la consulta en la siguiente dirección:

http://www.unisoft.com.co/articulos/consulta.htm

De nuevo, muchas gracias por su colaboración.

[Gydba]

Buenas, buenas

Muy detallado tu problema :) sin embargo creo que la resolución será algo complicada y basada completamente en pruebas.

Un enlace tratado hace poco sobre las SPs y el tráfico de red:
http://www.clubdelphi.com/foros/showthread.php?t=7568

Un enlace sobre el uso de memoria:
http://www.clubdelphi.com/foros/showthread.php?t=6980

Siento no tener más tiempo para ayudarte en este problema, que además de ayudarte podría resultarle completamente útil a los demás (donde por supuesto me incluyo).

[guillotmarc]

Hola.

La forma más evidente de recuperar la memória, es cerrar la conexión y volverla a abrir. Respecto a limitar la memória que pueda usar la solicitud, yo no lo intentaría, puesto que está claro que necestia mucha memória para atender al procedimiento, y si no puede disponer de ella, tendrá que utilizar archivos temporales en el servidor, cuanto más proceso se pueda ejecutar sobre memória, antes terminará.

Respecto al uso del 100% de la CPU, ¿ es un problema ?. Está claro que cuanta más CPU se destine al proceso, antes terminará.

En todo caso, visto la cantidad de memória consumida, y tiempo del procesador, ¿ estás seguro que has definido los índices adecuados para agilizar el proceso ?. Una consulta típica en tu ejemplo es :

SELECT "Expenses" FROM "PayFunctDeg" WHERE "Code" = :in_mt_function AND "Degree" = :in_mt_degree AND "Year" = :in_in_refyear INTO :refvalue

Si defines un índice en la tabla PayFunctDeg, que contenga los campo Code, Degree y Year, agilizas de una forma drástica su ejecución. (Tanto en CPU como en Memoria).

Para comprobar que no necesitas ningún índice, comprueba los PLANes de ejecución de las consultas involucradas.

Saludos.

[jachguate]

Con respecto a que la Memoria queda utilizada... aun cuando vos lo negues... yo creo que valdria la pena revisar el modelo de liberación de memoria que se usa al llamar a las funciones de la UDF.

No veo sentido a que interbase/firebird siga consumiendo memoria después de terminado el proceso y hasta que se cierre la sesión...

[mlara]

No veo sentido a que interbase/firebird siga consumiendo memoria después de terminado el proceso y hasta que se cierre la sesión...

Eso mismo he pensado. Por eso construí el procedimiento que llama 100.000 veces la UDF para saber si ahí estaba el problema. El resultado es que prácticamente no consume memoria. El código dentro del SP de prueba es algo así como:


DECLARE VARIABLE counter INTEGER;

BEGIN
counter = 0;
expr = '(378999.00+(37899.90+75978.00+113600.00+115800.00+0.00)+0.00*0.00+22160.00*0.00+2580.00*23.00+45000 .00*1.00)*0.04+378999.00*0.0337';
WHILE (counter < 100000) DO BEGIN
calcvalue = evalexpr(expr);
counter = counter + 1;
END

SUSPEND;

END

Como puede verse en el código, la UDF es un evaluador de expresiones matemáticas.

El caso es que después de saber que no es la UDF, no me parece que deba cerrar la sesión para liberar la memoria usada que aparece bajo Uso de PF en las gráficas y también para que suba la memoria física disponible.

En resumen:

En cuanto al uso de la CPU estoy de acuerdo.

En cuanto al uso de memoria, pues el uso exagerado de memoria sólo me parece que podría ser mientras no se haya hecho un commit o un rollback (aunque la verdad, como en una transacción todo va quedando grabado en la base de datos, y sólo se realiza un volcado cuando se hace un commit o un rollback, creo que tampoco debería consumir tanta memoria). Esto quiere decir que no acabo de estar de acuerdo con el uso exagerado de memoria, y no es lógico que deba cerrar la conexión para poder liberar memoria usada por el servidor.

Entre otras cosas, como sugirió Gydba leer otros hilos, los leí y probé la función LiberarMemoria.



procedure LiberarMemoria;
begin
if Win32Platform = VER_PLATFORM_WIN32_NT then
SetProcessWorkingSetSize(GetCurrentProcess, $FFFFFFFF, $FFFFFFFF);
end;


Tampoco sucedió nada. Esto se haría para liberar memoria en el cliente, pero no en el servidor. Después de todo lo evaluado estoy prácticamente seguro de que el problema es del servidor InterBase. Entonces la pregunta concreta sería:

Cómo libero memoria en el servidor InterBase luego de terminada una transacción, mientras aún haya conexiones activas? Cómo hago para liberar esa memoria precisamente desde una conexión, es decir desde un cliente?

Es normal este comportamiento?

[jachguate]

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.