Rendimiento Servidor

[Neeruu]

La versión de Firebird es la 3.0.12 ( ultima actualización de FB 3) 64bit...
1 Procesador con varios core?

Tengo configurado: CPU = 20
Núcleos por Socket = 2 ( 10 Socket)

[chenech]

Usa affinity a una CPU, es lo que yo hice, pero igual es otra cosa claro, vete a saber, a mi me pasó en el 2020.
Si puedes probar a configurar un núcleo y ya si pasas a SSD sería un gran salto, seguro.
Los core no lo se, eso lo hizo un compañero y me dejó anotado las CPU solamente.

[Neeruu]

Estoy probando cambiar la cantidad de cpu y nucleos por socket, pero no obtengo cambios...

[chenech]

Lo has probado en un equipo en local con una configuración de memoria y disco similar sin VM a ver si esa es la velocidad normal y el que tienes en la nube es demasiado rápida?

[Neeruu]

Estoy empezando a pensar que el problema realmente viene por el tipo de disco duro del servidor...

En mi server del tengo un disco sas (1.2TB 10K RPM SAS) y en la virtual en la nube tengo disco ssd...

[Casimiro Noteví]

Primero de todo, ¿windows? por favor, quita eso e instala linux.
Después, un disco mecánico será siempre al menos entre 5 y 10 veces más lento que un ssd. Y comparado con los nuevos m2 ya ni te cuento.
Y para acabar, lo más importante, ¿30 o 50 segundos para una consulta? obviamente eso está mal, una consulta no puede tardar eso salvo que estés recabando una tremenda cantidad de información estadística de muchos años acumulados y montones de cálculos de todo tipo.

[mamcx]

Empezado por Neeruu

Estoy probando cambiar la cantidad de cpu y nucleos por socket, pero no obtengo cambios...

No le veo el sentido a ponerle una sola CPU/Core.

Un RDBMS moderno esta optimizado para multi-core.

Empezado por casimiro

Y para acabar, lo más importante, ¿30 o 50 segundos para una consulta? obviamente eso está mal

Definitivamente. Mirar que arroja el query planner en ambos equipos seria muy ilustrativo.

[Neeruu]

Hola a Todos...

Gracias por sus respuesta.

Primero, si, la consulta esta muy mal escrita y optimizada, pero me sirve para poder apreciar de manera mas significativa la demora de respuesta en los servidores...

Ahora una pregunta, y perdón si es tonta...
Si conecto un disco ssd externo, muevo la base de datos a ese disco externo, reinicio el servidor y pruebo la consulta, debería mejorar si fuere problema de disco o la cache y todo se sigue escribiendo en el disco mecánico?

Se que hay una gran diferencia en el tiempo de respuesta y necesito poder determinar si es procesador, disco, la virtualización, etc...

Poniendo un segundo disco externo ssd y colocando la base de datos en el mismo mejorara el rendimiento o debería montar toda la vm en un ssd?

Desde ya muchas gracias por sus respuestas...

[Casimiro Noteví]

Si conoctas el disco de forma externa entonces seguramente lo harás por USB (más lento), no por SATA. Si lo conectas por SATA entonces no habrá diferencia.
Aparte me ha parecido entender que el servidor está en una máquina virtual, eso no es nada bueno, es otra capa más para hacerlo más lento.
Y en cuanto a que tus pruebas te sirve para saber si es más o menos lento que una sentencia sql ineficaz, entonces debo decirte que eso no es así, eso no sirve para nada.
Lo principal de todo es tener un select eficiente, todo lo que tarde más de 1 segundo es ineficiente.

[chenech]

Esa prueba no la he echo nunca, pero debes tener en cuenta la velocidad del USB, por muy rápido que vaya el disco, tendrás un cuello de botella en el USB.
No es lo mismo directamente a placa que a través de un puerto USB. Si copias archivos a un disco por USB, aunque sea SSD, no irá mas rápido que la velocidad de transferencia del USB.
La verdad que si lo haces comenta por aquí, para aprender todos. Si puedes probar haciéndolo así y conectando el disco internamente mejor, ten en cuenta también la carpeta temporal para Firebird, es importante que esté en el disco SSD.
Un saludo.
Edito: No había visto la respuesta anterior.

[Neeruu]

Con respecto de poner la base de datos en disco externo ssd (conectado por USB 3.0 ) los resultados de rendimiento siguen siendo iguales. (mas rápido en la vm en la nube). Los tiempos de respuesta son iguales.

Estoy viendo de poder montar todo un disco ssd para mover la vm al disco de ssd y hacer las pruebas todo sobre un ssd.

Comparto lo que dice Casimiro sobre la conexión, tenia la esperanza de ver algún cambio como para encaminar la solución por ahí pero entiendo que capaz la cache del firebird se sigue guardando en los discos mecánicos, entonces es lo mismo, por eso estoy viendo de hacer la prueba completa sobre ssd.

Con respecto a la consulta, ejecute otras consultas optimizadas, (lo mas optimizadas que mi conocimiento puede generar) todas lecturas indexadas, partiendo siempre de la tabla que menos registro tiene, etc... Y el tiempo siempre es mas rápido en el servidor en la nube...

Y si a alguien se le ocurre algo, aunque parezca loco, aviso... necesito ver cual puede ser el problema para poder ver que acciones tomar...

Gracias por todas las respuestas... siempre son de gran ayuda.