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

[Sascha-L]

Guten Tag Leute,
Ich habe folgendes Problem:

Ich habe mehrere Clients, die auf mehrere Firebird(1.5)-Datenbanken zugreifen, und sher viel Datenverkehr haben, anscheinend zu viel für den Firebirdserver, dieser hängt sich nämlich manchmal auf, oder verarbeitet die Daten einfach zu langsam, jetzt möchte ich ausprobieren, inwiefern ich meine SQL-Befehle bzw. Stored Procedures verbessern kann, oder erstmal an welchen es liegt, dass der Datenverkehr ohne jegliche Gründe aufeinmal zu langsam ist.

Jetzt wollte ich fragen, ob euch ein Tool bekannt ist, dass die geschickten SQL-Befehle Mitloggt, mir die Bearbeitungszeit sowie den client, der den Befehl gegeben hat anzeigt. Im Prinziep suche ich so etwas wie den SQL Profiler von Microsoft, halt nur für meinen Firebird Server. Ich habe in den letzten Tagen schon viel mit dem IBExpert SQL-Monitor rumprobiert, dieser liefert mir jedoch manchmal die Bearbeitungszeiten der SQL-Befehle und manchmal nicht :gruebel: , außerdem zeigt er mir nicht an, von welchem Client die Befehle gesendet wurden. Ich Hoffe Ihr könnt mir Helfen.

Ich bedanke mich schonmal im Vorraus und wünsche euch noch einen schönen Abend.

MfG Sascha

[manfred_h]

Hallo Sascha

schau Dir doch den BT SQLMonitor bei http://devrace.com/en/fibplus/download/#43 an.

Habe ich auch im Einsatz.

Shalom
Manfred

[Sascha-L]

Danke für die schnelle Antwort, jedoch verwenden wir nicht die benötigten Komponenten, ergo schneidet der Monitor leider nicht mit, ärgerliche Sache, ich hoffe Ihr habt noch andere Vorschläge, ich stehe echt aufm Schlauch :|

[mkinzler]

Ich würde hier eher den Flaschenhals BDE mal in Augenschein nehmen

[hoika]

Hallo,

willkommen im Leidensklub .. ;)

ich hatte den SQL-Monitor mal in Aktion (Präsentation HK Software) gesehen,
der hatte die Clients mit angezeigt,
oder meinst du jetzt, 2 Programme auf dem gleichen Rechner ?
OK, da würde ich mal mit Herrn Klemt mal reden.

Um eine einzelne Query zu testen,
benutze ich den ibplanalyzer (Download via google).
Das Problem bei dem Tool ist, es ist ausschliesslich
für IB geschrieben, es funktioniert mit FB2 nicht mehr.

Bei Verwendung der BDE würde ich den SQLMonitor von Borland
selbst mal nehmen und die einzelnen Programme unter die Lupe nehmen.
Das geht aber bei ihm nur immer für ein Programm (?)

Stelle dort mal nur die Transaktionen ein.
Falls beim normalen Arbeiten ein Haufen Transaktionen erzeugt werden,
benutzt du keine expliziten Transaktionen (DataBase.StartTransaction).
Das ist schlecht, weil dann die BDE für jeden SQL-"Pups" eine Transaktion erzeugt,
und den Firebird-Server damit gelinde gesagt überschwemmt.

Ausserdem die üblichen Verdächtigen:
- DB Cache auf 10000 (4kB Seite) hochsetzen (nur Superserver)
- die gds32.dll von FB1.5 nehmen, nicht die ursprüngliche Ivon B
(auf den Clients suchen -> Versionsinfo kontrollieren)
- RAM-Verbrauch des FB kontrollieren
benutzt er immer mehr RAM, ist eine Transaktion lange offen
- TTable für grosse Tabellen -> Query benutzen
- Select *, obwohl nicht alle Felder benötigt werden
- In einer Schleife immer die gleiche Query abarbeiten
nur mit anderen Parametern
-> Query for Beginn der preparen, und intern nur den Parameter ändern
oder besser eine einzige Query benutzen, die die benötigten Daten auf einmal holt
- fehlender Index (für order by desc muss ein desc index existieren)
- SP verwenden


Heiko

[Sascha-L]

