Firebird - Inserts lentísimos en Linux

[mcs]

Hola,

Tenía un sistema de TPV usando Firebird Embedded. El sistema iba perfectamente, pero por motivos de seguridad y centralización de datos he decidido poner toda la base de datos en un servidor Ubuntu Server LTS de 64bits (el último, no sé el número de versión).

El caso es que ahora la inserción, modificación y borrado de datos es LENTÍSIMO. O sea, una operación que antes era instantánea, ahora tarda 1 o 2 segundos en realizarse (estamos hablando de insertar TRES registros en dos tablas distintas, de unos 5 o 10 campos, y con sólo un índice primario en cada tabla).

Por otra parte, los selects, ya sean simples, de múltiples tablas o los que sea, son instantáneos. Cómo si se estuviera ejecutando en local.

La verdad es que es la primera vez que instalo un Firebird sobre Linux, y no sé que puedo hacer para mejorar el rendimiento de este... Hace tiempo ya prové el Firebird corriendo en un servidor Windows 2003 (mismo hardware que el que usa Linux), y funcionaba sin problemas y a un rendimiento normal...

Los componentes de acceso a datos son los IBDAC, y uso Delphi 2010. El Firebird es un 2.1, y la DLL de conexión (Client Library) tambien es una 2.1.

Ah, para insertar, modificar, etc, no uso los típicos IBTable.Open, IBTable.Update, IBTable.Post, etc, sinó que uso sentencias SQL. Lo único, es que siempre uso parámetros (("INSERT INTO t1 (x, y, z) VALUES (:X, :Y, :Z)").

Alguien me puede ayudar a mejorar este problema?

[Casimiro Notevi]

Creo que no das ninguna información para que podamos ayudarte.
Sí, vale, que has montado un servidor linux y usas ibdac, pero ¿qué hacemos con esa información?

No sé, para empezar e ir preguntando algo: ¿Qué versión exacta de firebird has montado en todos los equipos?, ¿has hecho un backup transportable y has restaurado antes de instalar la nueva versión?

[mcs]

Empezado por Casimiro Notevi

Creo que no das ninguna información para que podamos ayudarte.
Sí, vale, que has montado un servidor linux y usas ibdac, pero ¿qué hacemos con esa información?

Pues la verdad, no sé qué más quieres que te diga... Lo único que no te he dicho es la versión del Ubuntu, que es un 12.04 LTS.

No sé, para empezar e ir preguntando algo: ¿Qué versión exacta de firebird has montado en todos los equipos?, ¿has hecho un backup transportable y has restaurado antes de instalar la nueva versión?

En EL equipo cliente (ahora mismo sólo hay una máquina que usa esta base de datos, la librería de conexión es exactamente la 2.1.3.18185, de 22 de julio de 2009.

Y no, lo único que he hecho es copiar el FDB de una máquina a la otra y he corregido los permisos de este. Probaré lo del backup transportable.

[mcs]

Con backup transportable va igual de mal.

[Casimiro Notevi]

Veamos, es un poco dar palos de ciego, pero vamos a hacer una prueba.
Abre el ibexpert, flamerobin o el que uses.
Crea una conexión a la base de datos del servidor.
Ejecuta un insert cualquiera de los que te resultan lentos:

Código SQL [-]
insert into tbTabla values (111,'hola',12)

Le das a commit y calcula cuánto ha tardado.
¿Ha tardado mucho, poco, no has notado diferencia?...

[mcs]

he usado el ISQL (dime prehistórico :P), y el insert ha sido instantáneo... cosa que me alegra mucho!

voy a ver la configuración del IBDAC a ver si es todo correcto y tal...

Podría ser cosa de las transacciones? En el componente TIBDatabase hay un apartado que se llama DefaultTransaction. Dentro de este apartado, las opciones son:
- Active (boolean), ahora está a false
- DefaultCloseAction, ahora está en taRollback, y puede ser taCommit, taCommitRetaining, taRollback y taRollbackRetaining
- IsolationLevel, ahora está en iblReadCommited, y puede ser iblCustom, iblReadCommited, iblReadOnlyReadCommited, iblReadOnlyTableStability, iblSnapshot, iblTableStability
- Params (Strings), no veo que se pueda cambiar
- Tag

Y lo que no entiendo es que hace tiempo, usando los mismos componentes, pasé una aplicación de FB embedded a FB "normal", y no tuve ningún problema de rendimiento...

[cointec]

Hola, he visto en bastantes foros los problemas de rendimiento con Firebird en Linux con ext4, ya que tiene activo por defecto el parámetro barriers.

Creo que se recomienda para firebird, ext3 y barriers desactivo. No utilizo Linux, por lo que no tengo experiencia con el, pero puedes buscar en Google y hay bastante documentación al respecto. Te pongo un ejemplo de un hilo donde se habla del tema.

http://firebird.1100200.n4.nabble.co...td3775089.html

[Casimiro Notevi]

En general, ext3 es más rápido que ext4, ciertamente, aunque lo que comentan ese enlace que has puesto es sobre la creación de una base de datos, principalmente, no en el trabajo con ella (insert, update, delete, etc.)
Puestos a cambiar, reiserfs es más rápido que ext3, pero ext4 es más seguro que ext3 y ext3 es más seguro que reiserfs.
De todas formas, bastantes empresas/clientes de mi extrabajo usan ext4 y no tienen ningún problema.

Aquí hay que empezar por lo comentado antes y por el mensaje de mightydragonlor: "Si ejecutas instrucciones SQL en FlameRobin, isql o el ibexpert y van bien, el problema está en tu aplicación, Red, DNS o en mil variables mas, exceptuando Firebird."

Es que no se puede pretender obtener el máximo de rendimiento conectando por wifi.

[mcs]

Empezado por Casimiro Notevi

Es que no se puede pretender obtener el máximo de rendimiento conectando por wifi.

vamos a ver, si puedo hacer un select * de una tabla de 1500 registros en menos de medio segundo, y para insertar un j**** registro de menos de 30 bytes tarda más de 2 segundos, SEGURÍSIMO que el problema no es el wifi.

[[mightydragonlor]]

Empezado por mcs

vamos a ver, si puedo hacer un select * de una tabla de 1500 registros en menos de medio segundo, y para insertar un j**** registro de menos de 30 bytes tarda más de 2 segundos, SEGURÍSIMO que el problema no es el wifi.

Por mi experiencia puedo asgurar que una conexión por wifi no se puede establecer como medida de comparación, ya que esta depende de muchas mas variables que el cable, por otro lado, ya tuve una experiencia con esto, una aplicativo web, que estaba presentando "problemas" de lentidud en consultas y actualizaciones, pero que al acceder directamente el administrador de base de datos, todo funcionaba perfecto, así que el problema, nunca fue ´la base de datos, luego tuvimos que revisar la aplicación, siempre lo hicimos por cable, y funcionata todo perfecto, al final se descubrión que el wifi estaba generando el problema.
Las variables son muchas, pero si te centras en tu parecer, no vas a llegar a nada, por que esto no se trata del parecer de nadie, sino en hacer pruebas precisas para determinar el problema.

Saludos.

[Casimiro Notevi]

Veamos, esto es muy fácil de comprobar.
Te vas al servidor.
Una vez allí, abres el isql.
Conectas a la BD.
Ejecutas un insert.
Si es inmediato ya sabes que el problema no está en el servidor.

[Casimiro Notevi]

Empezado por Casimiro Notevi

Veamos, esto es muy fácil de comprobar.
Te vas al servidor.
Una vez allí, abres el isql.
Conectas a la BD.
Ejecutas un insert.
Si es inmediato ya sabes que el problema no está en el servidor.

¿Has hecho la prueba?

[cointec]

Empezado por mcs

vamos a ver, si puedo hacer un select * de una tabla de 1500 registros en menos de medio segundo, y para insertar un j**** registro de menos de 30 bytes tarda más de 2 segundos, SEGURÍSIMO que el problema no es el wifi.

Estoy de acuerdo contigo es obvio. Has probado el cambio del sistema de archivos?. Otra prueba simple es instalar Firebird en un PC Windows y probar desde otro equipo las mismas acciones.