En firebird uso de CPU a mas del 100%
 

Saludos....

Tengo la siguiente inquietud.

En un servidor Linux, esta montado firebird 1.5 Superserver, tiene dos bases de datos montadas una mide mas o menos 7 Gb y la otra un poco mas de 1 Gb. Se manejan dos aplicaciones. Una de las aplicaciones maneja la base de datos mas grande y se realizan consultas, insert y actualiaciones, y en la otra aplicacion se realizan insert sobre la base de datos mas pequeña y usa la base de datos mas grande para realizar consultas. Se tienen mas o menos de 50 a 60 conexiones a la base mas pequeña, y unas 8 conexiones maximo a la base de datos mas grande.

verificando las opciones de uso de CPU y de Memoria del firebird, la memoria se mantiene entre un 50 y 60% de uso, pero las caracteristicas de CPU se comporta de una manera que no entiendo....la CPU sube esta entre 60 y 70% de uso y de un mometo a otro llega al 100% y a veces se pasa del 100%, luego vuelve a caer al 70, y se mantiene en ese rango, hasta que llega el momento que no baja de 100, y los acceso a la base de datos ya no se dan y todas las conexiones se vuelven lentas o se bloquean, y la unica forma es cancelar las conexiones y reiniciar el firebird.

Espero me entiendan y alguno de ustedes me pueda ayudar....

con un gstat -h podrás ver la diferencia entra la última transacción activa y la transacción actual.
Si esta diferencia es mucha (más de 10.000), seguramente no estás haciendo commit cuando corresponde y quedan las transacciones abiertas y molestando unas a otras.

También puedes comprobar cada cuanto está es SWEEP INTERVAL
(cada cuantas transacciones hace un sweep)
Creo que si lo pones a 0 se desactiva.

Lo único que tendrás que hacer a la noche es una taréa programada con un GFIX.

Si puedes utilizar para lecturas (reportes, por ejemplo) el tipo de transacción de solo lectura (read, read_commited) ayudarás mucho al motor de la base de datos, pues no impedirçan ninguna inserción, modificación o borrado.

Muchas gracias por tu colaboracion, voy a realizar la tarea que me dices, revisar las transacciones en el codigo,,,,,,

en verdad muchas gracias....

También ten en cuenta si tienes más de una cpu debes usar la versión ClassicServer, no uses la SuperServer.

Saludos....

corri el gstat a la base de datos mas grande y efectivamente hay unas 27 mil transacciones restando la ulta activa y la actual....

ahora para eliminar esas transacciones que estan afectando el rendimiento....se realizaria un backup - Restore? se tendria que modificar algun parametro antes de hacer restore ?


Muchas gracias...

Con el solo hecho de desconectar todas las sesiones, se darán por finalizadas las transacciones y la "última activa" será una menos que la "siguiente". (creo que este contador se reestablece con la siguiente conexión)

Otra forma de hacerlo es con "gfix --sweep".

Una pregunta: ¿el gstat lo has hecho cuando todo estaba funcionando lento?
27 mil transacciones no debería ser muy grave (a menos que la 1 esté evitando que acaben(commit) otros 26.999 inserts/deletes/updates).

También puedes probar, sugiriéndole a tu cliente que al mediodía, cuando todos se van a a comer, que cierren la aplicación.

Un backup-restore, no solo pondría las transacciones a 0, sinó que además limpiaría los registros marcados como borrados, balancearía los índices y alguna otra cosita (eso es le "garbage collection").

Yo en algunos clientes, tengo una taréa nocturna que lo hace automáticamente.

Saludos...

Esta es la estadistica en este momento y esta lento el acceso.

Database header page information:
Flags 0
Checksum 12345
Generation 76357
Page size 8192
ODS version 10.1
Oldest transaction 62296
Oldest active 62297
Oldest snapshot 59452
Next transaction 76351
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Jan 22, 2009 14:30:24
Attributes

Variable header data:
Sweep interval: 20000
*END*


Estoy verificando esta estadistica y esta aumentando el newtransaction y el old se mantiene.....
entonces seria verificar si el commit se esta dando en el codigo fuente?...o la transaccion usada esta read commited....lo otro es si existe una conexion a firebird por BDE, no sera que el bde esta causando ese problema?

Espero tu respuesta...gracias.

Yo empezaría buscando algún update o delete sin su Commit (o con un CommitRetaining).

Yo nunca he usado BDE para conectar a Firebird, pero suena muy lógico. Con BDE no puedes saber que transacciones están abiertas y cuales no. Tampoco puedes saber si está bloqueando un registro para poder utilizarlo en exclusiva.

