empresas que usan firebird

[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