66 respuestas en este tema

[Sergio]

Ayer recibi mi SSD, un "Kingstom 64GB ssdnow100 x5", al final me ha costado 105 euros (+18% de IVA), y esta mañana he procedido a conectarlo y ahora mismo ando haciendo pruebas.

El equipo donde hago las pruebas (tanto FireBird server como mi aplicacion, todo junto) es este:

C:\ y D:\ Seagate Barracuda LP 500 GB SATA http://www.seagate.c...arracuda_lp.pdf
S:\ SSD SATA Kingston 64GB ssdnow100 x5 (105 € 02-2011) http://www.kingston....sd/v_series.asp
Win7 de 64 bits, Intel i5, 4 nucleos, 3.2 GHz, 4GB RAM (nuevo 2010)
FireBird V2.5 32 bits, instalacion 100% por defecto.

Las pruebas las hago usando mi propia aplicacion "del mundo real", lo prefiero a los scripts, y me estoy centrando en un proceso "pesado" que es generar facturas a partir de items. pendientes de facturar. Es un proceso que usa intensivamente la base de datos, pero donde las consultas son todas con sus indices y esas cosas (nada de "plan natural" en el proceso de generar las facturas), asi que es algo del mundo real y que basicamente necesita velocidad de lectura.

Planeo hacer cada prueba 4 veces, cambiando la base de datos del D: al S: y tambien cambiando los temporales de FireBird de C: a S:, ya que supongo que poner los temporales en S: tambien ayudara bastante. Asi que cuando pruebe usando solo discos normales, es importante notar que los datos y los temporales nunca coinciden en el mismo disco fisico.

De momento solo he hecho una pequeña prueba con los temporales en C: (generar 24 facturas a partir de 311 items. pendientes de facturar) y en el disco D: (el normal) tarda 1.092s, algo mas rápido incluso que el S: (SSD) donde tardo 1.170s.

Yo ya lo esperaba: Los discos normales tienen una cache interna en RAM que es mas rapida que un SSD, con lo que si todo lo que ha de hacer le cabe en esa cache, el disco normal es mas rapido que el SSD.

Actualizacion: Acabo de caer en que windows tambien asigna una cache RAM a cada unidad, lo cual tambien interfiere y los tiempos para estos casos "pequeños" tiene muy poca relevancia.

