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]

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.