PDA

Ver la Versión Completa : Dudas con Ubuntu server


Sergio-ponchito
07-05-2015, 12:52:21
Hola buenas, soy nuevo en este tema de firebird.

Acabo de montar 2 servidores de prueba uno con Windows Server 2012 y otro con Ubuntu server 14.04 LTS, ambos con las mismas características (4 cpu, 4 gb RAM y 2 discos duros, uno para el sistema y otro para almacenar la base de datos). Ambos sistemas estan funcionando con la ultima versión de Firebrid 2.5 de 64 bits y utilizando UDF Freeadhoc.

Cuando realizo una consulta sin utilizar la cláusula 'Where' el tiempo es de 900 ms en ambos sistemas, pero cuando añado un where ubuntu cambia de 900 ms a 3-4 segundos y windows sigue en los 900ms o menos.

¿A que puede ser debido este cambio de tiempo?

Casimiro Notevi
07-05-2015, 13:48:45
Hola, bienvenido a clubdelphi, por favor, no olvides leer nuestra guía de estilo (http://www.clubdelphi.com/foros/guiaestilo.php), gracias.

En cuanto a tu pregunta, tendrás que dar bastante más información, porque así es imposible ayudar.

MAXIUM
07-05-2015, 15:10:04
¿Como era eso de Server, Super Server y Clasic?

duilioisola
07-05-2015, 15:48:35
Además de lo que dice MAXIUM:

¿Tienes en cuenta el tiempo de conexión?
La conexión puede tardar bastante, comparado con las consultas, pero se realiza solo una vez.

También tienes que tomar en cuenta si es la primera consulta o las siguientes...
Si quieres hacer una prueba, monta algo para que haga una consulta y luego vuelva a repetir, pasando al where valores al azar.
La primera vez, leerá varias páginas de índices y esas cosas. Una vez que tenga eso en cache, puedes hacer la media de los resultados que obtengas.

Tampoco es lo mismo en una base recién restaurada que en una que se ha estado usando... aunque esto no se realmente porqué es...

Sergio-ponchito
07-05-2015, 16:40:19
Ambos sistemas usan firebird 2.5 Superclassic, se encuentran en el mismo servidor (los 2 servidores y el equipo de pruea estan virtualizados con VMware esxi, con tarjetas de red de 1gbps).

Os pongo un ejemplo de las consultas:

select * from wie_intern_viajes_sin_obs
where codigo > 0

------ QUERY PERFORMANCE ------
Prepare : 31 ms
Execute : 31 ms
Avg fetch time: 0 ms

----------- MEMORY ------------
Current : 66,93 MB
Max : 67,02 MB
Buffers : 4096

Tiempo 985ms

En ambos sistemas esta consulta suelen ser tiempos muy parecidos

select * from wie_intern_viajes_sin_obs
where codigo > 0
and ano_viaje=2015

------ QUERY PERFORMANCE ------
Prepare : 16 ms
Execute : 16 ms
Avg fetch time: 14 ms

----------- MEMORY ------------
Current : 67,00 MB
Max : 67,09 MB
Buffers : 4096

Ubuntu : 2500ms
Windows: 1550ms

Este es un ejemplo de las consultas que como podeis ver en linux tarda bastante más pero hay otras consultas donde windows llega a 3000ms como máximo y linux de 8000ms no baja :(
La base de datos estaba funcionando sobre una version 1.5 y acabamos de realizar la migración para la 2.5

Casimiro Notevi
07-05-2015, 17:47:47
Ambos sistemas usan firebird 2.5 Superclassic, se encuentran en el mismo servidor (los 2 servidores y el equipo de pruea estan virtualizados con VMware esxi, con tarjetas de red de 1gbps).

Eso no son dos ordenadores iguales.

Sergio-ponchito
07-05-2015, 17:52:14
Eso no son dos ordenadores iguales.
Maquinas virtuales diferentes con mismo hardware

duilioisola
07-05-2015, 18:15:21
Otra cosa que se me ocurre es que modifiques el tamaño de página de la base firebird.
Normalmente debería ser igual al tamaño del cluster del disco.
Esto influirá sobre todo si el tamaño de la base de datos es grande. Con esto me refiero a muchos registros por tabla, no a blobs.

De todos modos, no entiendo de dónde sacas esos números.
3000ms y 8000ms son 3 y 8 segundos respectivamente.
La información de las ejecuciones que muestras en el hilo anterior es aproximadamente mil veces menor (31ms en el primer caso)

Hay varios tiempos que deberías tener en cuenta:
1 - El de preparado
2 - El de ejecucion
3 - El de obtención de datos.

Si pides algo simple, pero la tabla tiene 1 millon de registros, el tiempo de preparado y ejecución será rápido pero el de obtención de datos no (1 millon de registro x tamaño del registro pasando por la red).

Sergio-ponchito
07-05-2015, 18:33:22
1 - El de preparado

31

2 - El de ejecucion

31

3 - El de obtención de datos.

985

¿Lo que no entiendo por que al introducir un where, que siempre te va a devolver menos registros, como puede tardas más que sin tener un where?, y ya lo que me extraña es que algunas consultas el tiempo sea el mismo que haciendolo desde windows server pero en otras tarde hasta 3 veces mas?

duilioisola
07-05-2015, 19:16:24
Vale, pero seguimos sin tener datos completos:
Has puesto la respuesta al tiempo, pero no sabemos de qué:
¿a qué consulta? (con/sin where)
¿en que sistema operativo? (win/linux)
¿qué es lo que devuelve? (nro de registros, tamaño, blobs, ...)

Además de esto, no sabemos que plan utiliza en cada caso (con/sin where, Win/Linux).
Tampoco nos dices si la cosa cambia cuando modificas el tamaño de página de la base de datos.

Todo esto, suponiendo que te conectas a ambas bases de datos de la misma manera (TCP / Local) y que las bases son iguales (restauradas de un mismo FBK).
Windos: IP:C:\Path\BASE.FDB
Linux: OP:/path/base.fdb

También debes considerar lo que he dicho antes. Debes hacer la consulta de forma repetida. La primera vez tardará, pero las siguientes te dará una idea aproximada de lo que tarda cada consulta. El servidor debe preparar la conexión, montando cache, reservando memoria y haciendo las verificaciones necesarias.

Finalmente, habría que ver qué mas está haciendo el servidor en cada caso (Firewall, Servicios activos, antivirus, etc.)

Cuando tengas todas las pruebas hechas y puestas en una tabla, podrás comparar siempre y cuando sean datos comparables. Por ejemplo, no es lo mismo una consulta en modo local que una a traves de TCP/IP, aunque los ordenadores sean iguales.

Bueno... dejo aquí esta parrafada porque creo que te faltan hacer muchas pruebas antes de poder decidir qué servidor elegirás.

Casimiro Notevi
07-05-2015, 20:52:18
Vale, pero seguimos sin tener datos completos:
Has puesto la respuesta al tiempo, pero no sabemos de qué:
¿a qué consulta? (con/sin where)
¿en que sistema operativo? (win/linux)
¿qué es lo que devuelve? (nro de registros, tamaño, blobs, ...)
Además de esto, no sabemos que plan utiliza en cada caso (con/sin where, Win/Linux).
Tampoco nos dices si la cosa cambia cuando modificas el tamaño de página de la base de datos.
Todo esto, suponiendo que te conectas a ambas bases de datos de la misma manera (TCP / Local) y que las bases son iguales (restauradas de un mismo FBK).
Windos: IP:C:\Path\BASE.FDB
Linux: OP:/path/base.fdb
También debes considerar lo que he dicho antes. Debes hacer la consulta de forma repetida. La primera vez tardará, pero las siguientes te dará una idea aproximada de lo que tarda cada consulta. El servidor debe preparar la conexión, montando cache, reservando memoria y haciendo las verificaciones necesarias.
Finalmente, habría que ver qué mas está haciendo el servidor en cada caso (Firewall, Servicios activos, antivirus, etc.)
Cuando tengas todas las pruebas hechas y puestas en una tabla, podrás comparar siempre y cuando sean datos comparables. Por ejemplo, no es lo mismo una consulta en modo local que una a traves de TCP/IP, aunque los ordenadores sean iguales.
Bueno... dejo aquí esta parrafada porque creo que te faltan hacer muchas pruebas antes de poder decidir qué servidor elegirás.

Exacto, y añadir también qué componentes o útiles está usando, qué configuraciones, si la base de datos tiene índices adecuados, si son querys "directos" o filtros tipo "ADO" que se trae todos los registros, etc. etc. etc. ... ... ...

Sergio-ponchito
07-05-2015, 23:25:33
Al parecer el fallo estaba en las udf 'freeadhoc', he cambiado las vistas usando las funciones propias de firebird y el cambio ha sido enorme de 8 segundos a 500 ms.
Muchas gracias por la ayuda a todos, saludos!

Casimiro Notevi
07-05-2015, 23:50:03
Una duda, ¿por qué motivo necesitas usar freeadhoc?

Sergio-ponchito
07-05-2015, 23:56:05
Pues estaba utilizándolo por que ya me encontré la base de datos así, había entrado en practicas en una empresa y se usaba de esa manera en la versión 1.5

Y su uso lo que se hasta el momento era para sacar el año, mes o día de una fecha y otras funciones como upper o trim y no se si alguna mas en especial :D

Ahora toca actualizar la base de datos para quitar freeadhoc :D

Casimiro Notevi
07-05-2015, 23:58:57
Es que puedes dejar de usarlas en cualquier momento, no las necesitas.

Sergio-ponchito
08-05-2015, 00:01:43
Ese será mi trabajo estos días :D

Muchísimas gracias por la ayuda a todos