Nun ja, ich benutze explizit Database.StartTrasaction und habe auch schon mit Herrn Klemt gesprochen, zur Zeit bin ich nur in besitz der kleinen customer Version des IB-SQL-Explorers, der nur Lokal funktioniert, ergo sind alle Clinets, die mit den Datenbanken arbeiten auf einem Rechner.
Verstehe ich dich also nun richtig, dass es kein Besseres Tool für meine Zwecke gibt? Ich suche nämlich schon hmhmhm sagen wir einfach mal, "etwas länger" nach einem Tool, dass mir weiterhilft... :wall:

Danke,

MfG Sascha

[hoika]

Hallo,

korrekt, AFAIK.

Du könntest für Tests allerdings die Monitoring Tabellen
der aktuellen 2er Version benutzen.
AFAIK gibt es aber bisher kein Tool das die grafisch oder was auch immer
anständig darstellen kann.

ACHTUNG FALLE!
Wird die DB über Backup(1.5) -> Restore(2.0) erzeugt,
kann sie nicht mehr in FB1.5 verwendet werden.
Auch ein Backup(2.0) -> Restore(1.5) klappt nicht.


Heiko

[Sascha-L]

Ach ja, da gibt es noch eine Sache, du hast von dem SQL-Monitor geredet, der bei Delphi dabei ist, mit diesem habe ich mich auch schon versucht, jedoch zeigt er mir nichts an... Zumindest nicht mit meinen Clients, wenn ich über den SQL-Explorer von Borland eine Verbindung zu einer Datenbank aufbaue wird er sofort aktiv, woran könnte dass liegen?

Und was zur Hölle ist AFAIK :wiejetzt:

Die grafische darstellung ist mir eigendlich relativ egal, zur not würde ich mir da selber etwas schreiben, ich brauche nur erstmal etwas, was mir die Daten überhaupt gibt, die ich analysieren möchte, also wie lange brauchen SQl Befehle, sind Transaktionen nicht geschlossen usw. usw. wenn ich dass is nem Logfile hab, bastel ich mir schon was, was mir die Daten vernümftig anzeigt. ;-)

[DeddyH]

AFAIK = As far as I know (Link)

P.S.: Gruß ins Sauerland

[hoika]

Hallo,

AFAIK ... As Far As I Know ;)

In der DPR muss ein Application.Initialize vor dem Erzeugen des Hauptforms,
also am besten als erste Zeile.

Ansonsten klappt das mit dem BDE-SQL-Monitor nicht.
Ausserdem muss der Monitor vor dem Programm gestartet sein.

Das schöne am BDE-Monitor ist,
dass mein seine Queries direkt beim Debuggen ansehen kann (ZEOS kann das z.B. nicht).
Noch eine kleine Sache.
Beendest du den Programm über Ctrl+F2 im Debugger, muss der SQL-Monitor neu gestartet werden,
und erst danach weder dein Programm.



Heiko

[Sascha-L]

Hallo Hoika,

was genau meinst du mit der GDS32.dll ?
ich meine ich kenne diese DLL doch verwende Sie nur im zusammenhang mit dem IB-Expert, wo ich Sie angebe um auf die Datenbanken zugreifen zu können, falls meine Clients diese auch benutzen, wäre es Hilfreich wenn du noch einmal genau schildern könntest welche wege ich gehen muss um zu überprüfen, welche Version ich nun genau benutze.

Ich habe hier mal einen Logfile von einem Client vom Borland SQL-Monitor, der nur Transaktionen mitloggen soll, es wäre nett wenn Ihr den mal kurz überfliegen könntet und mir sagen würdet, ob es irgendwelche auffälligkeiten gibt., die euch sofort ins Auge stechen, außerdem ist mir nicht ganz klar, was mit "XACT" und mit "Vendor" gemeint ist...

Hier der Log:

1 11:11:54 SQL Transact: INTRBASE - XACT ReadCommitted
2 11:11:54 SQL Transact: INTRBASE - XACT Begin
3 11:11:54 SQL Vendor: INTRBASE - isc_start_transaction
4 11:11:54 SQL Stmt: INTRBASE - Close
5 11:11:54 SQL Vendor: INTRBASE - isc_dsql_free_statement
6 11:11:54 SQL Prepare: INTRBASE - Select * From READAllAuftragsDatenForViewer
("11_09",1)

