Rendimiento de Firebird 2.5.1 64bits en Centos 6.2 64 bits

[briast]

Hola. Gracias por las respuestas. Voy a probar la superclassic como decís y os cuento como va.
Respecto a lo que comenta Casimiro:
- migrar de la 1.5.6 a la 2.5.1 es muy conveniente. Hasta ahora en todas las instalaciones que he realizado sin cambiar el servidor ha aumentado el rendimiento de la bd. Además, utilizo ya en la aplicación parte de las novedades en el Sql que tiene dicha versión por lo que era obligatorio el cambio.
- me extrañó mucho los requisitos de kernel de Linux para la 2.5.1. Aunque la centos 5.5 es antigua, tampoco lo es tanto, pero el kernel mínimo exigía la 6.
- he instalado la máquina con el s.o. de 64 bits, por lo que lo lógico es ponerle el firebird 64 bits. Nunca mezclo, y desde que hay versiones para 64 bits pongo la que corresponde según la máquina.
- Aún teniendo un SAI, no me gusta la idea de poner el force write a off. Me siento màs seguro puesto a ON y la verdad es que nunca he tenido ninguna incidencia con ello.
- el micro es un xeon de 4 núcleos y en Linux la superserver en la 2.5.1 creo que si los aprovecha tal como indica aquí firebirdsql.org/manual/qsg25-classic-or-super.html en el apartado de multiprocesamiento.

Un saludo

[briast]

Pues después de instalar el CS 64 bits, el resultado es el mismo. Sigue igual de mal.
Voy ha hacer una prueba más poniendo la SS pero de 32 bits (aunque el S.O. esté en 64). Ya por descartar una cosa que no me había dado cuenta y es que la versión 64 pone AMD64. Supongo que esto será porque fueron los primeros procesadores de 64 bits, y no porque no sea compatible con micros Intel.

Mucho me temo que el problema va a ser efectivamente el ext4.

[[birmain]]

Un saludo a todos.

Hace un par de meses hice una importante migración desde Firebird 1.5.6 32 bits arquitectura Super Server en un sistema Windows 2003 32 bits de dos procesadores, cuatro núcleos y 2GB de RAM a Linux (Ubuntu 11.10 kernel 3.0.15 server 64 bits sistema de archivos ext4) y Firebird 2.5.1 64 bits en arquitectura Classic Server. Tamaño de página 8192, número de páginas 8192, lo que hace un total 65536 KB por conexión. Parece mucho para lo que aconsejan por defecto, pero hice pruebas y esta era la configuración de mas rendimiento. Teniendo en cuenta la memoria del sistema, el número de conexiones (No mas de 50) y que está completamente dedicado a la base de datos para mi es lo más adecuado.El ordenador tiene cuatro procesadores y 8 núcleos con 8 GB de RAM,

Antes de decidirme, en el período de estudio hice numerosas consultas en internet, en todos los idiomas (¡ bendito traductor !) y encontré opiniones y resultados de todo tipo, pero me di cuenta de una cosa: El gran número de factores que determinan un adecuado rendimiento. En los debates me encontré que un cuello de botella, puede producirlo infinidad de factores, desde la tarjeta de red, el disco duro, los archivos temporales, el sistema de archivos, la configuración de la memoria caché y algo muy importante: el diseño de la base de datos.

Basándome en estas experiencias, y confiando bastante en mi diseño basado principalmente en el trabajo del lado del servidor (Más de 500 stores procedures trabajando duro tanto para generar informes como procesos) me decidí a a la migración. El resultado espectacular: procesos que tardaban 3 minutos ahora tardan 25 segundos, todos y cada uno de los procesos ha mejorado de rendimiento, y el backup restore se ha visto mejorado unas 10 o 15 veces en su velocidad. Una base de datos de 1.5 GB un backup tarda menos de dos minutos si se realiza localmente y unos 10 si se hace a través de la red. Desde delphi los componentes de acceso a los datos que utilizo es la VCL de acceso a Firebird/Interbase IBDAC de Devart, Utilizo Crystal Report para los informes pero todos se preparan con procedimientos almacenados, y el motor de Crystal Report se conecta a través de ODBC con el driver de Phoenix.

