Gibt es eine Art MS-Profiler für Firebird ?

[hoika]

Hallo,

kann viele Ursachen haben.

Du solltest dich mal zuerst etwas per www.ibphoenix.com
über die Multi-Generationen-Archtitektur (MGA) bei Firebird belesen.

Ein Select macht nicht nur das Select,
sondern bereitet auch die Garbage-Collection etwas vor.

Kurz:
Es gibt immer mehrere Versionen eines Wertes in einer FB-DB.
Wird ein Wert geändert, wird der alte Wert nicht sofort gelöscht,
sondern bleibt erhalten. Es wird aber eine neue Version des Wertes angelegt.

Grund:
Es könnte gerade eine andere Transaktionen genau diesen Wert benutzen,
z.B. zweimal auslesen, dann darf dein Update ja nicht einfach dafür sorgen,
dass beim 2. Mal ein anderer Wert gelesen wird (dirty read).

Ein Select sucht immer den jeweils passenden Wert,
und markiert in diesem Zusammenhang auch veraltete Versionen.

Jetzt läuft alle X (nicht Minuten) ein Thread (sweep) über die DB und
sucht diese als "veraltet" markierten Versionen und löscht sie.

Vielleicht ist das ja euer Problem.

Bei IBExpert kann man den Sweep-Intervall auf 0 setzen,
muss, vielleicht hilft das ja ?

Dann muss der Sweep aber von Hand gemacht werden,
z.B. einmal (z.B. nachts)

Dazu ein Bat Oder Cmd-Datei anlegen mit

c:\programme\firebird\firebird_1_5\gfix -sweep c:\data.fdb -user sysdba -pass masterkey

und über geplante Vorgänge laufen lassen.
Pfad von gfix und der DB natürlich noch ändern, und User oder Passwort auch.


Wie sieht es denn jetzt mit dem RAM-Verbrauch aus ?
Wächst der ständig ?
Das wäre dann eine offene Transaktion,
die im FB immer mehr RAM verbrät.



Heiko

[bluesbear]

Dazu möchte ich noch anmerken:
Ich habe The Firebird Book gelesen (sehr hilfreich), das entsprechende Kapitel aber nur überflogen (i will cross that bridge when i come to it), und da gibt es wohl einige Sachen, die der garbage collection entgehen. Es kann also sein, daß so eine Datenbank mit der Zeit degeneriert. Als Abhilfe stand da, ginge nur ein komplettes backup und restore. Vielleicht ist die Datenbank einfach zugemüllt? Nur sone Idee. Ich bin Firebird-Neuling - bitte nicht hauen, wenn das Blödsinn war.

[hoika]

Hallo,

nö ;)
die Idee ist auch ganz gut.
Ein Versuch macht Kluch.


Heiko

[mkinzler]

Aus diesem Grund wurde auch in FB das GC überarbeitetr. Es gibt jetzt 2 "Müllsammler" einer der im Hintergrund aufräumt und die Arbeitsthreads, die gefundenen Müll mitnehmen.

[Sascha-L]

Morgen Jungs,

erstmal danke für die ganzen Posts. Zum Ram: Nein, dieser wächst nicht an, sondern hält sich generell so bei 38 - 42 MB die belegt sind. Ein Backup-Restore ist mit sicherheit eine wichtige Sache, jedoch haben wir extra ein Programm hierfür, es besteht aus 2 Teilen, der 1. Führt quasie nur die Batchfikle aus, um die Datenbanken per gbak einem Backup-Restore zu unterziehen, und einem 2. Menüpunkt, der die Daten nochmal aus den Tabellen seperat ausließt und sie in eine Defaultdatenbank schriebt.
Wir haben gerade entdeckt, dass der Firebird manchmal in eine Tabelle die gleichen werte 2 mal einfügt, obwohl beim 2.Mal schon etwas anderes drinn stehn müsste (ein von uns manuell generierter fortlaufender Index beispielsweise). Jetzt vermuten wir Deadlocksituationen, hierzu wäre es vlt Hilfreich wenn Ihr ein Tool kennen würdet, dass mir die Deadlocks analysiert also welche Abfrage, wie lange usw. Gibt es generell eine Zeit, nachdem der Firebird eingreift um zu sagen, dass eine Deadlocksituation entstanden ist und diese aufhebt oder so änlich? Wenn ja, kann man diese Zeit irgendwo verändern?

Ich habe hier noch ein kleinen Auszug vom neusten Firebirdlog, jedoch ist da seit letzte Woche Freitag nichtsmehr reingeschrieben worden, obwohl wir die Fehler auch schon gestern und heute wieder hatten. Aber schaut ihn doch am besten selbst an, ich habe ein paar interessante Stellen rauskopiert.:




ALFHA-82A65C398 (Server) Thu Feb 21 09:36:31 2008
INET/inet_error: accept errno = 10093

ALFHA-82A65C398 (Server) Thu Feb 21 09:36:31 2008
INET/select_wait: select failed, errno = 0

ALFHA-82A65C398 (Server) Thu Feb 21 09:36:31 2008
SRVR_multi_thread/RECEIVE: error on main_port, shutting down
...


ALFHA-82A65C398 (Client) Fri Feb 22 17:11:50 2008
INET/inet_error: connect errno = 10061
...

ALFHA-82A65C398 (Client) Fri Feb 22 17:12:08 2008
INET/inet_error: read errno = 10053
...

ALFHA-82A65C398 (Client) Fri Feb 22 17:13:18 2008
REMOTE INTERFACE/gds__detach: Unsuccesful detach from database.
Uncommitted work may have been lost

ALFHA-82A65C398 (Client) Fri Feb 22 17:13:18 2008
INET/inet_error: send errno = 10053

Naja, dass wars fürs 1. denke wir werden uns später nochmal schrieben, danke und bis dann


MfG

Sascha Lütkemeier

[Sascha-L]

Es gibt meinerseits einige neue erkenntnisse.
Ich habe erfahren, dass der Bediener schlicht und ergreifend überhauptnichts mit PC´s am Hut hat, und es gut sein kann, dass unser Datenbankwartungsprogramm nur als Platzhalter auf der Festplatte diente :wall: . Naja wie dem auch sei, kommen wir zu den eigendtlichen Sachen. Wir haben eine tabelle, mit ca. 50000 Datensätzen gehabt, diese wird sekündlich mit neuen Daten beschossen, an dieser Stelle wurde dass ganze System ziemlich langsam, nun haben wir einfach mal die Tabelle aufgeräumt (komplett geleert) und das Prozedere wiedereinmal durchgeführt. Es mag vlt noch nicht Perfekt sein, aber jedoch sichtlich besser, nun wollte ich fragen woran dass liegen könnte, da wir in unseren MS-SQL Datenbanken teilweise Tabellen mit mehreren 100-tausenden von Datnsätzen haben, und hier alles normal läuft :gruebel: . Naja also ich hoffe Ihr könnt mir noch auf meine alten offenen Fragen antworten, ich werde mich nach dem Wochenende mal wieder hier melden.

Wünsche euch nen schönes erholsames WE

MfG

Sascha