7 11:11:54 SQL Vendor: INTRBASE - isc_dsql_allocate_statement
8 11:11:54 SQL Vendor: INTRBASE - isc_dsql_prepare
9 11:11:54 SQL Vendor: INTRBASE - isc_dsql_prepare
10 11:11:54 SQL Vendor: INTRBASE - isc_dsql_sql_info
11 11:11:54 SQL Vendor: INTRBASE - isc_vax_integer
12 11:11:54 SQL Execute: INTRBASE - Select * From READAllAuftragsDatenForViewer
("11_09",1)

13 11:11:54 SQL Vendor: INTRBASE - isc_dsql_execute
14 11:11:54 SQL Stmt: INTRBASE - Fetch
15 11:11:54 SQL Vendor: INTRBASE - isc_dsql_fetch

--// Hier standen nur die zurückgegebenen Ergebnisse

318 11:11:54 SQL Stmt: INTRBASE - Fetch
319 11:11:54 SQL Vendor: INTRBASE - isc_dsql_fetch
320 11:11:54 SQL Stmt: INTRBASE - EOF
321 11:11:54 SQL Stmt: INTRBASE - Reset
322 11:11:54 SQL Vendor: INTRBASE - isc_dsql_free_statement
323 11:11:54 SQL Transact: INTRBASE - XACT Commit
324 11:11:54 SQL Vendor: INTRBASE - isc_commit_transaction
325 11:11:54 SQL Transact: INTRBASE - XACT ReadCommitted
326 11:11:54 SQL Transact: INTRBASE - XACT ReadCommitted
327 11:11:54 SQL Transact: INTRBASE - XACT Begin
328 11:11:54 SQL Vendor: INTRBASE - isc_start_transaction
329 11:11:54 SQL Stmt: INTRBASE - Close
330 11:11:54 SQL Vendor: INTRBASE - isc_dsql_free_statement
331 11:11:54 SQL Prepare: INTRBASE - Select * From ReadSWPoolStrForWartung
(25911)

332 11:11:54 SQL Vendor: INTRBASE - isc_dsql_allocate_statement
333 11:11:54 SQL Vendor: INTRBASE - isc_dsql_prepare
334 11:11:54 SQL Vendor: INTRBASE - isc_dsql_sql_info
335 11:11:54 SQL Vendor: INTRBASE - isc_vax_integer
336 11:11:54 SQL Execute: INTRBASE - Select * From ReadSWPoolStrForWartung
(25911)

337 11:11:54 SQL Vendor: INTRBASE - isc_dsql_execute
338 11:11:54 SQL Stmt: INTRBASE - Fetch
339 11:11:54 SQL Vendor: INTRBASE - isc_dsql_fetch
340 11:11:54 SQL Data Out: INTRBASE - Column = 1, Name = R_POOLSTR, Type = fldZSTRING, Precision = 60, Scale = 0, Data = 17x98x2500x100x,z10,z30
341 11:11:54 SQL Data Out: INTRBASE - Column = 2, Name = R_STATUS, Type = fldINT16, Precision = 1, Scale = 0, Data = 0
342 11:11:54 SQL Stmt: INTRBASE - Fetch
343 11:11:54 SQL Vendor: INTRBASE - isc_dsql_fetch
344 11:11:54 SQL Data Out: INTRBASE - Column = 1, Name = R_POOLSTR, Type = fldZSTRING, Precision = 60, Scale = 0, Data = 17x120x2500x100x,z10,z30
345 11:11:54 SQL Data Out: INTRBASE - Column = 2, Name = R_STATUS, Type = fldINT16, Precision = 1, Scale = 0, Data = 0
346 11:11:54 SQL Stmt: INTRBASE - Fetch
347 11:11:54 SQL Vendor: INTRBASE - isc_dsql_fetch
348 11:11:54 SQL Data Out: INTRBASE - Column = 1, Name = R_POOLSTR, Type = fldZSTRING, Precision = 60, Scale = 0, Data = 17x78x2500x100x,z10,z30
349 11:11:54 SQL Data Out: INTRBASE - Column = 2, Name = R_STATUS, Type = fldINT16, Precision = 1, Scale = 0, Data = 0
350 11:11:54 SQL Stmt: INTRBASE - Fetch
351 11:11:54 SQL Vendor: INTRBASE - isc_dsql_fetch
352 11:11:54 SQL Stmt: INTRBASE - EOF
353 11:11:54 SQL Stmt: INTRBASE - Reset
354 11:11:54 SQL Vendor: INTRBASE - isc_dsql_free_statement
355 11:11:54 SQL Transact: INTRBASE - XACT Commit
356 11:11:54 SQL Vendor: INTRBASE - isc_commit_transaction
357 11:11:54 SQL Transact: INTRBASE - XACT ReadCommitted