La prueba buena es la que esta corriendo ahora mismo, que consiste en hacer eso mismo pero con 71.000 items. por facturar (una base de datos real, de 6.6GB, donde he usado FlameRobin para marcar todos los items. que tienen en su historico como "pendites de facturar", lo cual de entrada ya le cuesta al SSD unos 12s, luego, desde mi aplicacion, le pido que se prepare para facturar todo lo pendiente (16s), y finalmente que genere las facturas... esto ultimo es lo que anda haciendo ahora.

Cuando tenga todos los numeros volvere y os podre los resultados, pero como le estoy pidiendo bastante carga de trabajo, va a tardar en las 4 pruebas bastante tiempo, pero prefiero las pruebas largas y "realistas" a las cortas, los tiempos son mas fiables a la hora luego de comparar unos con otros.

[Marc]

Muy interesante, gracias.

Pero creo estas pruebas se quedan cortas. Para probarlo de verdad, al máximo rendimiento posible, habría que instalar el sistema operativo en el SSD (y no solo Firebird y la base de datos).

El Sistema Operativo y las aplicaciones te deberían caber bien (pongamos que cojan un máximo de 20Gb) y deberían dejar espacio suficiente para bases de datos.

Claro que es un engorro instalar el Sistema Operativo de nuevo, además de que necesitas tener otra licencia de Windows 7 o Windows 2008 Server, pero eso te va a asegurar el mayor rendimiento posible (y que no haya cuellos de botella por ejemplo por llamadas al API de Windows que tengan que cargar unas DLL's de la carpeta \System32).

NOTA: Además yo desactivaría la paginación a disco (después de todo Firebird no es ningún traga-memoria, y 4GB de RAM ya es una cantidad muy respetable).

Naturalmente el disco duro magnético es bueno dejarlo, pero solo para almacenamiento adicional.

[Sergio]

Lo siento Marc, no me pienso darme todo ese curro, aparte no creo que sea para tanto el cambio, cualquier DLL que se cargue no va a influir en un proceso de 1 hora (influye mas que te responda desde la misma maquina donde se hacen las pruebas, pero bueno, son 4 nucleos, usar uno para mirar paginas web creo que puedo permitirmelo sin cambiar los resultados).

El proceso largo ya termino (datos en SSD, temporal en disco duro) y ha tardado 3473.856s = 57m 53s 856ms.

Ahora anda repitiendolo en el disco D: -tras reiniciar el servico de firebird para limpiar caches y esas cosas- y por el momento parece que tardara mas del doble (siempre con los temporales en C:).

Los dos primeros pasos "preparatorios" han tardado algo mas:

El primer paso en flamerobin paso de 12.315s en SSD a 17.737s en disco duro, y el segundo paso pasa de 15.787s en SSD a 18.376s en disco duro, mejora pero nada del otro mundo.

Esperemos a temrinar las pruebas, pero esperaba mas cambio, la verdad... igual una prueba de estress (varios procesos pidiendole cosas a la vez) da mejores resultados, ya veremos.

[Delphius]

Gracias Sergio por tomarte la molestia de hacer esa prueba "real life". No quisiera imaginarme lo que se tardaría en llevar dicha prueba en mi cachivache  mínimo 4 horas, con mucha suerte.

Quisiera preguntarte si en un futuro te animarías a correr la misma prueba que hicimos Casi y yo, aún sabiendo que no sería un caso "real life", como para tener una orientación.

Saludos,

[Sergio]

delphius: Claro que puedo correr la prueba que me digais, para eso compre el SSD, eso si, nada de reinstalarme el windows como dice Marc, a eso me niego! Comentame que script exacto usaste y esas cosas, aunque creo que en este mismo hilo estaba puesto, confirmamelo please!

Ayer termino la "prueba gorda" de generar 1800 facturas, y el resumen es que el SSD va poco menos del doble de rápido en estos casos (mucho trabajo seguido, pero ninguno "complicado" para FireBird, de hecho no se crean temporales en el proceso).

He llamado a cada prueba SC si los datos estan en S y los temporales en C (DC es todo en disco duro, por ejemplo), y como la prueba constaba de 3 procesos independientes (el 3 es el largo), uso SC1 para "datos en ssd, tmp en disco duro, primera fase de la prueba), y estos sonlos numeors que tengo:

Datos en SSD, tmp en disco duro:
---------------------------------------
SC1: 11.341/12.215 s.
SC2: 14.352 / 16.739 / 16.770 / 15.787s (lo pase 3 veces).
SC3: 3473.856s = 57m 53s 856ms.

Datos y tmp en discos duros distintos:
--------------------------------------------
DC1: 17.737s
DC2: 18.376s
DC3: 5262.734s = 1h 27m 42s 734ms.

Datos y tmp en el mismo SSD:
------------------------------------
SS1: 13.8 s
SS2: 16.879/12.012 (con/sin delhi detras) s
SS3: 3573.765s

Mi conclusion: Para uso poco intensivo no se gana nada. En procesos largos y pesados pero "en serie" (un solo proceso pidiendo cosas al servidor, que nunca tiene mas de 1 proceso a la vez), va casi al doble, y los temporales en estos dos casos no parecen afectar.

En el caso de temporales pequeños, de nuevo, el disco duro con sus 16MB de RAM va mejor que el SSD, aunque claro, si necesitases mas de 16MB de temporales, el SSD empezaria a interesar. Para probar esto necesitaria elegir una SQL especialmente "mala" (con filtros tipo LIKE '%TEXTO%' o 'ORDER BY' un campo de texto no indexsado), la semana que viene buscare alguna del estilo de las que tardan del orden de 2 o 3 minutos a ver como afecta el SSD.

Lo siguiente que quiero probar es hacer esto mismo (la fase 3 que dura tanto) pero dividiendo el trabajo en dos y poniendo 2 instancias de la aplicacion cada una a hacer una mitad del trabajo de forma simultanea, asi es como creo que la SSD se notara mas, ya que parece ser que no le afecta casi el tema de muchos accediendo a la vez a los datos.

[Delphius]

Hola Sergio, no hay apuro, tampoco es para que la hagas ahora. Lo que si hay es curiosidad 

Efectivamente, el script lo publicó casi en la primera hoja del hilo. 

Saludos,

[Sergio]

Pues este lunes, si me dejan mis clientes, lo intentare probar, delphius, porque ademas mis pruebas no me han convencido ni a mi: De correr la aplicacion desde dentro de delphi a hacerlo fuera, cambio de 17 a 12s una de las pruebas, asi que creo que para que fuese comparables los tiempos deberia haberlo hecho todo tras reiniciar el windows del todo (no solo resetear firebird como si que he hecho) y siempre de la misma forma... no pense que afectara tanto, pero claro, es una aplicacion "real" y tarda tiempo en hacer cosas con los datos que lee!

Asi que la semana que viene, aparte de probar a hacerlo desde dos aplicaciones simultaneas, quiero probar cosas mas fiables, como un backup/restore de una gran base de datos o el script de delphius que hace algo "repetible"... si al final habra que hacer las cosas bien!

Ah! Y si cualquiera quiere pasar un script con sentencias SQL en disco duro y el SSD para comprobar algo que le interese (por ejemplo una sql compleja que le come el tiempo a su apicacion a ver si el SSD ayuda o no), solo tiene que enviarmelo y le hago las pruebas (siempre que no incluya reinstalarme windows, Marc, que soy alergico) y pongo los tiempos, no problem (incluso contras una base de datos que se me envie por email o algo asi).

Enviadme un PM en caso de necesitar enviarme la base de datos, si es un script, aqui mismo vale.

[Sergio]

Ya temrino la prueba que propuso dlephius con le codigo que ahy en la primera pagina de este hilo, y no ha habido casi ninguna diferencia:

Disco duro: 8.965s (media de 3 medidas)
Total execution time: 8.923s
Total execution time: 9.079s
Total execution time: 8.892s

Disco SSD: 8.804s (media de 3 medidas)
Total execution time: 8.799s
Total execution time: 8.814s
Total execution time: 8.799s

SSD es solo un 1.8% mas rapido que el disco duro!

He puesto los temporales en C:\ mientras que la base de datos estaba en D: o S: así que no se han mezclado nunca, y reinicie FireBird y FalmeRobin entre prueba y prueba, además, me fio de los resultados porque las 3 medidas salen muy similares.

Ahora ando con un backup/restore de 6.6GB, por un lado probare S->D->S (fichero original en S:, .fbk en disco duro, fdb final en S de nuevo), luego S->S->S a ver que tal y finalmente D->C->D que seria la peor de las opciones, a ver que tal.

[Marc]

Muchas gracias Sergio.

Decepcionante resultado, esperaba bastante más. Está claro que los diferentes niveles de caché que hay entre el disco duro y su procesamiento (tanto a nivel de hardware como a nivel de software en el S.O.) consiguen reducir enormemente el efecto de las grandes latencias de los discos tradicionales.

Al menos esto quiere decir que no es necesario que tengamos ninguna prisa en gastar dinero para actualizar nuestros equipos .

Saludos.

[Sergio]

Pues Marc, el proceso de copia de seguridad / recuperacion, lo he repetido 3 veces con una base de datos de 6.6GB, y tarda lo mismo en los 3 casos (S->D->S, S->S->S y D->C->D), 13 minutos.

No he probado el caso "malo" de leer y grabar todo en el mismo disco duro, ese caso si que debe ser mucho peor, claro.

De momento, si solo hay una conexion a la base de datos, va mas o menos igual, excepto el caso extremo de generar 1800 facturas seguidas que en la SSD tardo poco mas de la mitad que en disco duro.

Ahora ando preparando esa misma prueba pero poniendo 3 procesos a generar facturas, cada uno me va a generar las facturas de 2 años de trabajo de la base de datos que uso, es decir, unos 25.000 items. vendidos en cada uno de los 3 casos.

Espero que esta prueba "mas realista" de unos resultados mas decentes, la verdad.

[Delphius]

Hola Sergio,
Te agradezco que te hayas tomado lo molestia de hacer dicha prueba. La verdad es que me esperaba una diferencia mayor.

Esto, si uno quiere sacar alguna conclusión apresurada, podría sugerir que en realidad el disponer de un disco SSD no es tan estrictamente necesario y útil. También nos confirma algo que ya sabíamos: Firebird hace las cosas bien, y sabe equilibrar velocidad con prestaciones.
A mi modo de ver ya no pasa tanto por una cuestión del poder de disco duro sino del procesador. ¿De que sirve tener un disco tan potente si no hay un buen equipo que le haga juego? 

Y a la inversa lo mismo: ¿Para que tanto cerebro si la carótida está llena de piquetes de grasas?

En mi equipo se tomó 2 min, en los de ustedes segundos... no lo discuto: son equipos muy diferentes en prestaciones. Pero en tema de discos se ve que no hay una gran diferencia si uno no está dispuesto a explotarlo como debe en un mismo equipo (como sugiere la prueba de Sergio sobre los diferentes discos). Se podría llegar a ganar más, en cuanto más se requiere de lecturas y escrituras de disco más rápidas y recurrentes... ¡No se le explotó su máximo poder! Como ha dicho... es necesario pruebas bien real life.

Es como decir pa' que vas a usar un Camión para recorrer la ciudad si vas a vivir atorado con el tráfico... ¡ahora si planeas mudarte y llevar tus autos cargalos en el camión y mandalo! Te ahorras viajes de hacerlo con cada uno.

Está más que comprobado que Firebird funciona en aquellas calles angostas que conducen a los pueblitos del interior como en las avenidas de acceso de las grandes metrópolis evadiendo lo mejor posible cualquier bache y obstáculo sin demasiados problemas, aprovechando lo mejor posible lo que ofrece la calzada y el terreno.   

Saludos,

[casi]

Yo también esperaba mucha más diferencia, así que hice la prueba en un disco de memoria ram, como tengo 4 Gb entonces usé 1 Gb para crear un disco:
mount ­t tmpfs ­o size=1G,nr_inodes=10k,mode=0700 tmpfs /mnt/hdram
Luego copié una BD a ese disco y realicé la prueba de crear la tabla y ejecutar el procedimiento, repetí 3 veces la prueba y la media fue de 6,6 segundos, no es gran cosa, aunque comparado con los casi 8 segundos que tardó en el disco "normal", es una ganancia de casi un 25%.
La conclusión es que la prueba no es muy válida en "la vida real" o que firebird está bastante afinado para sacar provecho de los discos normales.
Habrá que preparar unas pruebas más "reales".

[Sergio]

Casi: No compares mis 8s con tus 6s, debe de ser en la misma maquina, influye mucho el procesador y esas cosas segun mi experiencia. Repitelo en tu HD y asi podremos tener una idea de como compara un HD con un SSD y con un disco RAM. De todas formas, no es aplicable a un entorno real el usar un disco RAM para la base de datos, no solo porque es volatil, quer ya da miedo, tambien porque si tus datos crecen hasta 10 o 20GB, no hay RAM que lo aguante.

Delphius: los SSD no son para tanto, es verdad, yo tambien esperaba mas, pero ojo, todos estos tiempos que he recopilado son con UN solo usuario conectado, y cuiando realmente se debe de notar es con varios usuarios dandole trabajo a FireBird... aqui si que creo que se notará.

Bueno, de momento, lo que queda claro es que para un usuario solo -o un proceso- casi que lo mismo da, la diferencia entre HD y SSD es muy poca o nada, y solo se nota en procesos realmente pesados, y aun asi, no llega nunca al doble de rapido.

Ayer deje haciendo la prueba "buena", es decir, 3 aplicaciones usando la BD intensivamente para ver que tal responde el SSD en casos realistas de muchos usuarios concurrentes, que al fin y al cabo es lo que importa, que por tener 10 usuarios simultaneos no se quede el sistema resoplando.

La prueba que hice es la misma que ya os conte de generar 1800 facturas, que en SSD tardo 3473.856s (con el tmp en C: aunque no influye nada en este caso), pues la buena noticia es que, al hacerlo en tres procesos simultaneos (y no es coincidencia que sean 3 procesos + FireBird = 4 que son los procesadores que tiene mi maquina), ha tardado lo mismo casi exactamente, 3567.883s! (solo 94s de diferencia, un 2.7% mas que en un solo proceso).

Nota: Cada proceso tardo su tiempo, pero al ser simultaneos, me he quedado con el que termino ultimo, que tardo esos 3567.883s, los otros dos tardaron 3142.221s y 3422.320s, así que más o menos consegui que el trabajo se repartiese bastante bien entre los 3 procesos.

Esto quiere decir que el SSD aguanta muy bien el uso simultaneo de la base de datos por varios usuarios, incluso cuando todos andan pidiendole cosas complejas al servidor, y casi casi no se nota que estamos compartiendo el fichero con otros.

En el HD repetire esta tarde la misma prueba, pero es de esperar que el rendimiento caiga bastante respecto de cuando lo probe con un solo proceso (5262.734s) ya que es algo que vemos todos los dias en bases de datos con 10 o 20 conexiones simultaneas (o mas).

[casi]

Casi: No compares mis 8s con tus 6s, debe de ser en la misma maquina

Estaba comparando "mis" 8 segundos con "mis" 6 segundos, en "mi" misma máquina. La prueba la hice y lo reporté en uno de los primeros post de este hilo

[Sergio]

casi, entonces tenemos maquinas muy del estilo! Al leer 8s pense que eran los mios... el principio de este hilo ya me queda tan lejano!

Hablando de poner las bases de datos en RAM, tengo una anecdota curiosa, un caso real de una empresa cliente nuestra que hizo algo del estilo con consecuencias desastrosas.

Nos llamaron porque habian tenido un corte de luz, y la base de datos aparecio totalmente destrozada. Bueno, es raro pero puede pasar, le dijimos.

"No, tenemos un UPS de los buenos y funciono, asi que deberia estar el fichero perfecto" me dijeron... que raro!

Resumiendo: Su informatico "maquinero" les puso 32GB en el servidor y, supongo que para justificar el precio, les dijo que podía configurar la base de datos para que volase con tanta RAM... lo configuro y suponog que no volaba tanto, asi que desactivo (en una maquina windows) el ForceWrites, es decir, los cambios se quedan en RAM hasta que la RAM se llena y son volcados a disco.

Claro que volaba, usaba los 32GB como disco RAM! El problema es que estubieron asi varias semanas, sin que el disco grabase nada de nada, todo quedaba en RAM.

Cuando se fue la luz, el UPS saltó y aviso al sistema por USB del problema, asi que todas las aplicaciones empezaron a cerrarse. FireBird recibio la señal, y comenzo a volcar todos los cambios de esas semanas a disco... y eran bastantes cosas que tenia ahora que replicar una a una en la base de datos.

Pasada media hora, el UPS cerro el grifo, y FireBird no habia tenido tiempo de volcar los 32GB a disco... se perdio todo todo todo!

[casi]

sí, también me he encontrado en alguna ocasión a "listillos" que han hecho eso mismo... y el resultado final ha sido similar: pérdida de datos de una semana por lo menos

[Marc]

La verdad es que ese es un fallo increíble de Windows.

Puesto que en Linux las grabaciones no-forzadas (es decir, se trabaja en memoria y el sistema graba en disco cuando tiene ciclos libres) parece ser que funcionan perfectamente.

Es difícil de concebir que Windows Server pueda tener un fallo tan monumental, es más fácil pensar que necesita una programación adicional a medida y los chicos de Firebird no han adaptado el motor teniendo en cuenta esos requerimientos de las grabaciones atrasadas en Windows.

Después de pegar unas buenas collejas a ese informático por tocar un parámetro que en Windows está totalmente contraindicado, quizás les deberíais informar que pueden trabajar con esa configuración bajo Linux.

Saludos.

[casi]

Salvo dos pequeños clientes que no quieren, todos los demás que tenemos les montamos linux, desde 1999, y antes montábamos unix.
Salvo problemas físicos de disco nunca hasta ahora (toco madera) hemos tenido ningún problema con una BD firebird. Recalco lo de 'nunca' porque es así, nunca (vuelvo a tocar madera)
Y casi todos los clientes tienen BD de varios gigas, uno de ellos tiene ya casi 30 GB y como si nada.

[Sergio]

Si, FireBird en Windows NO PUEDE tener desactivado ForcedWrites, deja de grabar... a no ser que quieras ir en plan kamikace, claro.

Según me contaron, Linux tiene sistemas "incluidos de fabrica" para gestionar los ForcedWrites=OFF pero en windows no hay nada similar (hablo de memoria de unas conferencias), pero ojo, hasta la V2.1 en linux *nunca* han funcionado los ForcedWrites=ON... da miedo pero es asi: http://www.firebirds...-fwrites-frnscs asi que no es oro todo lo que huele a unix!

Yo si que he tenido muchos problemas con bases de datos en Windows, pero es normal, el 99% de mis clientes usan servidores Windows, y son muy dejados, asi que es normal. En linux, pues tenemos las nuestras, y creo que nunca hemos tenido ningun problema, pero me huele a que es solo cuestion de suerte (un servidor linux suele tener un administrador que sabe lo que se hace, en caso contrario, ponen windows y cruzan los dedos).

Lo que si debe ser una pasada es montar FireBird en un disco con formato ZFS, pero de momento solo lo tiene Mac server... este sistema de ficheros es transaccional y muchas cosas mas, es una pasada, vamos, pero en windows como que no les dan permiso y esas cosas (es de Sun.ahora Oracle). Buscar un google si quereis babear.

[Marc]

Según me contaron, Linux tiene sistemas "incluidos de fabrica" para gestionar los ForcedWrites=OFF pero en windows no hay nada similar (hablo de memoria de unas conferencias), pero ojo, hasta la V2.1 en linux *nunca* han funcionado los ForcedWrites=ON... da miedo pero es asi: http://www.firebirds...-fwrites-frnscs asi que no es oro todo lo que huele a unix!

Que curioso. Gracias, estaba convencido de haber leído varias veces en los foros oficiales que los Forced Writes se habían podido activar siempre sin problemas en Linux. Pero está claro que es un error, que no hacía nada.