Firebird Monitoring System

[chros]

Hi,

Wir haben ein Datenbank System entwickelt wo eine Application lokal auf die Firebird Datenbank zugreift und clients über das Netzwerk.

Nun ist es so das wir scheinbar performance probleme haben. Bei mehr als 100 Clients die über einen Zeitraum von mehreren Tagen laufen und permanent in die Datenbank schreiben wird das System immer langsamer, da sich dadurch die Datenbank anfüllt (nur um eine Vorstellung zu haben 5 Tage ca. 700.000 Records pro Table) und die Applikation mit selects (nehmen wir mal an) die Datenbank bremst.

Die Application die auf dem Server Lokal läuft kommuniziert mit Firebird direkt über eine Pipe um die Geschwindigkeit zu erhöhen.

Jetzt suchen wir ein Monitoring system welches sich in diese Pipe reinhängen kann um alle aktionen (select, insert, delete, update) mit zu protokollieren, es reichen auch counter, um aussagekräftige Tests zu machen.

Leider habe ich nach tagelangem suchen kein Programm gefunden welches sowas kann. Es gibt zwar von IBExpert ein tool namens "IBExpert Network Monitor" aber das kann leider nur über die Netzwerk ports mit loggen. Die Application auf das Netzwerk umlegen kommt nicht in Frage da wir das System unter realen Umständen testen müssen.

Ich kann verständlicherweise leider nicht mehr Informationen über das System bereitstellen.

Im Endeffekt benötige ich ein Monitoring System welches die Kommunikation zwischen einer Applikation und einer lokalen Datenbank aufzeichnen/analysieren kann um die Probleme herrauszufinden und die Performance zu optimieren.

Vielleicht hat ja wer von Euch auch schon mal mit so einem Problem zu kämpfen gehabt und weis unter umständen ein solches Tool.

Danke, chros.

[TBx]

Hallo chros!

Über welche Komponenten greift Ihr auf den Firebird zu?

Bei den IBObjects z. B. ist eine Monitoring-Komponente mit dabei, die Du einfach mit der IB_Connection verbinden kannst.

Für die Verlangsamung des Datenbankzugriffs würde ich nicht unbeding die Datenmenge verantwortlich machen.
Ich gehe eher davon aus, daß die Application irgend eine Transaktion nicht wieder schließt.
Guck doch mal über IBExpert nach, wie groß der Unterschied zwischen der nächsten Transaktion und der ältesten aktiven ist.


Hope it helps

onlinekater

[negaH]

Vielleicht das hier http://www.devrace.com/en/sqlhammer/ ?

Gruß Hagen

[sakura]

Dein Problem ist sehr wahrscheinlich nicht die Datenbank an und für sich, sondern Eure Software.

Ich denke mal, dass Ihr offene Transaktionen über einen längeren Zeitraum haltet (z.B. oft in Eingabemasken o.ä.) und die Anwender diese nicht schließen, z.B. Kaffee trinken, Rechner und Software über Nacht laufen lassen, etc.. Dadurch muss die Datenbank alle folgenden Änderungen, neue und gelöschte Records versionieren und mit jeder Abfrage durch alle Versionen "lesen" etc. Das macht jede DB unweigerlich irgendwann langsam. Und das ist in über 98% der Performanzprobleme auch die Ursache. Einfach mal über diesen Ansatz schauen. Wenn ein einfache DB-Neustart das Problem behebt (nicht committete Transaktionen werden verworfen, die Versionen aufgeräumt, etc.), dann ist die Wahrscheinlichkeit noch größer, dass das die Ursache ist.

Das imho beste Tool zum Monitoren ist IB Monitor. Einfache mal die älteste, noch offene Transaktions-ID mit der aktuellsten vergleichen. Entfernen sich diese immer weiter voneinander, dann ist oben genanntes Problem zu 100% die Ursache :zwinker:

...:cat:...

[negaH]

Wir nutzen beides, IB Monitor und SQLHammer. SQLHammer hat den Vorteil das es mit den FIBPlus Komponenten direkt zusammenarbeitet. Man sieht also im Log auch die Komponetennamen, SQL Parameter usw. vom FIBPlus.
Desweiteren kann man im SQLHammer dieses Log auf einfache Weise durchsuchen und der Log-Text ist farblich, per Syntaxhighlighting hervorgehoben.

Gruß Hagen

[sakura]

Zitat:

Zitat von negaH

SQLHammer hat den Vorteil das es mit den FIBPlus Komponenten direkt zusammenarbeitet.

Dann muss ich mir den wohl mal anschauen, wenigstens um den kennenzulernen. Danke :zwinker:

...:cat:...

[chros]

Hi,
danke für die sehr schnellen Antworten.

@ onlinekater:

Zugegriffen wird über die Interbase header files. Das komplette System ist in C++ programmiert.