El servidor no es nada del otro mundo: HP Proliant, pero he tenido suerte, no me he encontrado un cuello de botella y todo a ido a mucho mejor. Sobre todo estoy satisfecho por el ahorro en la compra de un server Windows 2008

Un saludo

[Casimiro Noteví]

Empezado por briast

Ya por descartar una cosa que no me había dado cuenta y es que la versión 64 pone AMD64. Supongo que esto será porque fueron los primeros procesadores de 64 bits, y no porque no sea compatible con micros Intel.

Bueno, eso ya te lo dije antes

Empezado por Casimiro notevi

Sólo hay una versión de firebird que sirve tanto para 32 como para 64 bits. Lo que sí existe es una versión especial para AMD 64.

[[birmain]]

La versión genérica para procesadores de 64 bits se denomina AMD64, y está soportada por cualquier procesador de 64 bits que esté soportando el sistema operativo, sea Intel o AMD o cualquiera que sea.

Cuando desde isql-fb en Linux, se ejecuta el comando; show ver;, muestra la versión del servidor instalado, y en mi caso que tengo un procesador Intel aparece esto:

Código SQL [-]
ISQL Version: LI-V2.5.1.26351 Firebird 2.5
Server version:
Firebird/linux AMD64 (access method), version "LI-V2.5.1.26351 Firebird 2.5"
Firebird/linux AMD64 (remote server), version "LI-V2.5.1.26351 Firebird 2.5/tcp (servidor-fgh)/P12"
Firebird/linux AMD64 (remote interface), version "LI-V2.5.1.26351 Firebird 2.5/tcp (servidor-fgh)/P12"
on disk structure version 11.2

[Casimiro Noteví]

Que yo sepa, y por lógica, la versión AMD64 está pensada para sacar partido a una serie de características de los procesadores AMD.
Ahora bien, que funciona también si lo usas con un Intel, por supuesto, son compatibles, tan sólo que no sacará provecho de esas ventajas específicas para AMD.
Por lo demás, tienes razón.

[mankeke]

Disculpa, como mides el rendimiento del motor? por el funcionamiento de tu aplicación? porque yo estoy migrando un sistema que funciona perfectamente en 1.5 pero al intentar usarla con 2.5, se pone muy lenta, lo que hice fue empezar a depurar la aplicación y mi problema por ejemplo es el componente de conexión de mi aplicación que no funciona correctamente con algunas consultas en versión 2.5 de firebird y pone muyyyy lento el sistema. pero modificando las consultas que ya se tienen problemas, va quedando muy bien, anda muy rápido. y la mejora es bastante notoria.

[briast]

Hola. Pues después de realizar más pruebas he llegado a la conclusión de que es algo que pasa con el ext4 porque he probado incluso el firebird SS de 32 bits y aunque funciona ofrece el mismo rendimiento.
Respecto a lo que comenta el compañero anterior, la aplicación está mirada ya a 2.5, consultas revisadas y funciona perfectamente rápida en máquinas Windows con firebird 2.5. De hecho, funciona bastante más rápida simplemente con el cambio de servidor a 2.5.
Tengo más servidores con linux pero aún no los he actualizado por lo que trabajan con la 1.5 y la versión anterior de mi aplicación, con un buen rendimiento.
El rendimiento lo mido efectuando diferentes procesos de mi aplicación y con una batería de consultas que tengo preparada y midiendo los tiempos de respuesta.
Esta semana reinstalaré el servidor con la misma versión pero poniendo el sistema de fichero en ext3 a ver como va, y si no va reinstalaré la máquina con centos 6 pero de 32 bits.