empresas que usan firebird

[Casimiro Notevi]

Hola, amigo jachguate, es cierto que windows usa la memoria virtual (fichero en el disco duro) para "ampliar" aunque tenga mucha RAM instalada, incluso le sobre, pero eso es un problema de windows, como has dicho.
En linux, no es así, linux usa toda la memoria ram disponible y sólo cuando ya no le queda más remedio, entonces usará la memoria virtual, por lo que siempre está sacando el máximo rendimiento a la ram instalada, y cuanto más tenga, mejor.
En los apartados de memoria y cpus, no estoy nada de acuerdo contigo, mejor dicho, o te has confundido o no te he entendido, pero aquí dices:

Empezado por jachguate

• Procesador. Puede que tengas 16 nucleos, pero que la base de datos solo pueda sacar provecho de uno (especialmente cierto con firebird).
• RAM. En el servidor de base de datos, es bueno tener mucha RAM, y es mejor sacarle provecho. He visto casos donde el dueño del negocio se ve obligado a comprar un servidor con 8, 16 o más GB de RAM, pero cuando revisas Firebird está tirando solamente de un par de ellos. (especialmente cierto con Firebird).

Eso que mencionas puede ocurrir con windows, con la versión superserver, y si además no has configurado cpuaffinitymsak en firebird.conf
Pero no es así en linux con las versiones classicserver ni superclassic, firebird hace uso de todas las cpus instaladas, perfectamente, transparente al usuario, y además lo hace muy bien, aprovechando cada cpu, según su nivel de utilización, si está muy ocupada entonces lanza la consulta por otra cpu.
Lo tengo más que probado en mis clientes, observando con 'top' los procesos del servidor según van trabajando los usuarios, y cómo firebird va haciendo peticiones a cpus más ociosas para repartir el trabajo entre todas las cpus.
Además no sólo lo digo yo, lo dice la propia documentación de firebird:

Why doesn't Classic have CPUAffinity setting in firebird.conf?
Because CPUAffinity only applies to SuperServer. Classic can work on multiple CPUs without problems, while SuperServer needs that option to aviod context switching between processors with degrades performance dramatically.

Multiprocessor/multicore

ClassicServer // SuperClassic
SMP (symmetrical multi-processing) is supported out of the box. The CpuAffinityMask parameter in firebird.conf is ignored.
Unlike Superserver, Classic and SuperClassic can also assign multiple connections to the same database to different processors.

SuperServer
Windows SuperServer defaults to using the first logical processor only, because prior to 2.5 it performed badly on SMP systems. To make use of all your processors, set the CpuAffinityMask parameter in firebird.conf to: 3 for 2 CPUs/cores; 15 for 4 CPUs/cores; 255 for 8 CPUs/cores.
Linux SuperServer ignores CpuAffinityMask.

Ya digo, que cuando un cliente ha ido aumentado sus conexiones al servidor y vemos que todos los procesadores están casi siempre a un alto nivel de uso, le cambiamos el servidor por uno de más cpus y problema solucionado. Firebird reparte las peticiones entre ellos y se acabó el problema, es una "gozada" ver varias cpus a tope de rendimiento, abres una nueva conexión, haces un select complicado y ves en la pantalla de monitorización como la consulta se lanza contra otra cpu que está ociosa y no notas nada de retraso.
El único problema es ahí los discos duros, pero ya digo que hay que montar los más rápidos que se pueda permitir económicamente.
En un par de clientes también tenemos instalado red de fibra óptica, por lo que los "cuellos de botella" que mencionas se quedan prácticamente en la eficiencia de las SQLs que hayamos hecho nosotros

En cuanto a la memoria, la verdad es que firebird consume muy poco, otra gran ventaja, pero sí necesita un poco por cada conexión abierta, obviamente, no recuerdo la cantidad, pero también es poco, el lunes lo puedo confirmar preguntando a un cliente, pero juraría haber visto en algunas ocasiones más de 6 Gb de ram usadas, eso sí, con varias decenas de conexiones activas.

En fin, que al igual que afirmas que con servidores linux la diferencia de rendimiento con windows es bastante grande, también creo que esos "limitantes" que has puesto de cpus y ram, se dan sólo en windows, donde se usa la versión superserver. Y no tiene nada que ver con las versiones classic de firebird, menos todavía en linux.

[jachguate]

Empezado por Casimiro Notevi

Hola, amigo jachguate, es cierto que windows usa la memoria virtual (fichero en el disco duro) para "ampliar" aunque tenga mucha RAM instalada, incluso le sobre, pero eso es un problema de windows, como has dicho.
En linux, no es así, linux usa toda la memoria ram disponible y sólo cuando ya no le queda más remedio, entonces usará la memoria virtual, por lo que siempre está sacando el máximo rendimiento a la ram instalada, y cuanto más tenga, mejor.

