Ver la Versión Completa : Firebird - Inserts lentísimos en Linux
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
01-10-2012, 18:20:56
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? :confused:
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?
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? :confused:
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.
Con backup transportable va igual de mal.
Casimiro Notevi
01-10-2012, 19:25:31
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: 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?...
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...
Casimiro Notevi
01-10-2012, 21:44:50
Yo siempre uso:
read_committed
rec_version
nowait
Yo siempre uso:
read_committed
rec_version
nowait
tengo estas mismas opciones... :(
Hola,
He estado mirando el rendimiento de mi aplicación mediante el dbMonitor de DevArt (la utilidad de monitoreo de funciones SQL y tal), y la cosa es bastante "simple":
- Los "SELECT * FROM tabla" tardan aproximadamente 0,00 segundos (son tablas pequeñitas, de máximo 1500 registros)
- Los "SELECT COUNT(*) FROM tabla" tardan aproximadamente 0,016 segundos
- Los "DELETE FROM ..." tardan aproximadamente 1,172 segundos (y estaba borrando UN registro)
- Los "INSERT INTO..." tardan aproximadamente 1,562 segundos (y estaba insertando UN registro)
- Después de los DELETE e INSERT, se ejecuta una cosa que se llama "CommitRetaining:" (que no sé que es y yo no lo llamo, debe ser cosa del componente) y tarda 1,152 seg en el caso del DELETE, y 1,547 seg en caso del INSERT
Que hago mal? Y que es esto del "CommitRetaining"? Que puedo hacer para mejorar el rendimiento? Pruebo de poner un Firebird (server) en una máquina con Windows XP y miro si el rendimiento es el mismo que en el servidor Linux?
Casimiro Notevi
02-10-2012, 12:03:13
El commit y el commitretaining sirven para confirmar el cambio hecho en la BD (insert, update, delete), si no haces commit entonces no se guardan los datos.
Creo que el problema va a ser de tu BD, que no tenga bien definido los índices, relaciones, etc. imposible de saber si no la podemos ver y no sabemos las sentencias exactas que haces.
Creación de la base de datos:
create database "ttpv.fdb" user "sysdba" password "masterkey"
default character set utf8
Creación de una de las tablas:
create generator gen_fam;
set generator gen_fam to 0;
create table familias (
id int not null primary key,
cod int,
nom varchar(50),
dto integer
);
create trigger familias_bi for familias
active before insert
position 0 as
begin
if (new.id is null or new.id=0) then
new.id=gen_id(gen_fam, 1);
end!!
Inserción de un registro en la tabla familias:
INSERT INTO familias (cod, nom, dto)
VALUES (:COD, :NOM, :DTO);
Borrado de un registro en la tabla familias:
DELETE FROM familias
WHERE id=:ID;
Como puedes ver, es más simple que el mecanismo de un botijo... No hay ningún índice (a excepción del ID que es una primary key), y no creo que sea culpa del trigger, no?
La verdad, es que ya no sé por dónde buscar... :(
Gracias por tu ayuda!
Casimiro Notevi
02-10-2012, 12:30:31
Las pruebas que has hecho antes, ¿cómo han sido?, ¿en local, en red, desde el programa, desde isql?
Las pruebas que hecho antes son:
- En red (wifi)
- Usando el programa, más el "espía" dbMonitor (simplemente guarda las secuencias SQL que se mandan al Firebird)
- Al servidor Linux
Casimiro Notevi
02-10-2012, 13:19:38
Esas pruebas no se pueden considerar concluyentes en ningún caso.
Usar wifi no es válido, (es algo muy "oscilante").
Si tienes un programa espía, tampoco es válido, (estás poniendo otra capa intermedia).
Debes hacer pruebas reales. Una red cableada normal, nada de espías. Abres isql, ibexpert, flamerobin, etc. y ejecutas una sentencia. Punto. Si va bien entonces es que va bien, no hay más. Si va mal mal entonces es cuando hay que buscar culpables.
Esas pruebas no se pueden considerar concluyentes en ningún caso.
Usar wifi no es válido, (es algo muy "oscilante").
Si tienes un programa espía, tampoco es válido, (estás poniendo otra capa intermedia).
Debes hacer pruebas reales. Una red cableada normal, nada de espías. Abres isql, ibexpert, flamerobin, etc. y ejecutas una sentencia. Punto. Si va bien entonces es que va bien, no hay más. Si va mal mal entonces es cuando hay que buscar culpables.
No estoy para nada de acuerdo con esto.
El sistema en producción va a funcionar con wifi, y usando el programa que va lento. Por lo tanto, lo normal es probarlo así.
El tema del programa espía tampoco es ningún problema. Si hace falta puedo usar un cronómetro, pero a simple vista ya se ve que va lento con o sin programa espía. Y, en el peor de los casos, el programa espía alentirá el sistema 1 décima de segundo (o menos).
Por otra parte, ya te he dicho antes que he probado directamente con el ISQL y no hay problemas de velocidad en las inserciones...
fjcg02
02-10-2012, 17:00:22
Tamaño de página ?
Tamaño de página ?
8192 bytes (trabajo con unicode)
Casimiro Notevi
02-10-2012, 18:30:23
No estoy para nada de acuerdo con esto.
El sistema en producción va a funcionar con wifi, y usando el programa que va lento. Por lo tanto, lo normal es probarlo así.
Bueno, no hace falta que estés de acuerdo, o no, conmigo.
mightydragonlor
03-10-2012, 02:32:15
Si ejecutas instrucciones SQL en FlameRobin, isql o el ibexpert y van bien, el problema está en tu aplicación, Red, DNS o n mil variables mas, exceptuando Firebird.
Saludos.
Primero: Yo pasaba a FB 2.5 (con backup transportable y tal), asegurando de borrar todo rastro de fbclient.dll, gds32.dll del sistema antes de actualizar.
Segundo: Yo diría que tires por quitar el CommitRetaining...
El commitRetaining es un commit que guarda el contexto de la transacción. Esto significa que después de muchos commitRetaining se podría enlentecer la aplicación, aunque es muy raro que ocurra con un solo insert.
La diferencia principal entre commit y CommitRetaining es que el primero cierra la tabla ( o dataset) que está usando para el insert, mientras que el commitRetaining no lo hace.
¿tú abres y cierras la transacción?, porque si no haces nada (y supongo es lo que pasa) está usando la transacción por defecto y estará usando el CommitRetaining.
Si ya tienes el dbMonitor (o lo que sea) mira el plan de las consultas, a ver si hay algo raro.
Otra cosa que puede afectar: Lee sobre el multicore / multiThread (suele configurarse en Firebird.conf de la carpeta de instalación (no sé en Linux donde anda).
¡Suerte y no dejes de comentar!
cointec
03-10-2012, 14:58:56
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.com/Performance-of-FW-databases-on-ext4-filesystem-td3775089.html
Casimiro Notevi
03-10-2012, 15:31:11
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.
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
03-10-2012, 17:50:28
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
03-10-2012, 17:50:45
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.
cointec
04-10-2012, 15:15:34
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.
Casimiro Notevi
04-10-2012, 20:07:09
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?
vBulletin v3.6.8, Derechos ©2000-2024, Jelsoft Enterprises Ltd.