Problema grave de rendimiento
 

Hola Foreros,

Tengo un problema serio de rendimiento. Voy a intentar explicar la situación de la manera más breve posible, intentando no dejar detalle alguno sobre la configuración del servidor, así como de las conexiones al mismo.

Se trata de un servidor con 2 procesadores AMD a 2400Mhz, controladora SCSI con Raid por hardware con 4 discos duros de 36Gb, 2Gb de memoria, y una tarjeta de red de 1000, con Linux Red Hat 7.3. Sólo tiene instalado Interbase 6.5. y Samba 2.2.3a-6.

Desde hace unos días, el rendimiento del servidor ha bajado considerablemente. Todos los días, de madrugada, se hace un backup (con opción garbage activada) y un restore, con lo que la base de datos queda totalmente limpia para el día siguiente. Además de esto, el proceso sweep automático de interbase, ha sido desactivado. El tamaño de la base de datos es de unos 311Mb.

La reducción del rendimiento siempre se produce a partir de unas 4 horas desde que los usuarios se conectan a la base de datos, por lo que, el rendimiento decae poco a poco hasta que llega a ser casi imposible trabajar. Si reinicio el servidor, vuelve a funcionar todo bien. Durante el día, no se lanzan procesos de sistema ni de base de datos.

Desde la aplicación, se realizan ‘commits’ bastante asiduamente (desde que el rendimiento ha bajado, se han aumentado) para que no se acumulen muchas versiones de registros, y el número de transacciones máximas abiertas en ocasiones muy concretas es de 3 (lo normal son 2), por aplicación.

Aquí os paso algo de información cuando el sistema funciona lentamente:

Gstat –h basededatos.gdb

Database header page information:
Flags 0
Checksum 12345
Generation 6250
Page size 4096
ODS version 10.1
Oldest transaction 3168
Oldest active 3169
Oldest snapshot 3169
Next transaction 6238
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 1024
Next header page 0
Database dialect 1
Creation date Jun 16, 2004 5:35:49

Variable header data:
Sweep interval: 0
*END*

Puestos de trabajo hay 22 y, el número máximo de conexiones a la base de datos ha sido de 41. El número de licencias que tiene instaladas para interbase es de 63.

El tema físico (la red) queda descartado como posible motivo de error, ya que se han verificado todas las tarjetas de red y cableado, y se han cambiado los switches por otros nuevos (esto ha sido realizado por una empresa especializada). Todos los clientes que se conectan al servidor, son Windows 2000 profesional (se han eliminado los windows 98 y los Windows XP Home edition).

De momento, la única opción más inmediata, es la de actualizar la versión de Interbase, lo que haremos en un par de días.

¿Alguien puede sugerirme alguna opción mas sobre cómo configurar interbase?.

En caso de que interbase esté funcionando correctamente, ¿Para dicho número de clientes y número de conexiones, es suficiente con la potencia de este servidor?, o, ¿deberíamos plantearnos el cambiar el servidor por otro mucho mas potente?.

Siento el haberme extendido tanto, pero no quería dejarme ningún detalle, y, como podéis ver, el problema hace que mi situación es que me encuentro DESESPERADO, ya que dicho problema se viene produciendo desde hace bastante tiempo.

Vuelvo a pedir disculpas por haberme extendido tanto, y agradeceré fervorosamente cualquier tipo de ayuda, sugerencia o comentario.

Gracias a todos.

Hola,

Seguramente el problema esté con el doble procesador. Las versiones inferiores a la 7 tienen serios problemas de rendimiento en este tipo de máquinas. Creo recordar (no estoy seguro, ya que no uso InterBase, sino Firebird), que la versión 6.5 te permite asignar (mediante alguna opción en el archivo ibconfig) la ejecución del servidor a un único procesador.

De todas formas, la recomendación de Borland es subir a la versión 7.1 para estos casos...
http://community.borland.com/article...,30131,00.html

Samba no juega en este problema. Es más, no lo necesitas para conectarte desde los clientes Windows al servidor en Linux.

Saludos.

Muchas gracias Kinobi.

Voy a probar a asignarle únicamente una CPU a Interbase, aunque en pocos dias tengo pensado actualizar a la versión 7.1 de Interbase.

Iré escribiendo aquí las cosas que vaya encontrando, por si a alguien más le interesara.

Por cierto, samba lo utilizo para que los usuarios tengan un lugar donde guardar sus documentos personales, sin depender del ordenador que uticen.

Muchas gracias de nuevo.

Bien, sigue también los consejos que se dan en el documento de Borland al que hice referencia en mi mensaje anterior.

Ya, por eso te comentaba que Samba no es necesario para utilizar el servidor InterBase en tu servidor Linux.

Saludos.

Gracias de nuevo Kinobi.

En el documento al que haces referencia, indica de una manera rotunda, que en sistemas multiprocesador, se actualice a la version 7.1 de Interbase.

Gracias otra vez, sobre todo, por la rapidez con la que has respondido.

Hola, quizas me entrometa pero creo que si el problema fuera por el doble procesador ocurriria practicamente desde el momento de conectar y no al cabo de cierto tiempo.

Por cierto, antes de poner IB 7.1 por que no pruebas con Firebird 1.03 o 1.5. Es mas barato y no tienes limitacion de usuarios.

Hola,

En absoluto. Estos son unos foros de debate, lo que queremos es que la gente se entrometa ;) (en el mejor sentido)

