Dimensionar Ubuntu Server para Firebird CS-2.1.5

[josemmerida]

Buenas a todos:

Voy a montar un Ubuntu Server en vmWare como servidor Firebird CS-2.1.5 unicamente.

Dicho servidor tendrá una única base de datos que podrá llegar a unos 3Gb de tamaño con unos 25 usuarios concurrentes con 2 conexiones cada uno.

Tengo varias dudas, a ver si alguien que haya lidiado con esto me puede orientar:

1-Memoria
Mi idea inicial es asignarle 4Gb de Ram a la máquina.
¿Es suficiente?
¿En que medida y hasta que punto asignarle más RAM a la máquina le dará más velocidad?
Podría asignarle hasta 10Gb

2-Disco temporal
He leido, creo que en este foro, pero no lo encuentro, que se consigue más rendimiento si se asigna un disco independiente al directorio temporal de Firebird. Se habla incluso de crear un disco en memoria para apuntar hacia él el directorio temporal.
¿Que tamaño le asigno a ese disco duro?
Al ser una máquina virtual, la realidad es que el disco físico es el mismo.¿Merece la pena en el caso de vmware?

3-Configuracion de Firebird
En todos los años que llevo con Interbase/Firebird nunca se me ha pasado por la cabeza tocar la configuración por defecto.
¿Merece la pena redimensionar el parámetro "DefaultDbCachePages"?

Lo mismo intento afinar demasiado, pero bueno, si alguien tiene experiencia y la quiere compartir...

Muchas gracias

[Casimiro Notevi]

¿Y por qué lo instalas en una máquina virtual en lugar de usar el servidor dedicado para él?
Porque, además, ¿no estará montado sobre un windows?

[josemmerida]

No, eso sería demasiado...

Es un vmware EXSI 5 y sobre él están montadas todos las servidores de la empresa: Win2012,win2008,xp y ahora Ubuntu.

Va bastante bien, siempre que haya maquina aguantandolo...

Saludos

[cointec]

1. Memoria.

No depende del tamaño de la base de datos, sino más bien del metadata de la misma. Por ejemplo, una conexión a nuestra base de datos consume entre 100 y 125 MB, con fb2.5 cs/SC, 16kb de página y 300 páginas en cache por conexión. Con 4gb de RAM no podríamos dar servicio a más de 30 conexiones. Debes medir el consumo de memoria por conexión, pero te recomendaría en classic server, entre 150 y 300 páginas en cache.

También ten en cuenta que el SO necesita memoria adicional, y será importante que tenga memoria suficiente para cache de disco.

3. Configuración

Como te he comentado, establecería páginas en cache entre 150 y 300. También, dependiendo de las operaciones que realicen los usuarios, establecería lockhashslots a un número primo del rango de 3000. Pero esto es algo que tendrás que analizar en base al rendimiento que tengas.

Por otro lado, comentar que superserver hasta 30 conexiones tiene mejor rendimiento que classic server, según los análisis de rendimiento que he visto en test que se han realizado. Puedes consultarlos en slideshare. Nosotros instalamos superserver hasta 50 conexiones y classic en adelante. El rendimiento de classic server es mejor con más conexiones, siempre que se haga uso intensivo de cpu, pero tiene una penalización en el acceso a base de datos, ya que el sistema de bloqueos que utiliza la versión classic es más lenta que la que utiliza la versión superserver.

También tengo que decir que utilizamos Windows, pero no influye en que el sistema de bloqueos sea más lento en cs que en ss. Otro motivo por el que usamos SS con pocos usuarios es que podemos dar servicio a 50 conexiones con servidores con 2gb RAM, mientras que necesitaríamos 8Gb si utilizásemos cs,en base al consumo por conexión que tenemos.

Me parece extraño lo que has comentado en un post anterior que puedas valorar un mejor rendimiento de classic sobre superserver, ejecutando una simple consulta. Te remito a slideshare, para que veas las comparativas de rendimiento de SS/CS por número de conexiones.

[donald shimoda]

Empezado por cointec

Me parece extraño lo que has comentado en un post anterior que puedas valorar un mejor rendimiento de classic sobre superserver, ejecutando una simple consulta. Te remito a slideshare, para que veas las comparativas de rendimiento de SS/CS por número de conexiones.

Excelente tu aporte, gracias.

[josemmerida]

Hola de nuevo

Debes medir el consumo de memoria por conexión, pero te recomendaría en classic server, entre 150 y 300 páginas en cache

¿Cómo podría medir el consumo de memoria por conexión en un Ubuntu Server? Ya sabes que los que venimos de windows no perdemos sin graficos...

Puedes consultarlos en slideshare.

Voy a echarle un vistazo

Me parece extraño lo que has comentado en un post anterior que puedas valorar un mejor rendimiento de classic sobre superserver, ejecutando una simple consulta.

Bueno era solo un acercamiento inicial. Son una serie de consultas cíclicas más o menos complejas en las que mido las respuestas por minuto de cada servidor...

Muchas gracias por vuestra ayuda

[cointec]

No utilizo linux y en Windows he utilizado processexplorer para el análisis del consumo de memoria..

Yo utilizo Firebird 2.5 y creo recordar que mon$attachments tiene una columna con la memoria utilizada por la conexión, no se sí 2.1 la tiene, ya que es un dos distinto.

Para medir el consumo de memoria, se puede realizar simplemente simulando una conexión y un trabajo de un usuario durante unos minutos. Lo que más memoria utiliza es el metadata, ya que mientras superserver es compartida, classic o superclassic lo cargan por conexión. La memoria utilizada por cache de páginas siempre es fija y realmente en classic es muy poca, ya que como he comentado con 300 páginas es suficiente.

Otro tema interesante, es que aunque no utilizo Firebird 2.1, en su momento me pareció excesivo el consumo de 120mb por conexión en Firebird 2.5. Realicé las mismas pruebas con Firebird 2.1 y el consumo de memoria por conexión era cerca de un 50% inferior. En su momento lo reporté al equipo de desarrollo de Firebird para que lo analizasen, hicieron algunas modificaciones en Firebird, pero realmente no bajó el consumo. El ticket sigue abierto.

[josemmerida]

Voy a trabajar el tema.

Muchísimas gracias por la información.

Saludos.