Experiencia con SuperClassic y uso de memoria

[erickperez6]

Saludos,

Me gustaria compartir algunas experiencia con FB 2.5 SuperClassic y comentar una duda al respecto.

Pues estoy trabajando con una aplicacion web conectado a FB 2.5, todo montado en un servidor linux 64bit. Inicialmente instale la version Classic Server, pero la experiencia con aplicaciones web no es muy grata, les explico por qué. A diferencia de las aplicaciones de escritorio, que una vez que se logra la coneccion esta permanece viva hasta que el usuario sale o se desconecta del programa, en las aplicaciones web, se crea la coneccion en cada acceso o navegacion de una pagina, se consulta o actualiza la DB y luego se cierra la coneccion inmediatamente y este ciclo se repetira constantemente mientras se siga navegando dentro del website, pues sucede que el mecanisco de CS en crear un nuevo proceso y un nuevo hilo es muchisimo mas costoso en recursos que el mecanismo que utiliza el SC que va creando mas hilo dentro de un mismo proceso. Por ejemplo, la navegacion dentro del website utilizando CS era lenta (de 3 a 9 segundos en algunos casos) para cargar una pagina, al cambiar a SC la experiencia en la navegacion es inmediata y fluida (diria que en menos de un segundo cargas x paginas) incluso con varios usuarios simultaneos la experiencia siempre es la misma.

Lo unico que si he observado es que con el transcurso de los dias el uso de memoria que utiliza el proceso de firebird va creciendo, no en desproporcion, es decir, lo hace lentamente, pero siempre va en aumento. Por ejemplo, cuando hay usuarios navegando en la aplicacion se crean hilos nuevos, el uso de la memoria crece un poco, pero a los pocos segundo estos hilos mueren y la memoria vuelve a bajar pero no en la misma proporcion en que subio. No se a que se deba esto, pero me preocupa un poco ya que el servidor no tiene mucha RAM fisica.

[Casimiro Notevi]

¿Y cómo mides la memoria que ocupa y la que libera?.
Fíjate en el monitor del sistema y en top, verás que cada uno indica datos distintos.
También debes tener en cuenta que linux va usando la memoria ram hasta casi por completo y procura mantener ahí todo lo posible, para no usar el disco, que es más lento. Es normal ver la memoria prácticamente al máximo, por ejemplo, fíjate en este pantallazo, están siendo usados casi los 4 Gb que tiene el equipo, eso es normal.
http://farm8.staticflickr.com/7028/6544144311_ff45b398e9_z.jpg

En relación a que tarde más o menos en conectar con las distintas versiones, habría que conocer más en detalle tu sistema, en mi caso usamos classicserver 1.5 y 2.1 y no hemos tenido ese problema.

[Al González]

Muchas gracias por el testimonio, Erick. Esto puede servir a mucha gente que ande por los mismos caminos.

Personalmente desconozco cuál podría ser la razón de ese incremento de memoria. Una pregunta: Suponiendo que con un usuario conectado la memoria ocupada es 1 KB, luego con 3 usuarios / conexiones la memoria sube a 3 KB, luego se desconectan los últimos dos y vuelve a ser 1 usuario pero con 1.1 KB. Si vuelven a conectarse aquellos 2 usuarios (volviendo a ser 3 conexiones), ¿la memoria ocupada sube a 3 KB o a más de 3 KB?

Podría ser interesante hacer una prueba con esta mecánica, realizando meramente conexiones y desconexiones (sin consultar ni guardar datos) para observar con detalle el comportamiento de la memoria. Incluso sobre Windows también.

Por otro lado, conviene revisar si se está llevando a cabo un adecuado cierre de transacciones.

Saludos.

[erickperez6]

Saludos,

Se que el tema es viejo, pero creo que se quedo inconcluso de mi parte, ya que pude resolver el asunto y me gustaria compartir la solucion para alguien que le sea de ayuda.

Antes de decir la solucion, me gustaria contestar a Al Gonzalez, la proporcion en disminucion de la memoria al momento de que las conexiones cerraban eran casi minimas, por ejemplo tres usuarios conectados 3k, al desconectarse los tres la memoria quedaba en 2.7k es decir, se quedaba casi igual, por lo tanto se inflaba y se inflaba el uso de memoria del proceso hasta colapsar.

Bien, que era lo que sucedia? lo que pasa que en las aplicaciones web hay algo que es el poolconnection, aunque las conecciones se cerraban correctamente, estas pasaban a una cola de espera en memoria para ser reutilizada por nuevas peticiones, esto ayuda a un mas rapido acceso a las peticiones de las paginas. El poolconnection tiene un tiempo maximo de vida en memoria, por defecto son unos 30 segundos, este numero es configurable - cambiable, sucede que las conecciones que iban al pool nunca se destruian, no importa que yo le pusiera 1 segundo, 10 segundo, firebird simplemente no liberaba estas conecciones de memoria.

La tecnologia que uso es ASP.Net con los drivers oficiales para la conecion a firebird con .Net (2.5.2v a la fecha de hoy no es la ultima, pero si una de las mas recientes), estas librerias tienen metodo que forza a matar todas las conecciones que estan en el pool, pero solo mando a ejecutar este metodo cuando la session del cliente termina.

FirebirdSql.Data.FirebirdClient.FbConnection fbcon = new FirebirdSql.Data.FirebirdClient.FbConnection(ConfigurationSettings.AppSettings["fbcon"]);
FirebirdSql.Data.FirebirdClient.FbConnection.ClearPool(fbcon);

No se si esto es un bug en las versiones de firebird que he utilizado, pero este problema lo he tenido con la version 2.5.1 para windows y para linux, no he probado otras versiones; O si es un bug con el driver de coneccion que utilizo.

[cointec]

Hola,lo que no entiendo, es que con la versión classic, si utilizabas el connection pool, porque te tardaban tanto las consultas y las conexiones.

En los tests que he realizado, en Windows, no hay tanta diferencia entre abrir una conexión entre classic y superclassic. La mayos diferencia ha sido en el uso de memoria. Con 150 conexiones utiliza con SC 16Gb de memoria, mientras que con classic casi 19Gb.

Por otro lado, porque limpias el pool de conexiones. Nosotros tenemos el timeout a 5 minutos y con 3/4 conexiones damos servicio a muchos usuarios, con muy buen rendimiento.

Jesus

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