Die Monitoring Komponente ist meines Wissens nach nur möglich wenn man sie in die Anwendung integriert. Das können wir nachträglich nicht mehr machen, das das System schon draußen ist und wir aus behördlichen Gründen keine geänderten Versionen ausliefern dürfen. Darum brauch ich ein externes tool.

@ negaH:

Danke, ich werde mir das Programm mal ansehen.

@ sakura:
Nein offene Transaktionen können es nicht sein. Die Anwendung welche lokal auf dem DB Server läuft schließt einmal täglich zu einem definierten Zeitpunkt ausnahmslos alle Transaktionen. Außerdem greifen keine "Menschen" auf die Datenbank zu. Es gibt keine Eingabemasken etc. auf den clients, keine ein loggen usw. Im Prinzip sind die clients eigenständige Rechner die gesammelte Daten (Delta Daten) auf die Datenbank absichern, und das mehrmals in der Minute.

Wenn sonst noch jemand Tipps hat ich bin für alles offen und leicht verzeifelt. :)

Danke, allen Helfern.

Gruß chros

[negaH]

Mit 100 Clients und 700.000 Datensätze in 5 Tagen PRO Tabelle (bei wieviel Tabellen ?) ist schon eine Größenordnung in der ein einzigster SQL Server an seine Grenzen kommen kann (je nach zeitlichem Traffic). Es wäre also interessant für dich über die Scalierbarkeit des Servers nachzudenken, sprich die Last auf mehere Server zu verteilen.
Ein zweiter Tipp wäre die Überprüfung WIE deine SQLs aussehen, sprich habt ihr bewusst die SQL Server Features wie Stored Procedures ausgenutzt oder nutzt ihr über eure SQLs den Server quasi nur als Fileserver ? Sprich: habt ihr Datenbank Intelligenz auf den Server ausgelagert oder machen das immer noch die Clients.

Gruß Hagen

[chros]

Hmm Tables die die Größenordnung erreichen sind ca. 3.

Es werden keine Files gespeichert sondern überwiegend Zahlen und Text.

Ja wir verwenden Stored Procedures, es wird allerdings auch viel von der Lokalen Applikation übernommen.

Im übrigen habe ich dein empfohlenes Programm (SQLHammer) ausprobiert. Leider kann das nur mit IBX oder über FIBPlus arbeiten. Da wir allerdings eine eigene DLL für die Kommunikation verwenden funktioniert das Programm nicht. Eine Änderung der Dll zu einer Debug Version würde lt. den Programmierern zuviel Zeit in Anspruch nehmen. Schade, ist eigentlich ein sehr schönes Programm.

[negaH]

Ihr benutzt eine eigene DLL ? Hm, dann würde ich exakt dort das Problem vermuten. Aus kommerzieller Sicht ist dies aber ziemlich unüblich.

Gruß Hagen

[mschaefer]

Moin zusammen,

Wieviel Ram hat Eurer Server eigentlich. Würde übrigens das Monitoring ServerSided anlegen. Dafür gibt es einige Hilfsmittel. Zum Beispiel MiTec oder IBConSvc und weiteres unter nachfolgendem Link

Firebird Tools

Viele Grüße // Martin

[chros]

Wir verwenden eine eigene DLL da sie genau auf unsere Anwendung zugeschnitten ist und daher sehr schnell und kompakt ist. Klar könnte es theoretisch sein das die DLL nen Knacks hat, dann müsste allerdings das System auch schon bei wenigen Clients slowdowns bekommen, tut es aber nicht. Erst ab ca. 100 clients und ein paar Tage geschieht es. Darum denken wir das es an irgendeiner Stored Procedure, oder ein Algorithmus Teil der Hauptanwendung ist. Nur das lässt sich erst herausfinden wenn wir sehen was die Datenbank macht wenn er langsam wird. Daraus können wir dann den dafür verantwortlichen Programmteil herausfinden.

@ Martin:

Danke für den Tipp aber die bin ich schon durch. Liefern leider auch keine brauchbaren Ergebnisse, da die alle über TCP/IP funktionieren.

Der Server ist ein Dual Xenon Prozessor (Taktrate weis ich momentan nicht, hab mit der Hardware normalerweise nicht viel am Hut) mit momentan 1 GB Ram (wird noch auf 4 GB aufgestockt).

[TBx]

Zitat:

Zitat von chros

Erst ab ca. 100 clients und ein paar Tage geschieht es.
Darum denken wir das es an irgendeiner Stored Procedure, oder ein Algorithmus Teil der Hauptanwendung ist.

Das widerspricht sich.
Wenn es von der Anzahl der Clients abhängig ist, dann kann es nicht in der Application auf dem Server liegen und auch Stored Procedures scheiden dann als Ursache aus.

Und die Verbindung zu den Clients kannst Du dann tatsächlich mittels IBMonitor mitprotokollieren.