Lo que he leído sobre casos similares parece confirmar que se produce al cabo de cierto tiempo, por un problema de reparto de cargas entre los procesadores, que acaban consumiendo excesivo tiempo en la gestión de ese reparto, produciéndose una especie de frontón entre los procesadores y el proceso servidor. Ahora bien, yo no he sufrido esa situación personalmente, son comentarios de terceros.

Yo también lo aconsejaría (sin despreciar InterBase). De hecho es la solución que yo utilizo: Firebird 1.5 sobre Linux, compilando los fuentes.

Saludos.

Yo tambien me entrometo, he leido en este foro en no se cual mensaje anterior que la version 1.5 de firebird no funciona bien con un procesador dual. Que conocen uds, ya que tengo que instalar un nuevo server y quisiera saber si vale la pena la compra de un dual o con un simple bastaria.

PD: Avisenme si es necesario abrir otro hilo, y disculpen

Hay un hecho nada mas que me preocupa, y es que a pesar de mencionar que el servidor tiene 2 Gb. de RAM, no has especificado cuanta de esa memoria le has asignado a Interbase. Teniendo un servidor potente como el que tenes, y con tanta memoria RAM para una base de datos tan pequeña, lo corriente sería que todo permaneciera en cache.

La verdad tengo poca referencia de si esto mejora el rendimiento de interbase, pero es lo corriente con Oracle.

Lo menciono, porque quizas aunque tengas 2 Gb. de RAM en el server, si interbase solamente tomara unos cuantos megas... viendose obligado a leer y releer del disco, estas desperdiciando un buen recurso del servidor, y podrias tener un buen cambio en el desempeño al aprovecharlo.

Hasta luego.

;)

El número de páginas destinadas a interbase es de 10000, y el tamaño de página es de 4096 bytes, lo que da unos 40Mb.

Según hemos leido, el número de páginas que deben de estar mantenidas en RAM debe de estar entre 256 y 10000, por cada base de datos. Si el valor es superior a 10000, se pueden tener problemas, reduciendose el rendimiento.

Nosotros, hemos probado a poner 1024 y 10000, y no hemos notado nada, ni en esta base de datos (que sigue dando los mismos problemas de rendimiento) ni en otras que, de momento no tenemos problema alguno.

En cuanto a lo que hace referencia kinobi, sobre el reparto de cargas entre los procesadores, puede que sea eso lo que ocurre. Pegandole un vistazo al sistema, los procesos ibserver del sistema, se van haciendo mas grandes conforme va pasando el tiempo de utilización del servidor. Cuando reiniciamos el servicio, vuelven a tener un tamaño mas pequeño, y el funcionamiento vuelve a ser normal.

Ahora mismo, nuestra linea de actuación, pasa por esperar un nuevo servidor monoprocesador, para hacer pruebas con interbase 7.1.

Os mantendré al corriente de todo.

Un cordial saludo, y mi mas sincero agradecimiento por vuestra colaboración.

¡¡Hola foreros!!

Después de varios días de pruebas y cambios, la situación a mejorado.

El problema radicaba en las transacciones abiertas demasiado tiempo y en un commitretaining que no habíamos visto.

En una parte del programa se abría una transacción que no se cerraba hasta que el usuario no salia de la aplicación(podía estar unas 5 horas sin cerrarse), y además de eso dicha transacción realizaba una gran cantidad de inserciones y borrados en la base de datos, realizando un COMMITRETAINING, lo cual hacía que el número de versiones de datos en dicha transacción fuera tremendamente grande. En pocas palabras, se juntó todo lo malo en un mismo sitio.

La verdad, es que nos ha costado, ya que no pensábamos que teníamos ese commitretaining en ese lugar.

Hemos repasado toda la aplicación buscando mas commitretaining (ya no queda ninguno), y las transacciones se cierran automaticamente pasado cierto tiempo de inactividad por parte del usuario.

Ahora los usuarios trabajan con normalidad, pero aún así queremos hacer mas pruebas, como por ejemplo utilizar un servidor monoprocesador y actualizar a la version 7.1 en el biprocesador.

Estas pruebas las realizaremos en breve, así que seguiré informando sobre las mismas por si a alguien le pudiera servir de ayuda.

Saludos a todos. :D

Hola.

Creo recordar que las caidas de rendimiento debido a correr sobre un sistema multiprocesador solo ocurren en Windows, y no en Linux.

Aunque ciertamente es muy probable que Interbase 7 tenga mejor rendimiento que un Interbase 6/6.5 o Firebird, debido a su mayor granularidad.

Saludos.

Yo tube el problema del doble procesador con interbase 6 y tube que migrar al 7.1.


Desde entonces, todo fue bien...

Resp
 

Una de las maneras mas faciles de arreglar cualquier problema de progracion mas si es de logica es siempre decir que la culpa es nuestra. Cuando estemos completemente seguros que la culpa no es nuestra entonces vemos cuales son lo sfactores internso que no puedes afectar. Loq ue quiero decir con esto es que siempre tenemos por revisr nuestro codigo, se es posible hacer pruevas independientes o probar fracmentos de codigo que nos puedes molestar o probar con pequeñas aplicaciones o intentar acceder la data de otra forma y si persiste el problema entonces nos vamos a probar los programas en este caso interbase o delphi.

Nota. Recuerden que no existe aplicacion perfecta