Es correcto lo que decís. En cualquier caso, una de las tareas del DBA es evitar que el servidor de base de datos use memoria virtual. Si dada la necesidad, no se puede instalar más memoria, es preferible, por ejemplo, tener un caché más pequeño, que permita que todas las operaciones se realicen en RAM, que dejar que se use memoria virtual, independientemente del sistema operativo. Como ya se ha acotado, en Linux podrás, al menos, esperar a que realmente se consuma toda la RAM... en windows eso es diferente.

Empezado por Casimiro Notevi

En los apartados de memoria y cpus, no estoy nada de acuerdo contigo, mejor dicho, o te has confundido o no te he entendido

Creo que no me has entendido o no me supe explicar.
Lo que yo dije es:

Procesador. Puede que tengas 16 nucleos, pero que la base de datos solo pueda sacar provecho de uno (especialmente cierto con firebird).

Pretendí dar a entender más o menos lo siguiente:

Procesador. Puede que tengas 16 nucleos, pero que (por estar mal configurada o por haber elegido la edición incorrecta) la base de datos solo pueda sacar provecho de uno (especialmente cierto con firebird).

Y nunca quise decir que Firebird no pudiese sacar provecho de todos los núcleos o procesadores instalados.

Cuando comparas Firebird con otros motores, sin embargo, no puede dejar de reconocerse que aún tiene limitaciones (la falta de una caché compartida, pro ejemplo), y que no será hasta la versión 3 que esto mejore realmente. Esto tiene que ver también con el punto anterior.

Empezado por Casimiro Notevi

Firebird hace uso de todas las cpus instaladas, ... si está muy ocupada entonces lanza la consulta por otra cpu.

Esto en realidad lo hace el scheduler del sistema operativo, no Firebird. Lo que Firebird hace es sacarle provecho .

Empezado por Casimiro Notevi

Ya digo, que cuando un cliente ha ido aumentado sus conexiones al servidor y vemos que todos los procesadores están casi siempre a un alto nivel de uso, le cambiamos el servidor por uno de más cpus y problema solucionado

mmmm... yo diría "cuello de botella solucionado". Puede que al subir de 8 a 32 núcleos, resulte que el siguiente cuello de botella (que podría ser I/O, o RAM) impida que se saque provecho de tal capacidad de proceso!

Empezado por Casimiro Notevi

En cuanto a la memoria, la verdad es que firebird consume muy poco, otra gran ventaja, pero sí necesita un poco por cada conexión abierta, obviamente, no recuerdo la cantidad, pero también es poco, el lunes lo puedo confirmar preguntando a un cliente, pero juraría haber visto en algunas ocasiones más de 6 Gb de ram usadas, eso sí, con varias decenas de conexiones activas

Esto es parametrizable. Firebird consume poco (como motor) y eso es una de entre todas sus bondades. Pero cuanto consumirá cada cliente (en el caso de classic/superClassic) o cada base de datos (en el caso de SuperServer) depende de cómo esté configurado, de la cantidad de información en la base de datos y de cómo tiras de ella desde el cliente.

Empezado por Casimiro Notevi

también creo que esos "limitantes" que has puesto de cpus y ram, se dan sólo en windows, donde se usa la versión superserver. Y no tiene nada que ver con las versiones classic de firebird, menos todavía en linux.

No concuerdo con tu redacción, aunque lo has dicho mejor que yo... al final, creo que eran temas obligados (realmente no sabía si ya se habían tocado o no), ya que no sabemos prácticamente nada de la instalación/configuración particular de la que hablamos, y no debemos olvidar que la información aquí mencionada queda también para la posteridad y nada mejor que, de manera colaborativa, tratar de brindar un panorama más o menos completo.... tarea bastante complicada en un tema tan amplio como este, para el que fácilmente se llevan meses o años de estudio y experiencia.

Yo diría que:

• La RAM es una consideración a tener en cuenta independientemente del sistema operativo, de la base de datos (oracle, firebird, etc) o de la edición de firebird, para ser específicos en este caso. La combinación de estos da diferentes resultados y algunos serán más ventajosos que otros, pero es algo que un DBA debe conocer y no puede olvidar, ya que si puede llegar a ser un cuello de botella.
• La cantidad de CPU's y su velocidad, es igualmente importante, independientemente del sistema operativo y del fabricante de la base de datos. El DBA debe tener conocimiento suficiente del motor para poder elegir entre opciones/parámetros de configuración de manera que saque el mayor provecho de este recurso.

Esto, sin excluir otros factores que ya he mencionado antes.

