Servidor Interbase. Consumo de memoria sin parar.
 

Buenos días,

tengo problemas con el consumo de memoria del servidor de interbase 7.1 que se dispara hasta los dos megas muriendo al llegar a este nivel. Desde que se levanta el servicio hasta llegar a los dos megas suele pasar aproximadamente tres semanas.

Adjunto información del servidor:
El servidor esta activo 24/365
El número de usuarios activos concurrentes en una jornada normal llegan a ser de 120. y unas 600 transacciones activas (READ_COMMITTED).

Adjunto el fichero de configuración:
Librerias UDF ¿Alguna idea?

gracias de antemano

Supongo que en algún momento harás un "commit" de todas las transacciones.
Supongo que tendrás "write sync"

Todas las transacciones por defecto son "TaRollback", si son consultas de datos finalizan con "Rollback", las actualizaciones con "Commit" o "Rollback" si fallan.
Las transacciones de consultas duran mientras este activo el formulario.
Las transacciones de actualización lo que dure el proceso.

Si

Aunque no he entendido el problema, que ocupe 2 megas no es nada ¿cuál es el problema?

:D:D:D:D:D:D:D 2 Megas he dicho, NOOOOO 2 GIGAS, son dos GIGAS.
Cuando llega a este nivel, se cae el servicio de Interbase.

Gracias Casimiro.

Saludos,

tenia un problema parecido con el consumo de memoria, y el problema radicaba en que las conexiones que ya no se utilizaban se quedaban enganchadas, no se liberaban de memoria, por lo tanto el consumo de memoria del proceso de firebird se agigantaba hasta colapsar. Porque se quedan enganchadas? pueden ser mucho los motivos, en mi caso era que el driver que utilizaba para conectarme a firebird no estaba funcionando correctamente y dejaba las conexiones activas. Que ambiente de desarrollo esta realizada tu aplicacion? Que tipo de recursos/componentes estas usando para conectarte a la DB?

[quote]]erickperez6 [/QUOTE
Delphi 5, Cliente/Servior.
Acceso mediante los IBX.
Clientes win XP, W7, Vista, server 2003.

Eso es todo

Intenta cerrar todas las transacciones para ver si realmente están cerradas o no:
No sé si funcionará con interbase, ya que sólo uso firebird desde que se creó.

Cambia a firebird :p

O pregunta a interbase (embarcadero) que seguramente sabrán el motivo, además de que por algo estás pagando por interbase.

Interbase 7.1 tenía bugs importantes, que no se sí afectarán en tu caso. Tenías una actualización a 7.5.1 gratuita. Yo lo probaría.

El problema del bloqueo se debe a que al ser una aplicación de 32 bits, sólo puede direccionar 2gb. En cuanto necesita más de esa memoria, queda bloqueado.

En base a los parámetros de ibconfig y el número de usuarios, me parece un consumo excesivo. Yo con interbase 2009 y 150 usuarios, he tenido picos de consumo de 1.2 gb, teniendo 32768 páginas en cache.

Curiosamente tuve ese problema con Firebird 2.5.1, y el error se producía porque cerraba la conexión con la base de datos al cerrar la aplicación, utilizando IBX, con forceclose. Esto producía que Firebird no liberase la memoria de las consultas que tenía preparadas la conexión, y cada día incrementaba el consumo de memoria, ya que nunca se liberaba dicha memoria. Se solucionó, por nuestro lado, desconectando las conexiones correctamente al cerrar la aplicaciom y por parte de firebird corrigiendo el bug.

Interbase 7.1 tenía las tablas de monitorización disponibles. Prueba si en esas tablas puedes consultar el consumo de memoria de las conexiones y las consultas. También comprueba que no tengas transacciones en ejecución durante mucho tiempo.

Aparte, como te he comentado, valoraría migrar a interbase 7.5.1, o como ha dicho Casimiro, Firebird 2.5.2

Suerte!!!

:rolleyes: es una opción. Tendría que reducir el nombre de muchos objetos de la BBDD.


Difícil, pasar a 7.5, la empresa original perdió la factura de compra de interbase. 7.1 ya hemos hablado con Danysoft y no hay solución que se nos reconozca como cliente. Historias blablabla.

También es cierto que hay capullines de usuarios que me dejan los PC con la aplicación abierta durante días / semanas. ¡los mato!:D

Hablare con dirección a ver que dicen. Gracias a todos.

Con el número de serie, embarcadero debería tenerte registrado como usuario. En license manager debes tener la información de número de serie y correo electrónico con el que se registró. Con ese número de serie, deberías poder activar 7.5.1.

Nosotros en las aplicaciones tenemos un tiempo en el que sí el usuario no realiza acciones en la aplicación, cerramos la sesión.

A lo peor es mucho trabajo pero, ¿no podrías modificar la aplicación para que sólo conecte con la base de datos cuando sea necesario? Es decir: abres la conexión, envías las peticiones/modificaciones, obtienes la respuesta, cierras la conexión. A lo mejor sirve para evitar esas conexiones que se quedan colgadas.

También podría ser (o no) que cierran la aplicación de una forma "inesperada". Quizá de forma que no envía el evento "onClose" a la ventana, si es ahí donde cierras la aplicación...

No sé, hablo un poco por hablar. :rolleyes:

Saludos PepeLolo.
¿A qué te refieres con esto?

A mí ya me están pareciendo excesivos los 31 caracteres de Firebird. Estoy considerando renombrar una tabla "FacturacionActividadPartidaPago" por "FacturacionActividadPP" o "FacturacionAPP" y economizar en esfuerzo de lectura cuando veo por ahí el nombre de esa entidad. Y para nombres de procedimientos y disparadores que resulten necesariamente largos, abreviar. Después de todo cada objeto puede tener una descripción. :)