Ende des Logs

Schonmal Danke an alle...

[mkinzler]

Welche Version hat die Dll?
BTW. es handelt sich hier um die Zugriffs-Dll von IB (oder FB im Kompatibilitätsmodus)

[Sascha-L]

Ich finde diese DLL öfter auf meinem Rechner, also welche soll ich nehmen ?
Hier mal eine Kurze Aufzählung mit Pfad und VersionsNr.:

Im System32 Ordner -> Version 6.3.2.4731
Im IBExpert Ordner -> Version 1.5.2.4731

Ich gehe mal davon aus, dass Ihr die im System32 Ordner meint, allerdings steht bei beiden als Beschreibung Firebird SQL Server.

[mkinzler]

Die Im Systemverzeichnis gehört zu FB 1. Ersetzte diese durch die zum Server passende oder Kopiere die passende ins Anwendungsverzeichnis

[Sascha-L]

Ich benutze ja auch den Firebird 1.5...

Ach ja wenn wir schonmal dabei dind, (hier gehts grad nen bisschen drunter und drüber :? ) gibt es eine Möglichkeit zu kontrollieren ob der Super oder der Classicserver installiert wurde ?

Sry wenn Ihr euch jetzt an den Kopf packt und meint omg solche Fragen gehöhren Verboten, aber bin ja noch recht unerfahren und in der Ausbildung.

MfG Sascha

[mkinzler]

Die Version der Client-Dll muss zur Version des Servers passen. Handelt es sich um ein eigenes Programm oder entwickelst du ein vorhandenes weiter? Schon versucht die BDE abzulösen?

[Sascha-L]

Die entwicklung der Programme ist eigentlich schon abgeschlossen, jetzt ist halt nur die Frage wieso der Firebirdserver sich zwischendurch aufhängt, desswegen brauche ich ein Analysetool, bei dme ich erkennen kann welcher Client/StoredProcedure/SQL-Befehl dafür verantwortlich ist, dass er sich aufhängt, oder halt ob es an den Transaktionen liegt, ich schwimme vollkommen im Dunkeln, will aber allem nachgehen um zu prüfen was los ist um die Fehler zu beheben. Da wie schon gesagt die Entwicklung der Programme bereits abgeschlossen ist kann ich die BDE nicht ablösen, dies wäre ein riesen Zeit und Geld aufwand, den ich mir im Moment in keinster weise leisten aknn, jedoch bin ich mir darüber bewusst, dass die BDE veraltet ist, und keine optimale Lösung darstellt.
Ich benutze den Firebird 1.5.2.4731 muss ich jetzt noch etwas kopieren oder ändern ?

[hoika]

Hallo,

Superserver / Classic : beim Classic gibt es mehrere fbserver.exe im Taskmanager,
wenn mehr als 2 Rechner (Verbindungen) connected sind.

SQL-Monitor: CTRL+O, dann mal alles raus ausser Tramnsaktionen,
im zweiten Schritt die "Vorbereitete Abfrage-Anweisung" mit dazu.

Vendor: Hersteller , es gibt / gab mal auch odbc-Treiber anderer Firmen.

Zur GDS ist ja alles gesagt.

Heiko

[Sascha-L]

Auf Seite 1 ist ein log, auf dem nur die Transaktionen aktiv sind, wie gesagt, es wäre nett, wenn ich mal nen feedback dazu bekommen würd, ob es (nach diesem log zufolge) alles in Ordnung ist, oder aber ob schon irgendwelche auffälligkeiten zu sehen sind ?!?
Ich gehe dann mal davon aus, dass Xact nur eine ganz normale Aktion des Servers beschriebt, oder liege ich dorf falsch in der Annahme ?

Danke nochmal für die Erklärungen.

[hoika]

Hallo,

das meinte ich

Hier der Log:

1 11:11:54 SQL Transact: INTRBASE - XACT ReadCommitted
2 11:11:54 SQL Transact: INTRBASE - XACT Begin
3 11:11:54 SQL Vendor: INTRBASE - isc_start_transaction
4 11:11:54 SQL Stmt: INTRBASE - Close
5 11:11:54 SQL Vendor: INTRBASE - isc_dsql_free_statement
6 11:11:54 SQL Prepare: INTRBASE - Select * From READAllAuftragsDatenForViewer
("11_09",1)


