Experiencia con SuperClassic y uso de memoria

[erickperez6]

Cointec, lo que sucede que el CS crea un proceso por coneccion y esto es mas costoso para la CPU que crear hilos dentro de un mismo proceso, al parecer las conecciones que están en el pool no son reutilizadas y se siguen creando procesos o hilos (dependiendo si es CS o SC), entonces el servidor en cuestion no tiene muchas prestaciones, poca memoria, procesador mediano en un servidor Linux, la experiencia es notable en este ambiente. He probado otras aplicaciones pero en un servidor Windows con mucho mas recursos, y la diferencia de carga entre CS y SC no es notable, pero creo que esto es porque se trataba de un servidor mucho mas robusto. Tengo que limpiar las conecciones automaticamente cada cierto tiempo porque como había comentado antes, las conecciones nunca mueren en el pool y la memoria se infla hasta colapsar la aplicación, el mensaje de error es exactamente ese, limite de conecciones excedido en el pool. Un ejemplo practico, a medida que acceden usuarios simultáneos o no, la cantidad de conecciones en el pool se elevaba, al cabo de una hora, sin ninguna navegación nueva en la aplicación, yo hacia una consulta de la cantidad de conecciones en el pool, donde esperaba ver una sola, pues seguia viendo la elevada cantidad de coneccion en espera, si el timeout del pool dice 10 segundo estas deben de limpiarse automaticamente en ese tiempo si no es reutilizada. Porque no se limpian? no lo se, desconosco el motivo, pero ya esto lo he probado en diferentes OS y el resultado es el mismo (nunca mueren las conecciones en el pool por si solas)

Que OS utilizas para tu aplicación? es una aplicación Web? que versión de firebird usas? que versión de driver .Net para firebird usas? que versión de framework .Net usas? has chequeado cuantas conecciones tienes en el pool en momentos que sabes que no hay mucha concurrencia de usuarios? Por ejemplo, como dices cuando tienes 150 usuarios concurrentes y tu memoria llega a los 16GB, que pasa luego cuando estas concurrencias bajan en horas o días no laborables, tu memoria se queda en los mismos 16GB o decrece? Es posible que te este pasando lo mismo, pero como cuentas con un equipo de muchos recursos, no lo notes y la cantidad de connecciones en el pool es muy elevada pero no sobrepasas el tope.

[cointec]

* Todas las instalaciones son Windows, 2003,2008 32 bits y 2008 64 bits.
* Utilizo Firebird 2.5.x, superserver, classis y superclassic, dependiendo de la instalación, aunque tengo clientes con interbase 7.5, 2007 y 2009, cada vez menos.
* Yo utilizo una versión antigua de driver de .Net, ya que necesito que sea compatible con Firebird e interbase. El driver .net de interbase no admite polo de conexiones y deja bastante que desear.
Utilizamos .net 3.5
* nuestra aplicación es cliente pesado, desarrollado en delphi. En instañaciones grandes suponen unas 140-150 conexiones. Tenemos una aplicación en .net que pueden utilizar unos 1200 usuarios en instalaciones grandes(no simultáneamente ) que generan unas 60000-80000 conexiones/transacciones diarias, donde el grueso de las mismas se produce entre las 8:00 y las 15:00 horas. Entre 1 y 5 conexiones en el pool se da servicio a todas. Monitorizando Firebird, rara vez he visto mas de 5 conexiones derivadas del acceso a través de .net.
* La memoria llega a 16gb con classic y superclassic, por que cada conexión consume una media de 110 MB. El meta data de la base de datos es grande y creo que ha habido una regresión de Firebird 2.1 a Firebird 2.5, ya que en las mismas condiciones firebird2.1 consume un 40% menos de memoria. Las instalaciones con Firebird superserver consumen entre 400 MB y 1 Gb. Con firebird CS/SC cuando se producen desconexiones, el consumo de memoria baja proporcionalmente y por las tardes y noches esta entre 4 y 6 gb dependiendo de las conexiones.

Por otro lado, mira el driver .net mas reciente, ya que creo que había un bug resuelto relacionado con el pool de conexiones.

[erickperez6]

muy interesante todo lo que expones y según lo que comentas creo que mi problema entonces radica en el driver .Net que siempre he utilizado, aunque también utilizo una versión mas vieja del framework (la 2.0) para mantener la compatibilidad de mis aplicaciones entre linux (Mono) y windows, pero no creo que este sea el problema, aunque todo es posible.

gracias,