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

**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?

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.

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