Informacion acerca de VULCAN

[tang]

Casimiro muchas gracias por tu respuesta. Deberias animarte en escribir algùn instructivo de como optimizar el firebird.conf para "firebird classic server en servidores duales", ya que haz tenido suficiente experiencia y hace mucha falta para la comunidad.

Por ultimo otras preguntas:

1. Haz tenido problemas con DeadLock usando Classic Server ?, Hace algunos años, tuve una experiencia cuando ocurria un deadlock, creo que en Firebird 1.0 o en Interbase 6.0 porque no se resolvia el conflicto y quedaban eternamente los dos demonios levantados. Actualmente He leido acerca de los parametros LockAcquireSpins y DeadlockTimeout. Que puedes comentarme sobre estos caso ?

2. Sobre corrupcion de base de datos. Haz tenido esa experiencia en Firebird 1.5 o en 2.0 ? Me ha sucedido varias veces con Firebird 1.0

3. Que tamaño tienen las base de datos mas grandes que tienes?

4. Que volumen de transacciones tienen los clientes mas grandes, por ejemplo: numero de facturas por dia, etc. ?

5. Porque vas a cambiar a Ubuntu ?

6. Porque dejas RedHat o Fedora y te vas a SUSE ?

7. Que tipo de disco acostumbras a utilizar en los servidores con firebird SCSI, IDE, SATA ? y que velocidad 7.200RPM o 5.400 RPM ?

Disculpa el abuso

[Casimiro Noteví]

Empezado por tang

Casimiro muchas gracias por tu respuesta. Deberias animarte en escribir algùn instructivo de como optimizar el firebird.conf para "firebird classic server en servidores duales", ya que haz tenido suficiente experiencia y hace mucha falta para la comunidad.

Pues, la verdad, jamás modifico firebird.conf, me imagino que los creadores sabrán mejor que nadie los valores más óptimos.
Así que se quedan tal y como se instalan, no lo tocamos.
Y en relación a la experiencia... pues a ver si alguna empresa "buena" me contrata que estoy cansado de los sueldos milenarios

Empezado por tang

1. Haz tenido problemas con DeadLock usando Classic Server ?, Hace algunos años, tuve una experiencia cuando ocurria un deadlock, creo que en Firebird 1.0 o en Interbase 6.0 porque no se resolvia el conflicto y quedaban eternamente los dos demonios levantados. Actualmente He leido acerca de los parametros LockAcquireSpins y DeadlockTimeout. Que puedes comentarme sobre estos caso ?

No, no he tenido ningún problema con deaklock porque hay que tratar de hacer las cosas para que nunca ocurra eso.

Empezado por tang

2. Sobre corrupcion de base de datos. Haz tenido esa experiencia en Firebird 1.5 o en 2.0 ? Me ha sucedido varias veces con Firebird 1.0

Pues si te digo la verdad, hasta ahora nunca hemos tenido problemas de corrupción de una base de datos firebird. Algunas veces sí que nos encontramos con "inconsistencias" provocadas por cortes de luz (o fallo de nuestro programa ), pero nada que no se pueda arreglar en un rato. Aunque algunas ocasiones se han roto físicamente los discos duros y se ha necesitado rescatar la última copia de seguridad, pero eso no es culpa de firebird.

Empezado por tang

3. Que tamaño tienen las base de datos mas grandes que tienes?

Varía bastante, la más pequeña creo que era de 200 ó 400 Mbytes y las más grandes de varios gigas, la última que vi tenía ya casi 7 Gbytes. Pero no he visto las bases de datos de todos los clientes, puede que me lleve una sorpresa con alguno.

Empezado por tang

4. Que volumen de transacciones tienen los clientes mas grandes, por ejemplo: numero de facturas por dia, etc. ?

No recuerdo, lo puedo ver mañana en el trabajo (hoy es fiesta en Andalucía), pero calculo que entre pedidos, albaranes, facturas y tickets... serán más de mil diarios, lo que recuerdo es que la última vez que me fijé tenía más de once millones de registros en la tabla de movimientos de almacén. Pero te lo confirmo mañana.

Empezado por tang

5. Porque vas a cambiar a Ubuntu ?

Cambiamos a Suse porque los servicios de RedHat se encarecieron bastante. ahora seguimos montando Suse porque son económicos y reconocen todo el hardware de los servidores que montamos. Puede que nos cambiemos definitivamente a Ubuntu porque nos parece que es más liviana y, simplemente, porque me gusta
Aunque he de reconocer que todas las distros que hemos instalado funcionan perfectamente, que nunca, repito lo de nunca, jamás hemos tenido ni un sólo problema con ninguna instalación linux. Se instala el servidor, se instala el firebird y se acabó, no tocamos nada de nada. Eso sí, el servidor se usa únicamente para alojar firebird y la base de datos de la empresa, para nada más.

Empezado por tang

6. Porque dejas RedHat o Fedora y te vas a SUSE ?

Ya te digo, fue una decisión económica, nada más. Para servidor me gusta más RedHat (Fedora no), pero Suse funciona perfecto también y el paquete trae unos manuales estupendos, en castellano.

Empezado por tang

7. Que tipo de disco acostumbras a utilizar en los servidores con firebird SCSI, IDE, SATA ? y que velocidad 7.200RPM o 5.400 RPM ?

Los clientes "normales" llevan discos normales SATA. En las empresas más grandes se montan SCSI. El último servidor "grande" que se instaló era un rack con 4 cpus dual-core, 8 Gb de RAM, el sistema operativo y firebird estaba alojado en 3 discos SATA RAID 5, los datos en 3 discos SCSI RAID 5, la "shadow" (réplica de la base de datos en tiempo real) en 3 discos SATA RAID 5 y creo que los archivos temporales se creaban en un disco SATA.
La velocidad de los discos SATA creo que son 7200rpm y de los SCSI de 10000 y 15000. Creo que ya no se hacen discos de 5400rpm.
Pero lo habitual en nuestros clientes de hace unos meses hasta ahora, por lo que me comenta uno de los técnicos, lo que él llama el "servidor estandar", es montar una cpu amd dual-core con 4 gigas de ram, un pequeño disco SATA para el sistema y firebird, otro SCSI rápido para los datos y otro igual para la shadow y copia de seguridad.
De todas formas para cualquier pequeña o mediana empresa con un servidor linux "normal" le sobra para atender decenas de terminales sin problema alguno.


Me gustaría decir que lo más importante es el programa que se vaya a utilizar, que esté "super afinado", que sea muy ágil, que no haga circular por la red datos innecesarios y que se controlen todos los posibles casos de errores para que no se estropeen los datos.