Un saludo, amigo Casimiro y a todos!

[Casimiro Notevi]

Seguramente no te entendí bien, mejor ahora, quedará también más claro para otros posibles usuarios

Buen viaje

[jachguate]

Empezado por Casimiro Notevi

Buen viaje

Gracias Casimiro!

[Gregory Mazon]

Hola, no tengo tanta experiencia en este tema como ustedes pero me enfrento a una situación muy similar y lo que yo puedo aportar es que una consulta SQL específicamente con esas cantidades de registros inevitablemente van hacer lentas por mas optimizadas que se encuentren y la unica opcion seria las tablas de los acumulados, pero ahi es de donde viene otro problema, los TRIGGERS

Empezado por Casimiro Notevi
Esos acumulados se programan en la BD, mediante triggers, así que todo el trabajo lo haría la propia BD y nos despreocuparíamos nosotros.

yo tengo mis tablas de acumulados mediante triggers, pero despues de ir acumulando ciertos registros (miles o cientos de miles) la "basura" que me genera en la DB, hace que mis consultas se vuelvan lentas lo que antes me daba en segundos se vuelven minutos, y la unica forma de resolver el problema es mediante backup y restore, pero al tener una base tan grande ese proceso es de horas y horas maquina

me parece perfecta la idea de poder tener 2 base de datos
- una para detalle o para los millones de registros
- otra para los acumulados (en donde el proceso de mantenimiento se pueda hacer mucho mas rapido y mas frecuente)

pero que pasa con las transacciones?????
se puede tener una trasaccion para 2 bases de datos????

Saludos
GM

[erickahr]

Hola, buen dia a todos compañeros foreros, y antes que nada muchisimas gracias a todos, y especialmente en orden de respuesta.

• Casimiro Notevi
• Delphius
• Chris
• Jachguate

He leido detenidamente cada punto de sus recomendaciones, de sus consejos, y bueno creo que el primer punto de "Things to do" es montarme un servidor linux, inceramente estoy muy verde en linux, pretendo usar Fedora, aunque ya antes he tenido problemitas con otras distros para levantar el Samba, y tengo ciertas dudas, pero por lo leido vale bastate la pena el cambio, y lo haremos.

Como datos adicionales, solo para no dejar cosas en el aire, manejamos un servidor dedicado para los DNS y administracion de los usuarios, permisos y demas; y otro servidor exclusivamente para la BD, el cual no corre aplicaciones, es dedicado, no administra nada, cuenta con 4 cores, se generan Backups diarios a la 1 de la madrugada (cuando el servidor no tiene conexiones activas), y se almacenan en un disco externo de 4TB.

Como bien dice Chris con la cuestion de los reportes creo que me explique mal, si me refero al momento de hacer la consulta, ya que una vez con los datos necesarios el RAVE me funciona perfecto, y si, hay algunos reportes 'pesados' en los cuales cambiaré la ideologia y en lugar de sacarlos con Joins, Groups, y demás, se mandarán a una tabla de acumulados para sacar la informacion con un select mas sencillo, aunque en este punto me entra otra pequeña duda...

• Al hacer updates en las tablas de acumulados repetidamente para mantenerlas actualizadas
  ¿Se estaria generando demasiada basura en la BD?
• De ser asi ¿Cada cuanto se tendria que hacer una reculeccion (mediante Backup-Restore)? O ¿como se podria manejar esa cuestion?

Empezado por Delphius

Me hiciste acordar ahora de otra frase: Rapido, Bueno, Barato. Elija 2 cualquiera.

Me rei mucho con esa 'Reflexion', es la pura y cruda realidad

Y bueno por último y no por eso menos importante Jachguate, pues tu dime como por que fecha andas en esta tierra Azteca, y claro que nos ponemos de acuerdo y si alguien más anda por el rumbo, armamos una 'Taberna' en el plano real .


Me temo que andaré por aca dando lata mas adelante, porque esto apenas comienza...

Saludos y nuevamente Gracias.

[Casimiro Notevi]

Empezado por erickahr

aunque ya antes he tenido problemitas con otras distros para levantar el Samba

En el servidor sólo has de instalar firebird, nada más, no tienes que usar samba ni nada de nada.
El servidor firebird se comunica por el puerto 3050 y él se encarga de hacer las peticiones a la base de datos y de dar las respuestas. Pero nadie, ningún usuario tiene por qué tener acceso a nada del servidor, no hay que compartir nada.
Mejor que los usuarios ni sepan dónde está el servidor, usas un alias y listo.
Cuando vayas a instalarlo si tienes cualquier duda, pregunta, aunque es un tema que se ha tratado en diversas ocasiones y encontrarás información amplia si usas las búsquedas de clubdelphi.

