Rendimiento Servidor

[Neeruu]

Hola a todos... buenos dias...

Les hago una consulta haber si pueden ayudarme...

Tengo una maquina virtual, creada por mi, en un servidor dell 730. (instalado físicamente 48 gb de ram y un procesador E5-2660 2GHZ)
La vm tiene 16gb de ram, 20 core asignados.

Y tengo otra vm contratada a un proveedor en la nube.

El tema es que estaba haciendo unas pruebas de rendimiento de una consulta sql sobre firebird y veo que la vm contratada en la nube ( que la uso para testing ) es mucho mas rápida que la de mi servidor.

Esta vm de testing tiene 8gb de ram, 6 core, y un procesador de 2.9ghz.


A que voy con mas rápida, una consulta (mal optimizada ) en mi servidor de testing tarda 28 segundos y en mi servidor de producción (dell) 58segundos.

Aclaro que ambos servidores tienen la misma versión de firebird, la misma configuración de firebird, la misma copia de la base de datos.


Mi consulta es, puede esa diferencia de Ghz en el procesador hacer semejante diferencia? o estara mal configurado mi virtualización en el dell...

Cualquier luz me sirve... aclaro que no soy ningun experto en virtualización.

[Casimiro Notevi]

Hay muchas cosas a tener en cuenta, por ejemplo, tipo de disco (mecánico, ssd, m2, etc.), si ambos sistemas firebird son iguales (superserver, classic, superclassic), la capacidad de los discos, si el directorio temp está declarado en el mismo disco o en otro disco, o en memoria ram...) , el sistema operativo instalado en ambos.
Son muchas cosas.

[mamcx]

Apuesto que la nube tiene SSD. Y probablemente un mejor networking incluso si tu vm es local.

[chenech]

¿Que versión de Windows y de VM? Me ocurrió algo parecido, y en la de menos memoria y menos procesador iba mas rápido y al cambiar de Windows server a otra versión y tocar un parámetro en la configuración del VM se solucionó. creo recordar que era el server 2019 el del problema, pusimos uno mas antiguo y volaban las consultas.
Fue hace tiempo, intentaré buscar si tengo anotado el cambio, de todas formas hecha un vistazo a esto a ver si te aclara algo.
https://ibexpert.net/pdf/Requirement..._EN_202402.pdf

[Neeruu]

En la vm del servidor windows server 2016, en la nube windows server 2019.
Yo virtualizo con vmware (version 6.7) , con que esta virtualizado en la nube nose...

Probé crear otra virtual en mi servidor con windows server 2019 y los resultados son iguales a la vm con windows server 2016. Con esto descarte que sea algo de windows ( a menos que arrastre el error en las 2 vm propias ).

En disco en el servidor dell es mecánico y en la nube puede ser que sea ssd en la nube ( no tengo certeza de eso )

@chenech te agradecería si puedes encontrar esa configuración...

Saludos.

[chenech]

Lo encontré, el problema era que tenia configurados 4 CPU, lo cambie a 1 y se solucionó, también probé antes con affinity a un procesador e iba mejor, el servidor era para firebird exclusivo, también cambié la versión de Windows Server a una anterior, a la 2012, tenía la 2019 y ahí ganó mas.
Que versión de Firebird tienes inslatada? Ten en cuenta que Firebird recomienda la versión de 64 bits para usar affinity, en la de 32 creo que no está soportado.

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

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

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.

[mamcx]

A ver, empecemos mas basico.


1. Recoje datos precisos de ambas maquinas, no solo `CPU de X ghz` sino modelo exacto. Hay grandes diferencias entre una CPU de 3.0 de hoy a una de hace 10 años. Igual con el SSD, memoria, tarjeta de red, versionando de SO, version de firebirds. Valores *exactos*

2. Seria bueno saber la estructura de las tablas, que indices tiene, y un mini ejemplo de datos

3. Corre la consulta con el query planner, usando conexion de localhost/directa en ambas maquinas, usando la misma herramienta. Diria yo con `isql`ya que dice:

https://www.firebirdsql.org/file/doc...reference.html

A more detailed plan can be obtained when you enable an advanced plan. In isql this can be done with SET EXPLAIN ON. The advanced plan displayes more detailed information about the access methods used by the optimizer, however it cannot be included in the PLAN clause of a statement. The description of the advanced plan is beyond the scope of this Language Reference.

[Neeruu]

Voy a comunicarme con el proveedor de la vm en la nube para solicitar los datos mas precisos y los publicare...

Muchas gracias por todo...