Servidor Interbase. Consumo de memoria sin parar.

[Casimiro Notevi]

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

Many operating systems employ a disc cache mechanism. This uses an area of memory (which may be part
of your server's overall RAM or may be built into the disc hardware) to buffer writes to the hardware. This
improves the performance of applications that are write intensive but means that the user is never certain when
their data has actually been written to the physical disc.
With a database application, it is highly desirable to have the data secured as soon as possible. Using Firebird,
it is possible to specify whether the data should be physically written to disc on a
COMMIT
or simply left to the
operating system to write the data
when it gets around to it
.
To give the DBA or database owner full control of when data is written, the
gfix -w[rite]
command can be used.
The command takes two parameters:
gfix -write MODE database_nam

The MODE parameter specifies whether data would be written immediately or later, and is one of:•
sync
- data is written synchronously. This means that data is flushed to disc on
COMMIT
. This is safest
for your data.
•
async
- data is written asynchronously. The operating system controls when the data is actually written to
disc.
If your system is highly robust, and protected by a reliable UPS (uninterruptable Power Supply) then it is possible
to run asynchronously but for most systems, synchronous running is safest this will help prevent corruption in
the event of a power outage or other uncontrolled shutdown of the server and/or database

Firebird defaults to synchronous mode (forced writes enabled) on Linux, Windows NT, XP, 2000, 2003 and
Vista.

[PepeLolo]

Empezado por Casimiro Notevi

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

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.

Supongo que tendrás "write sync"

Si

[Casimiro Notevi]

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

[PepeLolo]

Empezado por Casimiro Notevi

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

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

Gracias Casimiro.

[erickperez6]

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?

[PepeLolo]

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

Eso es todo

[Casimiro Notevi]

Intenta cerrar todas las transacciones para ver si realmente están cerradas o no:

 gfix -commit all database

No sé si funcionará con interbase, ya que sólo uso firebird desde que se creó.

Cambia a firebird

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

[[Al González]]

Saludos PepeLolo.

Empezado por PepeLolo

Las transacciones de consultas duran mientras este activo el formulario.

¿A qué te refieres con esto?

Empezado por PepeLolo

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

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.

Empezado por PepeLolo

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

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).

[PepeLolo]

Empezado por Al González

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

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..). Mientras el usuario este en este formulario la transacción esta activa. Al cerrar el formulario se finaliza la transacción.

Empezado por Al González

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.

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:

Materias primas -> AL_MAT_PRI = Almacén. Materias Primas.
Ordenes de producción -> PR_OP = Producción. Ordenes de producción
Albaranes -> FRA_ALB = Facturación. Albaranes. (Cabecera)
Líneas de detalle de albaranes -> FRA_ALB_DET = Facturación. Albaranes. Detalle.
Pedidos de compra -> CP_PED_COM -> Compras. Pedidos. De compra
Recepciones de compra -> CP_REC_COM -> Compras. Recepciones. Compras.

un trigger de una tabla. PD_NOT_INF_BI0.
Pero queda mierda suelta que como siempre no hay tiempo para solventarlo.

Empezado por Al González

Quizá una mejor idea sería que la aplicación cierre la conexión tras un tiempo sin uso

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

Empezado por Al González

Aunque no debería representar ningún problema dejarla abierta siempre que el cierre de las transacciones no dependa de a interfaz de usuario (una mala práctica por la que casi todos hemos pasado al incursionar en desarrollo cliente-servidor).

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...)

Empezado por Ñuño Martínez

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...

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

[[Al González]]

Empezado por PepeLolo

En formulario de edición largos (rellenar una factura), la transacción dura mientras el usuario no abandone el formulario con (Rollback o Commit).

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.

[Casimiro Notevi]

Empezado por Al González

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

[PepeLolo]

Empezado por Al González

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.

[Casimiro Notevi]

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