[erickahr]

Claro, buscar antes de preguntar, y si me imagino que debe ser un tema recurente... pues manos a la obra, y muchas gracias nuevamente Casimiro Notevi y CD

[Casimiro Notevi]

Empezado por erickahr

• Al hacer updates en las tablas de acumulados repetidamente para mantenerlas actualizadas
  ¿Se estaria generando demasiada basura en la BD?
• De ser asi ¿Cada cuanto se tendria que hacer una reculeccion (mediante Backup-Restore)? O ¿como se podria manejar esa cuestion?

¿Basura al hacer updates?, no, además hazlo mediante triggers, es la mejor opción.
Con un backup/restore la BD queda como nueva

Con ese servidor que tienes verás como el rendimiento que consigues será bastante importante.

[jachguate]

Empezado por erickahr

He leido detenidamente cada punto de sus recomendaciones, de sus consejos, y bueno creo que el primer punto de "Things to do" es montarme un servidor linux, inceramente estoy muy verde en linux, pretendo usar Fedora, aunque ya antes he tenido problemitas con otras distros para levantar el Samba, y tengo ciertas dudas, pero por lo leido vale bastate la pena el cambio, y lo haremos.

No vamos a entrar al tema de las distros, porque para los gustos los colores. Olvida el Samba, además del core básico, este servidor solo tendría Firebird, no?

Empezado por erickahr

cuenta con 4 cores

¿saca provecho realmente a los 4?

Empezado por erickahr

Al hacer updates en las tablas de acumulados repetidamente para mantenerlas actualizadas
¿Se estaria generando demasiada basura en la BD?

Si, genera distintas versiones de registros que luego son basura, además que ir actualizando por cada registro insertado/modificado/borrado también consumirá tiempo de proceso, que tiene a su vez impacto en el rendimiento. Hay un abanico de posibilidades y lo mejor, para no variar, depende de tu aplicación particular. Por ejemplo, ¿es aceptable que algunos acumulados estén algo desactualizados? ¿que tanto?

Podes configurar el motor de diferentes maneras para graduar la manera y frecuencia de la recolección de este espacio, de manera que sea el óptimo para tu caso particular. Lee el artículo dabase housekeeping, que te dará una panorámica del tema.

Empezado por erickahr

Jachguate, pues tu dime como por que fecha andas en esta tierra Azteca, y claro que nos ponemos de acuerdo y si alguien más anda por el rumbo, armamos una 'Taberna' en el plano real .

Te envié un privado, no es que sea secreto... pero prefiero que no haya reporteros en el aeropuerto al llegar, jajajaja

[Casimiro Notevi]

El tema de la "basura", no suele ser problema, en un uso normal ni siquiera se notará. Por eso digo que no es problema, o al menos nunca me he encontrado que sea un problema en ningún caso.
También es cierto que además de los backups diarios, cada semana (cómo mínimo) tenemos programado un backup/restore de la BD (habitualmente los sábados por la noche o domingos, según el cliente), por lo que queda "limpia" para empezar a trabajar de nuevo con ella.

[jachguate]

Empezado por Casimiro Notevi

al menos nunca me he encontrado que sea un problema en ningún caso.

Depende de factores tales como:

• Qué tan cortas son las transacciones
• Se usa o no commit retaining?
• Nivel de aislamiento de las transacciones
• Cantidad/Proporción de rollbacks
• Configuración de la bd (sweep interval/GCPOLICY)

En una aplicación que ha seguido recomendaciones como realizar transacciones cortas, con el menor niveles de aislamiento necesario, no tendría por qué ser problema, pero... he visto casos!! ufff...

[Casimiro Notevi]

Empezado por jachguate

En una aplicación que ha seguido recomendaciones como realizar transacciones cortas, con el menor niveles de aislamiento necesario, no tendría por qué ser problema, pero... he visto casos!! ufff...

Pues sí, tan sólo hay que tener un poquito de cuidado con lo que hace

[jachguate]

Empezado por Casimiro Notevi

Pues sí, tan sólo hay que tener un poquito de cuidado con lo que hace

Claro, y cruzar los dedos para que cuando heredas código, los otros F#$%&/*" programadores hayan tenido ese cuidado también... jajajaja

[erickahr]

Efectivamente, mi duda respecto a la basura, se basó en este articulo ahi se mencionan las popiedades que comenta Jachguate, queda el enlace por si a alguien le sirve.

Mi preocupacion surgia porque un Backup/Restore se me tarda un promedio de 4hrs, pero pretendo generar una BD con tablas de acumulados, sobre esta ideologia, no afectaria mucho hacer un Backup/Restore, ya que seria relativamente pequeña, o eso espero ; pero primero lo de Linux