Da steht mehr drin, z.B. Vendor, Stmt,
dass kann man im SQL-Monitor komplett ausknipsen.


Heiko

[Sascha-L]

Hm, kann sein, dass ich dass am Anfang einstellen muss, noch bevor er irgendetwas mitloggt, habe nämlich einfach denlog gelöscht, die optionen umgestellt, und dann weitergemacht, da wird er den rest wohl mitgeloggt haben, im moment sieht es so aus:

2 15:37:18 SQL Transact: INTRBASE - XACT ReadCommitted
3 15:37:18 SQL Transact: INTRBASE - XACT Begin
4 15:37:18 SQL Transact: INTRBASE - XACT Commit
5 15:37:18 SQL Transact: INTRBASE - XACT ReadCommitted

und dies immerwieder nacheinander.

Ich gehe mal stark davon aus, dass es auch so aussehen sollte oder etwa nicht?
Nur wie soll ich die 2 mal "ReadCommitted" interprätieren?

Ich überlege gerade ob es nicht vlt Sinnvoll wäre den neusten Firebird 1.5 zu installieren, glaubt Ihr das würde irgendwelche unterschiede machen oder Probleme mit sich führen können? :gruebel:

MfG

Sascha

[hoika]

Hallo,

das ReadCommited, wird nach einem Post von der BDE bei TTable gemacht
(TQuery weiss ich jetzt nicht genau), das ist normal.
Die BDE versucht immer einen aktuellen Stand einer offenen TQuery / TTable zu haben
(das war bei Desktop-DB's OK, bei SQL ist es eher hinderlich für mich zumindestens)

Jetzt packe mal die Prepares und Excecutes mit rein
("Vorbereitete Abfrage-Ausführung", "Ausgeführte Abfrage-Anweisung" ganz oben).

Es sollte nicht so sein, dass zwischen vielen Executes immer eine Transaktion steht,
dass wäre dann die BDEmit Ihrem automatischen Transaktionen.

Ausserdem sollte keine Prepare/Execute Paare der gleichen Anweisung hinereinander vorkommen,
das wäre dann eine z.B. Schleife ohne vorigen Prepare.


Unter folgender URL findest du auch noch einen Traffic-Monitor,
ist schon interessant, was so an Daten übers Netz geht.
Da sieth man, was ein Select * alles anrichtet.

Der Monitor hat nur einen Buf, das Reset geht nicht, muss man ihn enfahc noch mal neustarten.

Wie sieht es denn mit dem RAM-Verbrauch auf dem Server aus ?


Heiko
PS: Das Log bitte als Anhang.

Netwerk-Monitor

[Sascha-L]

Wie es mit der Arbeitsspeicherauslastung des Servers aussieht kann ich dir gerade nicht genau sagen, ich übe hier quasie im trockenen für den Ernstfall, dass der Server sich aufhängt, kommt willkürlich vor, es kann sein, dass es mehrere tage mal nicht auftritt und ich dann einen Anruf bekomme, dass mal wieder nichts geht, und genau in diesem Zeitpunkt, will ich wissen woran es liegt, ich habe mir hier zur Simulation ein Testsystem aufgebaut (bin noch nicht ganz fertig), indem alles so configuriert ist, wie es auch im bestehenden System ist, wenn alles soweit fertig ist will ich hier einen Dauertest laufen lassen und siesen mitloggen um den Übeltäter zu finden ^^. Wenn der Fehler das nächste mal Auftreten sollte, sage ich sofort bescheit wieviel Spicher Firebird für sich in Anspruch genommen hat, ich habe bei dem Borland SQL-Monitor jetzt die Sachen so eingestellt wie du es mir gesagt hast und der Log sieht wie folgt aus:

1 16:44:36 SQL Transact: INTRBASE - XACT ReadCommitted
2 16:44:36 SQL Transact: INTRBASE - XACT Begin
3 16:44:36 SQL Prepare: INTRBASE - EXECUTE PROCEDURE ReadMessZopfMessLaenge ?, ?
4 16:44:36 SQL Execute: INTRBASE - EXECUTE PROCEDURE ReadMessZopfMessLaenge :i_RemaTeleg3ALaufIdx, :i_MPMMode
5 16:44:36 SQL Transact: INTRBASE - XACT Commit
6 16:44:36 SQL Transact: INTRBASE - XACT ReadCommitted
7 16:44:36 SQL Transact: INTRBASE - XACT ReadCommitted
8 16:44:36 SQL Transact: INTRBASE - XACT Begin
9 16:44:36 SQL Prepare: INTRBASE - Select * From READMPMAUFTRAG(1)

10 16:44:36 SQL Execute: INTRBASE - Select * From READMPMAUFTRAG(1)

11 16:44:36 SQL Transact: INTRBASE - XACT Commit
12 16:44:36 SQL Transact: INTRBASE - XACT ReadCommitted
13 16:44:37 SQL Transact: INTRBASE - XACT ReadCommitted
14 16:44:37 SQL Transact: INTRBASE - XACT Begin
15 16:44:37 SQL Prepare: INTRBASE - EXECUTE PROCEDURE ReadRemaTeleg3AIstLaufIdx ?
16 16:44:37 SQL Execute: INTRBASE - EXECUTE PROCEDURE ReadRemaTeleg3AIstLaufIdx :i_LaufIdx
17 16:44:37 SQL Transact: INTRBASE - XACT Commit
18 16:44:37 SQL Transact: INTRBASE - XACT ReadCommitted

Meines Erachtens nach macht die Reihenfolge Sinn,bis auf die von dir angesprochenen Prepare-Execute Paare, was meint Ihr dazu?
Mit deinem Netten Tool habe ich herausgefunden, dass alleine diese kleine Befehlskette eine Traffic von ca. 5 MB verursacht. :shock:

MfG Sascha

[hoika]

Hallo

moinz .. ;)

