Informacion acerca de VULCAN

[tang]

Tengo un cliente que realiza muchas transacciones desde 20 puntos de ventas (POS). Sin embargo al mismo tiempo, ellos quieren lanzar informes que son bastante largos y complejos, al ejecutar estas sentencias para realizar el informe, el sistema se pone muy lento y el CPU se pone en 100% fijo. Ya hemos creado indices y hemos optimizado las sentencias, ha mejorado un poco, pero son muchos computadores para un servidor mono procesador, Quisiera instalar VULCAN porque es SMP.

Quien ha utilizado VULCAN y puede darme referencia de su funcionamiento en computadores MultiProcesador (SMP), Dual Core o Core 2 Duo ?

Que otra soluciòn tengo, Firebird Classic Server en SMP ?

Que tan estable es VULCAN ?

Saludos

[Casimiro Notevi]

No he usado vulcan, pero para lo que quieres también te viene bien la versión firebird classic en linux, porque si una cpu está ocupada haciendo algo, el resto de peticiones de ventas de los tpv se irían ejecutando en la otra cpu.
Algunos de mis clientes tienen bastantes más tpvs y no tienen problemas de ese tipo. Todos con varios procesadores y linux.

[jhonny]

No recuerdo donde, pero estoy seguro que fue un lugar serio donde leí que FireBird 3.0 se fusionaría con las buenas características de Vulcano para que los dos motores tomaran lo mejor de cada uno.

[Casimiro Notevi]

Empezado por jhonny

No recuerdo donde, pero estoy seguro que fue un lugar serio donde leí que FireBird 3.0 se fusionaría con las buenas características de Vulcano para que los dos motores tomaran lo mejor de cada uno.

En el Roadmap de Firebird

[tang]

1.- Cuando los TPV o POS de tu aplicacion estan trabajando, tu clientes lanzan informenes simultaneamente, los TPV o POS trabajan tranquilamente o hay algun tipo de lentitud ?

2.- Cuanto procesadores tiene el servidor que utilizas con Firebird ?

3.- Que distribucion de Linux utilizan ustedes con Firebird 2.0 ?

4.- Han utilizando Linux 64 con Firebird 64 ?

5.- Cuando creen ustedes que lancen la version Firebird con SMP en SS ?


Gracias

[Casimiro Notevi]

Empezado por tang

1.- Cuando los TPV o POS de tu aplicacion estan trabajando, tu clientes lanzan informenes simultaneamente, los TPV o POS trabajan tranquilamente o hay algun tipo de lentitud ?

Tranquilamente, es instantáneo.

Empezado por tang

2.- Cuanto procesadores tiene el servidor que utilizas con Firebird ?

Son muchos clientes, algunos tienen un procesador, otros (la mayoría), AMD 64 dual-core, algunos con 2 AMD 64 dual-core y alguno con 4 AMD 64 dual-core.

Empezado por tang

3.- Que distribucion de Linux utilizan ustedes con Firebird 2.0 ?

De momento tenemos Firebird 2.0 en nuestros ordenadores para probar. A nuestros clientes, de momento, les instalamos Firebird 1.5 y tenemos clientes con RedHat, Suse y Ubuntu. Los de RedHat los estamos sustituyendo por Suse, que es el que instalamos desde hace un par de años y los servidores web los montamos con Ubuntu porque estamos estudiando de pasar todos los demás también a Ubuntu y queremos ver que tal responden.
Hacemos los cambios después de haber probado algo muy en profundidad, primero los probamos nosotros en nuestra empresa, luego los vamos instalando en empresas pequeñas y luego, cuando hemos comprobado que funciona perfectamente y es capaz de responder a la carga de trabajo es entonces cuando lo montamos en las empresas más grandes que tenemos, este proceso de prueba puede durar más de un año hasta que estamos seguro de que no existirán problemas una vez instalado.

Empezado por tang

4.- Han utilizando Linux 64 con Firebird 64 ?

Todos nuestros clientes tienen Linux en los servidores, en los casos de cpus de 64 bits, la versión de Linux es de 64 bits. La versión de Firebird 1.5 que instalamos es la ClassicServer cuando hay más de una cpu (o una cpu dual-core) y la versión SuperServer cuando sólo hay una cpu simple.
Creo recordar que no hay Firebird 1.5 específica para 64 bits.

Empezado por tang

5.- Cuando creen ustedes que lancen la version Firebird con SMP en SS ?

Tendrás que preguntar a Firebird, aunque imagino que para después del verano o final de año estará disponible alguna beta.

Empezado por tang

Gracias

de nada

[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 Notevi]

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.