66 respuestas en este tema

[Sergio]

Si, Marc, da algo de miedo... menos mal que las caches de disco en linux van muy bien, que si no la liamos parda! (y es fallo del kernel reportado en el 2006, como dicen el link "The Firebird developers have no idea why such a bug would remain unfixed almost two years after getting into the Linux kernel's bug-tracker. Apparently, in Linux, a documented bug evolves into a feature...").

Ya encontre el caso del windows y los force writes OFF aqui http://www.firebirds...g15-safety.html: El propio windows permite usar la cache de disco para estas cosas, como en linux, pero no se preocupa de ir poco a poco pasandolo a disco, se espera a que cierres el proceso: "It has been observed that the Windows server platforms do not flush the write cache until the Firebird service is shut down."

Asi que ni linux ni windows es de fiar... al final vamos a terminar con un Mac de server con su flamante ZFS!

[casi]

Qué dura es la vida, ¡¡¡ seguiré tocando madera !!!

[Delphius]

Hola,
Sergio, por eso mismo había dicho que si uno quiere sacar conclusiones apresuradas... 
Seguramente el disco SDD es mucho más efectivo y útil en cuanto más exigencias se necesite pero si no se está contemplando situaciones en la que se lo explote demasiado no vale demasiado la pena; lo que quise recalcar es que Firebird sabe trabajar bastante bien con ambos y puede adaptarse a muchos terrenos y no necesita de una calzada bien asfaltada para llegar a destino; ya de por si hace bien su trabajo con poca cosa.

Saludos,

[Sergio]

Bueno, ya termine todas las pruebas que tenia previsto hacerle al SSD, y la ultima ha sido la mas decepcionante de todas!

La "prueba gorda" ha sido generar 1800 facturas, y lo he hecho de 4 maneras diferentes: un proceso en SSD, un proceso en HD, tres procesos en SSD y tres procesos en HD. Os pongo los 4 tiempos:

1 proc. en H.D.: 5262.734s
1 proc. en SSD: 3573.765s
3 proc. en SSD: 3567.883s
3 proc. en H.D.: 3458.464s


Que quereis que os diga... que paso totalmente de sacar conclusiones, el caso mas desfavorable ha resultado ser el que menos tiempo ha necesitado... no entiendo nada, pero no os gasteis mucho dinero en cambiar el disco duro del servidor por un SSD, al menos de momento no merece la pena.

[casi]

Bueno, hay que ver el lado positivo, uno de ellos es que seguramente ese proceso necesita una revisión para que sea más rápido porque parece ser que el tiempo que tarda no es por el disco sino por la cpu, seguramente, así que te toca depurar ese proceso
Y la de dinero que nos vamos a ahorrar en NO comprar estos discos

[Marc]

Bueno, hay que ver el lado positivo, uno de ellos es que seguramente ese proceso necesita una revisión para que sea más rápido porque parece ser que el tiempo que tarda no es por el disco sino por la cpu, seguramente, así que te toca depurar ese proceso

Sí, tienes toda la razón. La única explicación es que este proceso viene marcado por la CPU y no por el acceso a disco. De ello yo aventuro dos conclusiones :

1) El Disco SSD solo vale la pena cuando tienes decenas (cuando no centenares) de usuarios simultáneos.

2) Probablemente el proceso que más notaría la mejora con un disco SSD, sería un proceso que no estuviera optimizado en absoluto. Me explico, con los índices adecuados, una única consulta solo necesita un acceso puntual al disco, por lo que la mejora de tecnología de disco no se nota demasiado (otra cosa sería si tuviéramos bastantes consultas simultáneas). Pero en cambio, si eliminamos todos los índices de la base de datos, entonces cualquier consulta tendrá que leer la totalidad de la tabla, con lo que entonces se debería notar la mejor tecnología SSD.

Es decir, ¿ quieres que se note el disco SSD ?, revisa tu proceso y des-optimizalo al máximo (hacer eso es una auténtica burrada, pero parece que es la única forma en que un disco SSD sea decisivo para un entorno de pocos usuarios).



NOTA: Sergio, ¿ te apetece volver a repetir el test en disco y en SSD, habiendo quitado primero todos los índices implicados ?.

[Sergio]

Bueno, hay que ver el lado positivo, uno de ellos es que seguramente ese proceso necesita una revisión para que sea más rápido porque parece ser que el tiempo que tarda no es por el disco sino por la cpu, seguramente, así que te toca depurar ese proceso

No te creas, el proceso no es tan desastroso internamente, piensa que en el sector en que me muevo, se hacen pocas facturas pero muy gordas, asi que lo normal serian 30 o 40 facturas/mes, y eso tarda unos 10 segundos. Lo que pasa es que mandarle generar 1800 facturas equivale a todo lo trabajado durante 6 o 7 años, es mucha tela, y la CPU tiene que echar humo si o si. La dua era si el HD aun lo penalizaba más o no.

NOTA: Sergio, ¿ te apetece volver a repetir el test en disco y en SSD, habiendo quitado primero todos los índices implicados ?.

Marc, coincido en lo que dices, se debe de notar con muchos usuarios simultaneos o si el diseño de la base de datos está hecha un sabado de madrugada al volver de una fiesta... pero no puedo repetir estas pruebas sin los indices, me puedo morir, piensa que ya tarda del estilo de 1 hora con indices "bine pensados", sin ellos, me quedo sin maquina una semana.

Pero hay otra forma de comprobar eso que dices: Pedirle listados normalitos, pero con filtros elegidos por un ejecutivo de Oracle para desprestigiar a FireBird... y acabo de hacerlo, y ahora SI que se nota el SSD!

Acabo de borrar 7 u 8 ejemplos de SQL con filtros malos, me he dado cuenta de que si no se reinicia la mauqina al completo, las diferencias son enormes entre 2 intentos, aunuqe se reinicia el Firebird. Supongo que el cahce de disco y esas cosas afecta demasiado para olvidarse de el... quizas sea este el problema de que todas las pruebas hayan dado resultados tan tan increibles (incluida la primera prueba del inico del post).