Es sieht nach wie vor nach zu vielen offenen Transaktionen aus.
Schonmal wie des öfteren in diesem Thread vorgeschlagen geprüft?

Gruß

onlinekater

[chros]

So, wir haben es geschafft und ich möchte Euch das auf jeden fall nicht vorenthalten, denn vielleicht benötigt ihr sowas ja auch einmal.

Also das Programm heißt UIBSQLMonitor 1.3.

ist zu finden unter

progdigy.com

Dieses Programm funktioniert einwandfrei. Man gibt einfach die exe an die auf die Datenbank zugreift und die dll über welche sie das macht. Nach drücken auf "Run" wird die Anwendung gestartet. Und fertig. Logt alle querys mit.

So wie es aussieht arbeitet es über Hooks.

Vielen Dank nochmals für die Hilfe. Und vielleicht findet ihr auch einmal Verwendung für dieses kleine aber feine Programm.

@ Onlinekater:

Es bleiben keine offenen Transaktionen, wirklich nicht und falls doch schließt der Server alle ausnahmslos mindestens einmal am Tag. Das ist so hardgecoded und nicht veränderbar. Nur wenn mehrere Clients vorhanden sind steigt auch die Datenmenge sehr stark an. Und selects dauern immer länger. Dadurch ist der Datenbank Server immer beschäftigt und kommt nicht mehr richtig dazu neue Daten von den Clients zu akzeptieren.

Das ist unsere Theorie, und jetzt müssen wir das auch irgendwie belegen. Entwicklungsjob ist was tolles, immer wieder neue Herausforderungen. :)

[IBExpert]

>Leider habe ich nach tagelangem suchen kein Programm gefunden welches sowas kann.
>Es gibt zwar von IBExpert ein tool namens "IBExpert Network Monitor" aber das kann
>leider nur über die Netzwerk ports mit loggen. Die Application auf das Netzwerk
>umlegen kommt nicht in Frage da wir das System unter realen Umständen testen müssen.

Netzwerk kann auch localhost sein, das sollte nicht wirklich das Problem sein.
man muss nur den Connection String anpassen nichts anderes. Sieht für IBExpertSQLMonitor
(ehemals IBMonitor) genau so aus.

mein Tip:

bevor du andere Probleme ins Auge fasst: Wenn das system immer langsamer wird, findet man
den Grund fast immer in der Statistik. Wenn du möchtest, dann erzeuge mal die Statistik
während das System gerade langsam ist und sende diese per email an mich hklemt at ibexpert.biz
Wenn es daran liegt kann ich dir das auf jeden Fall sofort sagen. Wenn nicht gibt es noch
einige andere Möglichkeiten.

Gruß
Holger
www.ibexpert.com

[Jelly]

Zitat:

Zitat von chros

(nur um eine Vorstellung zu haben 5 Tage ca. 700.000 Records pro Table)

Vielleicht etwas offtopic, aber ist es nicht so dass die Datenbankgrösse bei Firebird 1.5 noch auf 4 GB begrenzt ist? Kann mich irren, aber unser IBExpert Mann weiss da sicherlich was Genaueres.

Ich kann Sakura nur Recht geben. Nicht abgeschlossene (bzw. offene) Transaktionen bremsen ein System sehr stark aus, insbesondere je nachdem welcher IsolationLevel benutzt wird.

Wie sehen denn die Abfrage an den 100 Clients üblicherweise aus. Wenn das komplizierte Dinge sind, so ist ein Firebird Server schnell überfordert.

[IBExpert]

>Vielleicht etwas offtopic, aber ist es nicht so dass die Datenbankgrösse bei Firebird 1.5 noch auf 4 GB begrenzt ist?
>Kann mich irren, aber unser IBExpert Mann weiss da sicherlich was Genaueres.

Die Einschränkung gilt nur auf Dateiebene bei Interbase<=6.0, seit Firebird 1.0 ist das 64 Bit Dateisystem
implementiert. Eine Datenbankdatei kann je nach Betriebssystem oder Filesystem eine Maximalgröße erreich
(bei NTFS zum Beipiel maximal 16TB pro Datenbankdatei). Da pro Datenbank bis zu 65536 Dateien zu einer Datenbank
gehören können (ALTER DATABASE ADD SECONDARY FILE ... ist der passende Befehl) reicht das auf weiter interner
Beschränkungen für 2^(31+16)-1 byte oder 131072 Terabyte, oder 131 Petabyte. Solange auf NTFS die 16TB nicht
überschritten sind sollte man auch keine Sekundärdateien anlegen

Sollte also erst mal reichen ;-)

Holger
www.ibexpert.com

[Jelly]

Zitat:

Zitat von IBExpert

reicht das auf weiter interner
Beschränkungen für 2^(31+16)-1 byte oder 131072 Terabyte, oder 131 Petabyte.

Das sollte erstmal reichen :mrgreen:
Danke für die ausführliche Info.