EXECUTE PROCEDURE ReadMessZopfMessLaenge

nur minimaler Traffic, 2 Parameter übergeben, nix zurückbekommen


Select * From READMPMAUFTRAG(1)

Select * heisst,
a) ich brauch alles
b) ich brauch vielleicht nicht alles , aber laden wir erst mal alles

b) ist "schlechter" ;)

Die Ursache des Traffic bekomst du per im SQL-Monitor CTRL+O (oh) + "Fetched Data"

Die Frage ist halt immer, braucht das Programm wirklich die ganzen Daten ?

Die Performance hängt leider von vielen Faktoren ab:

Prepare/Optimize:
FB sucht den besten Weg, die Abfrage zu durchzuführewn (Anzahl der Datensätze, vorhandene Indizes ..)

Execute:
Prozessor, mehr noch die Fest-Platte spielt eine Rolle, wie schnell das geht

Fetch:
der Client holt sich die Daten zeilenweise ab
jedes Byte, was nicht benötigt wird, bremst


Heiko

[Sascha-L]

Morgen...

Ja, danke erstmal für die Erklärungen...
Einiges war mir bereits bewusst anderes kann ich mir jetzt besser denken, das Programm benötigt bei dem "select * from..." aber wirklich alle daten, da diese in einem Grid angezeigt werden solln. Wir achten schon darauf, so zu Programmieren, dass wirklich nur die benötigten Daten auch abgefragt werden, da wie du schon sagtest, alles andere bremst und reine resourcenverschwendung wäre...
Nun ja, ich denke mal ich werde mich heute drannmachen den Firebird in meinem Testsystem zu ärgern und ihn erstmal ordentlich arbeit zukommen lassen, wenn er sich dann aufhängt (wovon auszugehen ist) schaue ich gleich wieviel speicher er benötigt, aber nochmal zu einer alten frage von mir, könnte es irgendwelche positiven bzw. negativen aspekte mit sich führen, wenn ich meine derzeitige Firebird 1.5.2... mit einer 1.5.5... Version ersetze?
Was die Leistung angeht, sind die PC´s mit eig. mehr als genug versehen, also unter nem gig ram und 3 Ghz geht da nichts, was die Festplatten angelangt bin ich mir gerade nicht so sicher, aber ich glaube es wird ein SCSI Raid System in benutzung sein, außerdem sind die Rechner mit GigabitLan oder Glaßfaser verbunden.
Gibt es außerdem noch irgendwas in dem Log, was im Idealfall nicht so sein sollte?

MfG

Sascha

[hoika]

Hallo,

ich habe hier auch die 1.5.2.4731,
keine Ahnung, ob es was bringt, umzusteigen.
Dasd kann man testweise machen, indem Firebird als Zip herunterheladen wird,
die aktuelleVersion unter Dienste angehalten wird und dann
die heruntergeladene mit
fbserver -a

