Hallo Forum,
ich bin ein Feld- Wald und Wiesenadmin und betreue ua. einen Windows Server 2012r2 auf dem eine Versicherungssoftware läuft. Die DB dieser Software läuft auf einem Firebird-Server 64 bit mit der Versionsnummer: 3.0.5.33168 (x64).
Der Server ist eine VM, jetzt ProxMox, vorher VMware 5.5 und im Moment hat die VM den VMhost ganz alleine für sich. Auf dem ProxMox läuft also nur einen VM.
Die Vm hat 4 CPU-Kerne und 32 GB Ram die virtuellen Platten laufen auf einem SSD-Raid 10.
Der Grund dieses Postings ist die große Unzufriedenheit der Anwender mit der Performance des Systems. Die Anwender schildern lange Wartezeiten beim Wechsel von Verträgen und Kunden. Zähes öffnen von Dokumenten die in der DB abgelegt sind etc.
Die DB enthält Verträge, MS Office Dokumente, Mails und Jpegs und hat eine Größe von ca. 100 GB.
Der Taskmanager der Servers2012r2 zeigt eine durchschnittliche CPU Auslastung von ca 40 % und eine IO Auslastung mit nur gelegentlichen Spitzen.
Mir ist aufgefallen, daß die Virtualisierungssoftware nach dem Start in kurzer Zeit meldet, dass der gesamte Speicher belegt ist. Das kenne ich eigentlich nur vom Exchange-Server oder vom MS-SqlServer.
Ist das bei Firebird normal?
Ich bin auf der Suche nach Gründen für die Trägheit der Software.
Leider kenne ich, wie ihr sicherlich merkt, Firebird nur vom Namen und ich würde mich über einige Tipps wie ich die Performanceprobleme eruieren könnte und ggf. Abhilfe schaffen kann sehr freuen!!
Vielen Dank im voraus.
MFG RO
Performancetest
Moderator: thorben.braun
-
martin.koeditz
- Beiträge: 474
- Registriert: Sa 31. Mär 2018, 14:35
Guten Morgen,
wir sind vor kurzem ebenfalls auf Proxmox umgestiegen und hatten ähnliche Probleme. Wir betreiben Firebird allerdings unter Linux.
Welcher Speicher läuft zu? Festplatte oder RAM? Firebird selbst ist recht genügsam mit Speicher. Dies lässt sich ja auch konfigurieren. Was läuft sonst noch auf dem System? Ist dies ein DC?
Gruß
Martin
wir sind vor kurzem ebenfalls auf Proxmox umgestiegen und hatten ähnliche Probleme. Wir betreiben Firebird allerdings unter Linux.
Welcher Speicher läuft zu? Festplatte oder RAM? Firebird selbst ist recht genügsam mit Speicher. Dies lässt sich ja auch konfigurieren. Was läuft sonst noch auf dem System? Ist dies ein DC?
Gruß
Martin
Martin Köditz
it & synergy GmbH
it & synergy GmbH
Das ist normales Verhalten einer jeden Datenbank.
Wenn einer VM Speicher zugewiesen wird, kann sie diesen auch komplett nutzen. Was soll daran schädlich sein? Da arbeitet auch die Firebird nicht anders als der SQL-Server.
Um Speicher zu begrenzen, kann man den DB-Cache in der Firebird.conf begrenzen, aber wozu soll das gut sein? Damit verlangsamt man die DB dann auch noch. Bei einer 100GB Datenbank, die u.U. nur wenig historische Daten hat, die also eher selten benötigt werden, sollte man den Hauptspeicher vielleicht sogar noch erhöhen.
Da nun aber Dokumente in der Datenbank liegen, müssen diese ja erst mühsam extrahiert, übers Netz gesendet und wieder lokal gespeichert werden, bevor sie von einer Officeanwendung wieder geöffnet werden können.
Dies ist ein Unterschied zu einem normalen Fileserver. Zudem es da noch einen Unsicherheitsfaktor gibt, dass diese Dokumente ja dadurch durchaus gleichzeitig bearbeitet werden können.
Die Performance der DB sieht nach deiner Aussage eigentlich gut aus.
CPU-Auslastung von 40% und geringe IO-Last deutet darauf hin, dass der größte Teil der Daten bereits im Speicher liegt und die CPU sogar noch 60% an Reserven hat. Auch sollte man mal prüfen, wie hoch dabei die Netzauslastung ist. Wenn das Netzwerk ausgelastet ist, kann auch eine DB nicht schneller werden.
Nun ist es halt mühsam noch herauszufinden welche SQL's laufen, ob genug Indizes existieren, wieviele Transaktionen pro Minute stattfinden und was ganz wichtig ist: wieviele Satzversionen in einer Tabelle ständig überlesen werden müssen.
Gerade letzteres kann sich durchaus schion mal fatal auf die Performance auswirken: Wenn ich fast ausschließlich Abfragen habe ohne dafür jedes mal eine neue Transaktion aufzumachen, führt das bei Änderung von Daten zu Satzversionen die überlesen werden müssen und zudem noch verhindern, dass meine Daten aktuell sind.
Dies passiert vor allem dann, wenn man seine Anwendung u.U. vom SQL-Server migriert, da dieser eher selten bis gar nicht Satzversionen verwendet.
Dazu prüfe mal die MON$DATABASE, wie groß die Differenz zwischen den einzelnen Transaktions-ID's ist.
Hier hilft dann ein regelmäßiger Save/Restore (1x wöchentlich), der mal alles wieder in Grundstellung bringt. 100GB benötigen da ca. 90 Minuten.
Wenn einer VM Speicher zugewiesen wird, kann sie diesen auch komplett nutzen. Was soll daran schädlich sein? Da arbeitet auch die Firebird nicht anders als der SQL-Server.
Um Speicher zu begrenzen, kann man den DB-Cache in der Firebird.conf begrenzen, aber wozu soll das gut sein? Damit verlangsamt man die DB dann auch noch. Bei einer 100GB Datenbank, die u.U. nur wenig historische Daten hat, die also eher selten benötigt werden, sollte man den Hauptspeicher vielleicht sogar noch erhöhen.
Da nun aber Dokumente in der Datenbank liegen, müssen diese ja erst mühsam extrahiert, übers Netz gesendet und wieder lokal gespeichert werden, bevor sie von einer Officeanwendung wieder geöffnet werden können.
Dies ist ein Unterschied zu einem normalen Fileserver. Zudem es da noch einen Unsicherheitsfaktor gibt, dass diese Dokumente ja dadurch durchaus gleichzeitig bearbeitet werden können.
Die Performance der DB sieht nach deiner Aussage eigentlich gut aus.
CPU-Auslastung von 40% und geringe IO-Last deutet darauf hin, dass der größte Teil der Daten bereits im Speicher liegt und die CPU sogar noch 60% an Reserven hat. Auch sollte man mal prüfen, wie hoch dabei die Netzauslastung ist. Wenn das Netzwerk ausgelastet ist, kann auch eine DB nicht schneller werden.
Nun ist es halt mühsam noch herauszufinden welche SQL's laufen, ob genug Indizes existieren, wieviele Transaktionen pro Minute stattfinden und was ganz wichtig ist: wieviele Satzversionen in einer Tabelle ständig überlesen werden müssen.
Gerade letzteres kann sich durchaus schion mal fatal auf die Performance auswirken: Wenn ich fast ausschließlich Abfragen habe ohne dafür jedes mal eine neue Transaktion aufzumachen, führt das bei Änderung von Daten zu Satzversionen die überlesen werden müssen und zudem noch verhindern, dass meine Daten aktuell sind.
Dies passiert vor allem dann, wenn man seine Anwendung u.U. vom SQL-Server migriert, da dieser eher selten bis gar nicht Satzversionen verwendet.
Dazu prüfe mal die MON$DATABASE, wie groß die Differenz zwischen den einzelnen Transaktions-ID's ist.
Hier hilft dann ein regelmäßiger Save/Restore (1x wöchentlich), der mal alles wieder in Grundstellung bringt. 100GB benötigen da ca. 90 Minuten.
Welcher Speicher läuft zu? Festplatte oder RAM? Firebird selbst ist recht genügsam mit Speicher. Dies lässt sich ja auch konfigurieren. Was läuft sonst noch auf dem System? Ist dies ein DC?
Firebird belegt laut Proxmox Gui 98 % des Rams nach ca. 5 min Laufzeit.
Auf dem System läuft sonst nichts.
Oh nein, es ist kein DC.
Firebird belegt laut Proxmox Gui 98 % des Rams nach ca. 5 min Laufzeit.
Auf dem System läuft sonst nichts.
Oh nein, es ist kein DC.
Dazu prüfe mal die MON$DATABASE, wie groß die Differenz zwischen den einzelnen Transaktions-ID's ist.
Hier hilft dann ein regelmäßiger Save/Restore (1x wöchentlich), der mal alles wieder in Grundstellung bringt. 100GB benötigen da ca. 90 Minuten.
Kannst du mir eine Quelle nennen wo ich nachlesen kann wie man das macht?
Oder kannst du es mir erklären?
Danke!
MfG RO
Hier hilft dann ein regelmäßiger Save/Restore (1x wöchentlich), der mal alles wieder in Grundstellung bringt. 100GB benötigen da ca. 90 Minuten.
Kannst du mir eine Quelle nennen wo ich nachlesen kann wie man das macht?
Oder kannst du es mir erklären?
Danke!
MfG RO
Mit ISQL oder jedem anderen Tool, dass SQL aus der DB liest:
select * from mon$database
Interesssant sind die Felder MON$OLDEST_ACTIVE und MON$NEXT_TRANSACTION.
Bei einer Differenz > 20.000 wird normalerweise der sog. Sweeper gestartet um aufzuräumen. Wenn die Differenz sehr groß ist, sollte möglichst bald ein Backup/Restore erfolgen.
Im Firebird-Programmverzeichnis ist u.U. auch mal die Firebird.log auf Fehler zu untersuchen (was man sowieso regelmäßig tun sollte).
Manchmal scheitert der Backup nämlich wenn der Sweeper versagt und dann hilft nur noch ein Programm, dass Tabelle für Tabelle, Zeile für Zeile kopiert um die Daten zu retten.
Bei 100GB kann das durchaus mal 20 Stunden dauern, denn u.U. hat die DB nur ca. 50% oder weniger an Nutzdaten.
Ggf. muss auch mal ein "gfix" versucht werden:
https://www.firebirdsql.org/file/docume ... -gfix.html
Poste mal die gefundenen Werte.
select * from mon$database
Interesssant sind die Felder MON$OLDEST_ACTIVE und MON$NEXT_TRANSACTION.
Bei einer Differenz > 20.000 wird normalerweise der sog. Sweeper gestartet um aufzuräumen. Wenn die Differenz sehr groß ist, sollte möglichst bald ein Backup/Restore erfolgen.
Im Firebird-Programmverzeichnis ist u.U. auch mal die Firebird.log auf Fehler zu untersuchen (was man sowieso regelmäßig tun sollte).
Manchmal scheitert der Backup nämlich wenn der Sweeper versagt und dann hilft nur noch ein Programm, dass Tabelle für Tabelle, Zeile für Zeile kopiert um die Daten zu retten.
Bei 100GB kann das durchaus mal 20 Stunden dauern, denn u.U. hat die DB nur ca. 50% oder weniger an Nutzdaten.
Ggf. muss auch mal ein "gfix" versucht werden:
https://www.firebirdsql.org/file/docume ... -gfix.html
Poste mal die gefundenen Werte.
Hallo,
bevor Du an der falschen Stelle schraubst - versuche mal, die VM auf Durchzug zu stellen. Ich habe reichlich Virtualisierungen auf fetten Servern gesehen, die beim Betrieb eines Datenbankservers eine schlechtere Performance hergaben als ein alter Laptop. Checkt, dass die VM die Ressourcenvergabe nicht von irgendwelchen default-Lastprofilen steuern lässt, das ist für Datenbanken nahezu immer Käse. Ein DB-Server braucht die Ressourcen (alle, CPU, RAM, IO, Platte) immer genau dann, wenn er danach fragt, und so viel, wie er nachfragt, vollständig. Da darf keine Instanz dazwischenhängen, die erstmal gemächlich auswürfelt, wie viel in welchen Häppchen in welcher Zeit der DB-Server zugeteilt bekommt.
Als A/B-Test packt das System auch auf einen nicht-virtualisierten Rechner, dann weißt Du grob, ob es an der Virtualisierung liegt.
Grüße, Volker
bevor Du an der falschen Stelle schraubst - versuche mal, die VM auf Durchzug zu stellen. Ich habe reichlich Virtualisierungen auf fetten Servern gesehen, die beim Betrieb eines Datenbankservers eine schlechtere Performance hergaben als ein alter Laptop. Checkt, dass die VM die Ressourcenvergabe nicht von irgendwelchen default-Lastprofilen steuern lässt, das ist für Datenbanken nahezu immer Käse. Ein DB-Server braucht die Ressourcen (alle, CPU, RAM, IO, Platte) immer genau dann, wenn er danach fragt, und so viel, wie er nachfragt, vollständig. Da darf keine Instanz dazwischenhängen, die erstmal gemächlich auswürfelt, wie viel in welchen Häppchen in welcher Zeit der DB-Server zugeteilt bekommt.
Als A/B-Test packt das System auch auf einen nicht-virtualisierten Rechner, dann weißt Du grob, ob es an der Virtualisierung liegt.
Grüße, Volker