Servidor Interbase. Consumo de memoria sin parar.

[PepeLolo]

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:

Windows Server 2003 Enterprise edition Service Pack 2
Intel Xeon CPU X3363 @ 2.83GHz 2.83 GHz, 11.9 GB de RAM Extensión de dirección física

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:

## The default value for each entry is listed the right of it.
## To activate an entry, uncomment it and supply the desired value.

#ADMIN_DB "admin.ib"
## Specifies a filename for the InterBase security database.
##Needed only if you do not want to use the default name, admin.ib.
## The security database must reside in the InterBase home directory.

#ANY_EVENT_MEM_SIZE 32768
## Bytes of shared memory allocated for event manager.

#ANY_LOCK_MEM_SIZE 98304
## Bytes of shared memory allocated for lock manager.
## Default is 98304 on Linux and Solaris, 256K on Windows.

#ANY_LOCK_SEM_COUNT 32
## Number of semaphores for interprocess communication
## (Classic architecture only).

#ANY_LOCK_SIGNAL 16
## UNIX signal to use for interprocess communication
## (Classic architecture only).

#CPU_AFFINITY
## (Windows only) In an SMP system, sets which processors can be used
## by the InterBase server. The value is taken from a bit vector in
## which each bit represents a machine. Thus, to use only the first
## processor, the value is 1. To use both the first and second processors,
## the value is 3. To use the second and third, the value is 6.
## Default is all processors (when entry is commented out).

#CONNECTION_TIMEOUT 180
## Seconds to wait before concluding an attempt to connect has failed.

DATABASE_CACHE_PAGES 10000
#DATABASE_CACHE_PAGES 2048
## Server-wide default for the number of database pages
## to allocate in memory per database.
## Can be overridden by clients.

#DEADLOCK_TIMEOUT 10
## Seconds before an ungranted lock causes a scan to check for deadlocks.

#DUMMY_PACKET_INTERVAL 60
## Seconds to wait on a silent client connection before the
## server sends dummy packets to request acknowledgment.

#ENABLE_HYPERTHREADING 1
## Specifies whether Intel Hyper-threading technology enabled logical
## processors should be enabled
## Valid values are: 1 (enable), 0 (disable)
## Default: 0 (disable)

#EXTERNAL_FILE_DIRECTORY
## If your external files are not in <interbase_home>/ext,
## specify their location here. For security reasons, do not
## put other files in this directory.

#EXTERNAL_FUNCTION_DIRECTORY
## If your UDF library is not in <interbase_home>/UDF, then specify
## the location of the library here. For security reasons, do not
## put other files in this directory.

#LOCK_ACQUIRE_SPINS 0
## Number of spins during a busy wait on the lock table mutex.
## Relevant only on SMP machines.

#LOCK_HASH_SLOTS 101
## Tune lock hash list; more hash slots mean shorter hash chains.
## Not necessary except under very high load.
## Prime number values are recommended.

#MAX_THREADS 1000000
## Controls the maximum number of threads that can be active
## at one time within the InterBase engine. The listed value
## applies to a system with multiple licensed CPUs. For a
## single CPU system, the value defaults to 1 which eliminates
## the synchronization overhead required by multiple CPUs.

#SERVER_CLIENT_MAPPING 4096
## Size in bytes of one client’s portion of the memory mapped
## file used for interprocess communication.

SERVER_PRIORITY_CLASS 2
## Priority of the InterBase service on Windows NT, 2000, or XP.
## The value 1 is low priority, 2 is high priority.
## Relevant only on Windows NT/2000/XP.

#SERVER_WORKING_SIZE_MAX 0
## Threshold above which the OS is requested to swap out all memory.
## Relevant only on Windows NT, 2000, and XP
## Default is system-determined

#SERVER_WORKING_SIZE_MIN 0
## Threshold below which the OS is requested to swap out no memory
## Relevant only on Windows NT, 2000, and XP
## Default is system-determined

#SWEEP_QUANTUM 250
## Specifies the maximum number of records that a garbage collector
## thread or a sweeper thread is allowed to work before yielding
## control back to the worker threads.

#SWEEP_YIELD_TIME 1
## Specifies the time, in milliseconds, the sweeper or
## garbage collector thread sleeps.

#TCP_REMOTE_BUFFER 8192
## TCP/IP buffer size for send and receive buffers. This applies to
## both client and server programs.
## Default is 8192 bytes. Valid range is 1448 to 32768

#TMP_DIRECTORY
## Directory to use for storing temporary files.
## Specify directory path and number of bytes available in the directory.
## List multiple entries one per line; directories are
## used in the order specified.
## Default is the value of the INTERBASE_TMP environment
## variable; otherwise /tmp on UNIX or C:\temp on Windows NT/2000/XP.

#USER_QUANTUM 250
## Specifies the maximum number of records that a worker thread
## (thread running an user query) is allowed to work before
## yielding control back to other threads.

#V4_EVENT_MEMSIZE 32768
## Bytes of shared memory allocated for event manager.
## Overridden by ANY_EVENT_MEMSIZE.

#V4_LOCK_GRANT_ORDER 1
## 1 means locks are granted first come, first served.
## 0 means emulate InterBase V3.3 behavior, where locks are granted
## as soon as they are available; can result in lock request starvation.

#V4_LOCK_MEM_SIZE 98304
## Bytes of shared memory allocated for lock manager.
## Default is 98304 on Linux and Solaris, 256K on Windows.
## Overridden by ANY_LOCK_MEM_SIZE.

#V4_LOCK_SEM_COUNT 32
## Number of semaphores for interprocess communication
## (Classic architecture only).
## Overridden by ANY_LOCK_SEM_COUNT.

#V4_LOCK_SIGNAL 16
## UNIX signal to use for interprocess communication
## (Classic architecture only).
## Overridden by ANY_LOCK_SIGNAL.

#V4_SOLARIS_STALL_VALUE 60
## Number of seconds a server process waits before retrying
## for the lock table mutex.
## Relevant on Solaris only.

Librerias UDF

FreeAdhocUDF.dll

¿Alguna idea?

gracias de antemano

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

[cointec]

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

[PepeLolo]

Empezado por Casimiro Notevi

Cambia a firebird .

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

Empezado por cointec

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

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!

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

[cointec]

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.

[Ñuño Martínez]

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. ¡los mato!

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.

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

[PepeLolo]

Empezado por Casimiro Notevi

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

Toy perdido, eso ya lo se, pero no en este tema
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!

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.

[[rretamar]]

Empezado por Casimiro Notevi

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

Muy buen material. Gracias.