als Anwendung gestartet wird.

Ich habe gerade mal die 1.5.5 genommen und meine Unit-Tests (dUnit)
drüberlaufen lassen (sind nen Haufen SQL-Abfragen).
War praktisch keine Verbesserung.


Heiko

[Sascha-L]

Naja wenn du keinen Unterschied merkst, stell ich den test erstmal nach hinten...
Alsooo...
Ich habe nun in der Testkette mit enormen geschwindigkeiten gearbeitet, bekomme den Firebirdserver auf eine Auslastung von ca. 60-90%, die komplette CPU-Auslastung tendiert ständig gegen 100%, der Speicher des Firebirds beläuft sich dabei zwischen 36-42 MB (Ich habe auf der Testkette noch nicht den Speicher in den Einstellungen des Servers erhöht).
Die Clients verlieren hier allerdings manchmal Daten bzw. die Daten werden (ich denke durch die hohe geschwindigkeit) nicht mehr in der richtigen Reihenfolge angezeigt.
Ja, dass wars erstmal mit dem Bericht bisher...
Wenn noch anregungen da sind oder iuhr ideen habt, was ich noch testen kann, bitte bitte immer her damit ;-)


MfG

Sascha

[hoika]

Hallo,

> Die Clients verlieren hier allerdings manchmal Daten bzw. die Daten werden (ich denke durch die hohe
> geschwindigkeit) nicht mehr in der richtigen Reihenfolge angezeigt.

Das darf gar nicht passieren, egal wie der Server ausgelastet ist.
Auch die Reihenfolge knn durch so etwas nicht verändert werden,
da stimmt dann im Programm etwas nicht.

Schua mal im Firebird Log-File firebird.log nach,
ob das was auffälliges ist.

Steht im Programm-Verzeichnis von Firebird.


Ich hatte mal den Fall, dass der Netzwerktreiber zu alt war.
Der kam dann mit der Datenmenge nicht zurecht
und hat die tcpip-Verbindung gekappt.
Damit war natürlich auch die SQL-Verbindung weg.

Bei einem 2. Fall lag es an der (internen) Netzwerkkarte.
Erst der Einbau einer eigenen Karte hatte das Problem gelöst.


Heiko

[Sascha-L]

Hm, also die PC´s sind quasie Brandneu und haben Gigabit Netzwerkkarten von Intel verbaut, die eig. verdammt gut, schnell und zuverlässig sind. Veraltete treiber kann ich mir auch nicht denken, und im Programm? Naja es läuft ja alles Reibungslos sobald die Geschwindigkeit heruntergestellt wird. Also an der Logik im Programm sollte es nicht liegen, wie gesagt ich arbeite hier mit ungewöhnlich schnellen Zeiten, die im normalen Betrieb so nie erreicht werden, um den Server auszulasten und möglichst Bald den eig. Fehler Simulieren zu können. Aber ich schaue mir den Logfile mal an.


Sascha

[Sascha-L]

Guten Tag Jungs,

Ich habe mir nun ein kleines Programm geschrieben, was einfach die Datenbank mit eingegebenen selects in eingegebener Zeit bombadiert und habe diese mitgeloggt, für gewöhnlich beträgt die Ausführzeit dieses SQL befehls (einfacher Select in diesem fall) 15 oder 16 ms jedoch als ich dass Programm mal eine Weile hab laufen lassen fiel mir auf, dass ich zwischendurch Werte erreiche, die um die 32 ms Ausführzeit für den gleichen Select liegen. Woran kann dass liegen?

Ich weiß, dass jetzt von verdammt großer größenordnung auf so ziemlich die kleinste gegangen wird, und es eig. nicht interessier ob ein select 15 oder 32 ms dauert, jedoch ist dass immerhin mehr als doppelt so lang, also kann man sich ausrechnen, was bei einem Befehl passiert der regulär schon 600ms dauert.

---Später eingefügt---
So, gerade weitergetestet (bin ständig dabei) und schon hatte ich ein noch unglaublicheres Vorkommen, bei einem Select auf eine andere tabelle in einem Intervall von 200ms beträgt die bearbeitungszeit ca 32 ms, jedoch in ein paar Fällen bis zu 560 ms...
Solche Unterschiede dürfen nicht sein, dass ist es genau was uns gerade das Leben zu Hölle macht, danke.
---

Ich hoffe Ihr könnt mir meine Frage beantworten,

MfG



Sascha

[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