Quizá una mejor idea sería que la aplicación cierre la conexión tras un tiempo sin uso. Aunque no debería representar ningún problema dejarla abierta siempre que el cierre de las transacciones no dependa de la interfaz de usuario (una mala práctica por la que casi todos hemos pasado al incursionar en desarrollo cliente-servidor).

El mundo gira alrededor de un formulario con rejilla. Sobre el que se implementa las funcionalidades (Edición, Listados, consultas, Reportes, Filtros, acciones especificas, etc..). Al usuario se le muestra un conjunto de datos filtrados en función del perfil de este(guapo, feo, bonito, atún con ojos, directivo, etc..:D). Mientras el usuario este en este formulario la transacción esta activa. Al cerrar el formulario se finaliza la transacción.

Efectivamente, nosotros hemos abreviado mucho desde que llegue a la empresa, pero la BBDD viene del 2003 y muchos objetos siguen activos. A modo de ejemplo:
un trigger de una tabla. PD_NOT_INF_BI0.
Pero queda mierda suelta que como siempre no hay tiempo para solventarlo.

Si es una buena opción que habrá que implantar.

Eso depende del modo en que apliques la arquitectura cliente-servidor, me explico:
- En los procesos de disparo y olvido (actualizar un dato especifico), se define una transacción para la acción, independiente del resto.
- En formulario de edición largos (rellenar una factura), la transacción dura mientras el usuario no abandone el formulario con (Rollback o Commit).
- En las rejillas. Por cada acción de búsqueda que realiza el usuario se finaliza la transacción actual y se activa una nueva para con los resultados.
- Todas las transacciones por defecto son TaRollback.

La transacción en el formulario de rejilla se queda activa porque los capullines de los usuarios no cierran la aplicación, si añadimos a esto, que la aplicación presenta los formularios de rejillas en "Pestañas" a semejanza a como lo hace "Access" añadimos nuevas transacciones.

Lo normal es que un usuario tenga activas de 1 a 10 formularios (Ordenes de producción, Facturación, Presupuestos, identificación, tareas pendientes,
Almacén, Materiales, Compras, Recepciones, consultas, informes, Indicadores, etc...)

Esto no es posible por acción del usuario. Todos los formularios están creados mediante herencia visual ¡no me gusta escribir lo mismo más de una vez!. y tienen toda la funcionalidad básica que se necesita. (Diseño, controles y eventos).

gracias a todos:D

Tarde o temprano tendrás que cambiar eso. No tiene sentido abrir una transacción mientras no sea seguro que algo se enviará a la base de datos. En pocas palabras, hasta que el usuario oprima "guardar", es cuando hay que:

1. Iniciar transacción.
2. Enviar datos / cambios.
3. Confirmar transacción (o revertirla en caso de problema).

De la manera en que lo haces actualmente es nocivo, como ya has podido darte cuenta. :)

Saludos.

^\||/^\||/^\||/

Si y No. Dependerá de la amplitud de la acción. Para empezar, la transacción abierta te protege de los cambios que intente realizar otro usuario. Bloqueas el acceso a registros que estan siendo actualizados, que nadie mas se pueda hacer propietarios de ellos.

Si. Por ejemplo, tengo que introducir consumos de stock desde un formulario. Para cada registro introducido se implementa la transacción como señalas.

Andas bastante perdido en el tema de las transacciones, te aconsejo este documento, es la "biblia" de las transacciones.

:D:D Toy perdido, eso ya lo se, pero no en este tema :D:D
No veo nada en el documento que no contenga la cutreexplicación que di :)

Ya que habéis ayudado y mucho más de lo que os podéis imaginar, comentaros que:
- Tengo programas específicos del ERP, que están conectados a máquinas de producción que tienen conexión abierta, incluso cuando no están siendo utilizados durante horas. Aprovechare para cambiar esto y pasar a 2010, así aprovecho de paso la parte gestual.

- En el aplicativo de oficina, cuando no haya actividad durante un tiempo a determinar se desactivará de la BBDD. Esto tiene un poco más de miga ya que como comente en este hilo, los formularios se muestran en modo pestaña y lo normal es que tengan varios formularios activos.
La complicación estriba en que muchos de ellos reciben eventos de la BBDD "POST_EVENT". que informa al usuario de la idoneidad de la información para realizar una u otra acción o asignación de tareas a realizar. Bueno un royo patatero...... cosas como TaskList calientes ¡no confundir con líneas calientes! :D:D:D:D

Haber sí dirección esta de acuerdo que migremos a Firebird, pero de momento lo veo un poco lejano, por la pila de trabajo que tenemos. Por los dichosos nombres de objetos de la BBDD.

un saludo.

Muy buen material. Gracias. ^\||/