FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Firebird en un entorno 24x7
Hola a todos,
Soy nuevo en este foro, así que espero no soltar burradas muy graves Más que un problema concreto lo que aquí voy a plantear es una duda de concepto. Voy a exponer las conclusiones a las que he ido llegando para luego plantear algunas preguntas. Lo primero indicar que utilizo Delphi5 y Firebird 1.0.3-972 en Windows 2000 y XP. Lo segundo es que no soy muy ducho en Delphi ya que lo mio es más unix y la programación de sistemas. Así que si el problema es de un mal uso de los componentes no teneis más que decirlo y la colleja me la pego yo solo [TOCHO MUY LARGO] Tengo un software de adquisición de datos que ha de estar funcionando lo más continuadamente posible. Básicamente, cada cierto tiempo se recibe información que actualiza registros ya existentes en una tabla. Es decir que, exceptuando los mecanismos internos de Firebird (versionado de registros, etc), el volumen de información total de la base de datos no cambia. La actualización de datos siempre se hace mediante componentes Delphi y los métodos Edit y Post. En otra base de datos diferente se van a añadiendo registros históricos con Append y Post, y cada cierto tiempo se borran. Según he leido, al borrar no se reaprovecha automáticamente el espacio hasta que se lleva a cabo una recolección de basura. El problema es que nuestro sistema debe funcionar lo más autónomamente posible. Con el tiempo se observa un crecimiento bastante significativo de los ficheros .GDB , aparejado con una bajada de rendimiento considerable (el problema de rendimiento se aprecia tanto en 2000 como XP, por lo que no creo que tenga que ver con la restauración del sistema de XP). En ocasiones hemos llegado a tener el sistema completamente parado. Siempre se soluciona con un backup/restore. A veces simplemente parando la BD, haciendo una copia del .GDB y rearrancando la aplicación se recupera buena parte del rendimiento original (puede ser algo relacionado con la fragmentación en sistema de ficheros del fichero original). Los ficheros .GDB tienen 20000 en el parámetro "sweep interval". Usamos dialecto 1. Leyendo un documento de uno de los moderadores de este foro decidimos empezar a utilizar "gfix -sweep" por las noches y parece que la BD contiene su tamaño. Aún así no estoy tranquilo del todo, ya que es un sistema en producción y esas cosas dan bastante yuyu. Bueno, todo ese rollo es para plantear la situación. Ahora vienen las cuestiones: [EOT] 1- Utilizando los componentes estándar de Delphi5, ¿con {Edit|Append}/Post es suficiente para finalizar una transacción o es necesario realizar las operaciones en el contexto de una transacción de forma explícita (StartTransaction + {Edit|Append}/Post +Commit)? ¿Si no hago commit se me quedan transacciones en el limbo? 2- ¿Usar gfix es la forma correcta de hacer las cosas para que la BD no crezca desmesuradamente? ¿Por qué no se hace el sweep solito sin que nadie se lo diga? 3- ¿Alguno ha observado la degeneración de rendimiento que comento más arriba? ¿Es un mal inevitable o con la recolección de basura se soluciona? En nuestro caso aparece aproximadamente después de 1-2 semanas después del último restore. A mis jefes les precupan mucho éstos dos problemas (sobre todo el del rendimiento), hasta el punto de considerar el cambio a otra BD (mysql probablemente) con mucho menos mantenimiento, aunque también menos características. Les he dicho que aplacen la decisión, porque problablemente es un tema de desconocimiento por nuestra parte en la configuración de Firebird. ¿Qué me decís? Bendito sea el que haya llegado leyendo hasta aquí Muchas gracias por vuestro tiempo. Nos vemos! |
#2
|
|||||||||||||
|
|||||||||||||
Hola y bienvenido,
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
De todas formas, este asunto es tema a discutir en el foro: "Conexión con bases de datos"; allí se tratan los asuntos referentes a los componentes de acceso (incluidos los propios de InterBase). Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Saludos. |
#3
|
||||||||
|
||||||||
Cita:
Cita:
Cita:
Cita:
Cita:
Cita:
Las conclusiones que hemos sacado de esto en el trabajo es que en nuestro caso es preferible dejar el "sweep interval" a 0 y ejecutar "gfix -online -sweep" todos los días en horas de baja carga (madrugada normalmente). De esta forma el sweep reduce en mucho el rendimiento de la BD, pero sigue online y sabemos a qué hora va a pasar. Llevo experimentando con una instalación desde hace 1 semana y los .GDB no han aumentado de tamaño Cita:
Seguiré visitando estos foros (que no conocía) porque hay mucha y buena información. Muchas gracias por la respuesta. Nos vemos! Cita:
|
#4
|
||||
|
||||
Hola.
Por lo que dices, yo revisaria las transacciones. En Interbase/Firebird se produce una caída importante del rendimiento cuando se acumulan muchas operaciones en una misma transacción. Como comenta Juan José, debes evitar los CommitRetaining y realizar Hard Commits, al menos al llegar sobre los mil registros no confirmados. NOTA : Yo tengo una aplicación 24x7 funcionando desde hace más de un año, y Firebird se comporta muy bien, como mínimo hace 6 meses que no me acerco por allí (controla el tráfico marítimo de un importante puerto del Mediterraneo). Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#5
|
|||
|
|||
Hola guillotmarc,
La lentitud que he observado no parece que esté directamente relacionada con transacciones grandes. En nuestro sistema no suelen verse involucradas más de 10 o 20 tuplas de una tabla por transacción. Más bien parece provenir de la gran cantidad de actualizaciones de registros que hacemos al cabo del dia (unas 200000). En algún sitio leí que eso podía afectar al balanceo de los índices. He observado que una reconstrucción diaria de los mismos agiliza sensiblemente las consultas, a cambio de perder un poco de rendimiento en los momentos puntuales donde se reconstruyen. Gracias por la respuesta Nos vemos. |
|
|
|