saludos....

Estoy realizando una prueba, modificando una de las opciones que realiza inserts usando la conexion BDE y otra usando los ibx

el objeto transaccion la tengo configurada de esta forma

read_committed
rec_version
nowait

y estoy usando un TransJ.CommitRetaining al terminar el proceso....

verifco el gstat y las nuevas transacciones se incrementan las antiguas se mantienen...


Cuando dices que "Yo empezaría buscando algún update o delete sin su Commit (o con un CommitRetaining).
"

estas indicando que no se debe usar el CommitRetaining?

Gracias...

CommitRetaining es diferente a Commit.

CommitRetaining graba los datos, pero no libera la transacción. La sigue manteniendo abierta. Esto es útil en el caso de que estés entrando el detalle de una factura, por ejemplo. Después de cada línea haces un CommitRetaining y sigues insertando.

Si haces un Commit, la transacción graba los datos y finaliza. Para poder insertar otro dato tendrás que abrir otra. La contrapartida de esto, es que si haces un Commit después de cada línea de la factura, se cerrará el dataset y deberás volver a abirlo y posicionarte en el último registro.

Si solo deseas insertar, creo que deberías hacerlo más o menos así:

Código Delphi [-]
procedure TDMFactura.Insertar(Dato : string);
var
  Q : TFIBQuery;
begin
   {Creo el Query}
   Q := TFIBQuery.Create(nil);
   with Q do
   begin
      Close;
      DataBase := DMMain.DataBase ;
      {Creo la transacción del Query}
      Transaction := TFIBTransaction.Create(nil);
      Transaction.TRParams.Add('read_committed');
      Transaction.TRParams.Add('rec_version');
      Transaction.TRParams.Add('nowait');
      Transaction.DefaultDataBase := DMMain.DataBase;

      {Comieza transaccion}
      Transaction.StartTransaction;

      SQL.Text := 'insert into tabla (dato) values (?dato)';
      Params.ByName['DATO'].AsString := Dato;
      ExecQuery;

      {Finaliza transaccion}
      Transaction.Commit;
   end;

   {Libero el Query creado}
   FreeAndNil(Q);
end;

Si ya tienes los componentes en el datamodule sería algo así:
Suponiendo que lees de algún lugar y quieres transferirlo a la base.

Código Delphi [-]
//Supongo: Q.SQL.Text := 'insert into tabla (dato) values (?dato)';
procedure TDMFactura.Insertar;
begin
   while not Datos.EOF do
   begin
      with Q do
      begin
         Close;
         {Comieza transaccion}
         Transaction.StartTransaction;
         Params.ByName['DATO'].AsString := Dato.FieldByName['DATO'].AsString;
         ExecQuery;
         {Finaliza transaccion}
         Transaction.Commit;
      end;
      Datos.Next;
   end; {while not Datos.EOF}
end;

Como verás la transacción está abierta solo durante la asignación de parámetros y el ExecQuery.
Luego de eso se hace un Commit.

Además de mejorar las transacciones también debes ver como accedes a los datos, usas componentes TTable?, traes del servidor información que no se necesita en el momento??, la parte del commit o commitrataing es bien importante, siempre que se haga un insert, un update o un delete es necesario hacer un commit (o commitRetaing)... Si estas trabajando con tablas es bien importante usar maestro detalle y ademas usar filtros en la tabla maestra (esto como solución temporal), pero mejor aun usar componentes que se filtren mejor como son Query... tengo entendido que los componentes del BDE no son los más recomendables en esquemas cliente servidor ya que siempre traen todos los datos y es a nivel de componente donde se hace el proceso de los datos tales como clausulas where y similares

Una lectura interesante:
http://www.intitec.com/varios/transacciones-0.2.6.pdf
http://tech.groups.yahoo.com/group/f.../message/15926
http://www.firebirdsql.org/index.php...tivity#ibo_clx Porqué no usar BDE

saludos...

quiero agradecerles toda la ayuda que me han brindado.....


sobre el uso del BDE estoy ajustando todos los proceso que requieren de inser, delete o update a conexiones ibx, las consultas si las estoy dejando con la conexion BDE...bueno te cuento que ya implemente la parte de commit y entendi todo lo que me dices...corro el gstat en una base de prueba, y las nuevas transacciones siguen aumentando y la mas vieja se mantiene...al parecer el %de CPU si se mermo...no se si ya con esto podriamos finalizar este hilo o si tienes alguna recomendacion adicional...?

Gracias.