Firebird Backup Tool gbak unter Linux Mint v19.3 Cinnamon 4.4.8

[vr2]

Hallo Michael,

3.0.8er gbak restore, 1 thread: 02:42h für 180Gb
5.01er gbak restore, 12 threads: 00:25h für 180Gb

Ja, und auch das backup geht schneller. Hast Du die 12 Threads als Optimum ermittelt oder sind das die log. CPUs des Servers? Ich hatte bei Tests festgestellt, dass es nicht mehr bringt, sämtliche Threads, die die CPU parallel kann, als ParallelWorkers für Firebird zu konfigurieren, so kam ich bspw auf 6 ParallelWorkers bei einem Laptop mit 8 Threads. Es spielt ja auch eine Rolle, ob die Platte/Controller da mithalten kann.

Backup/Restore-Strategie: Genau, immer restore in eine neue DB, und erst wenn das geklappt hat - kriegt man erzählt - umschalten. Dass ihr mehrfach kaputte backups und DBs bei Kunden hattet, ist allerdings eine Sache, die ihr mal untersuchen müsstet. Das ist nicht der Normalfall. Arbeiten die Kunden mit Netzlaufwerken für die DBs oder VirenSW, die beliebig dazwischengrätscht?

[bfuerchau]

Man muss auch immer daran denken, für Abfragen weiterhin Kapazität zu haben. Es bringt also nichts, wenn der Backup dann nur 25 Minuten braucht, wenn währenddessen Abfragen dann extrem länger benötigen.
Wenn kein 24/7-Betrieb vorliegt, kann man fast aus dem Vollen schöpfen.
Allerdings bekomme ich von Kunden da schon mal zu hören, dass bei einer 100%-Auslastung einer VM die anderen VM's dann stark drunter leiden, da die Cores mit VM's gerne überbucht werden, da viele Server eher bei 1-2% dahindümpeln.

[RS667]

Hallo Michael,

3.0.8er gbak restore, 1 thread: 02:42h für 180Gb
5.01er gbak restore, 12 threads: 00:25h für 180Gb

Ja, und auch das backup geht schneller. Hast Du die 12 Threads als Optimum ermittelt oder sind das die log. CPUs des Servers? Ich hatte bei Tests festgestellt, dass es nicht mehr bringt, sämtliche Threads, die die CPU parallel kann, als ParallelWorkers für Firebird zu konfigurieren, so kam ich bspw auf 6 ParallelWorkers bei einem Laptop mit 8 Threads. Es spielt ja auch eine Rolle, ob die Platte/Controller da mithalten kann.

Backup/Restore-Strategie: Genau, immer restore in eine neue DB, und erst wenn das geklappt hat - kriegt man erzählt - umschalten. Dass ihr mehrfach kaputte backups und DBs bei Kunden hattet, ist allerdings eine Sache, die ihr mal untersuchen müsstet. Das ist nicht der Normalfall. Arbeiten die Kunden mit Netzlaufwerken für die DBs oder VirenSW, die beliebig dazwischengrätscht?

Hallo,

ich hab die 12 Threads nicht empirisch ermittelt, das war tatsächlich ein Wert aus dem Bauch heraus, weil der Epyc halt 16 physische, 32 logische Cores hat. Und da ich meistens nur kurz Load auf 1-4 Kernen habe hab ich bei den restlichen zum testen aus dem vollen geschöpft.
Wir monitoren die Maschine mit Prometheus und Grafana, da sieht man recht gut, ob das noch okay ist. Zur Not hätte ich den gbak beendet.

Es werden übrigens die per -par Schalter verwendeten Threads auch nicht die ganze Zeit voll verwendet, ich habe im htop zur Laufzeit CPU Loads zwischen 60% und 1100% auf dem FB5/gbak gesehen. Das hat variiert. Load auf der "Platte" kann ich leider nicht beziffern, da dort gerade was anderes großes läuft, was 3500-4200IOPS verursacht. Der Job sollte übermorgen fertig sein, dann kann ich dazu was sagen.

Bezüglich der defekten Dbs und Backups: Bei dem Kunden, wo das vermehrt auftrat ist es nach dem Tausch des ganzen Srervers seinerzeit nicht mehr aufgetreten. Wir hatten zuerst den RAM im Verdacht, dann die Platten am RAID Controller, und als das nichts brachte haben wir die Maschine final ganz ausgetauscht. Sie war zu dem Zeitpunkt auch schon 6 Jahre, lief aber ansonsten tadellos. Defekte files oder sonstige Dinge traten nur in FB auf, damals Version 1.5. Die anderen 2 Beispiele waren auf einer Maschine, die mal einen Stromausfall miterlebt hat, und auf einer VM, wo Jemand einen Snapshot angewendet hatte. Da habe ich dann geholfen. Ist also kein Massenphänomen, nur etwas Erfahrung aus den letzten 18 Jahren.

Bezüglich 24/7 und vm: ICH persönlich würde Datenbanken, von denen ich Performance erwarte, niemals auf einer VM betreiben. Wir haben je einen dedizierten Datenbankserver pro Standort, auf dem die FB3, Maria und MongoDB laufen. Die Maschinen sind 24/7 verfügbar, abgesehen von kurzen Wartungsfenstern, die ich für Updates, ggf. Umbauten o.Ä. nutze. Wir haben einige inhouse-User, die hier mit einer Software von Externen arbeiten und viele Webapplikationen, die von Kunden und Geschäftspartnern genutzt werden können. Das muss schon 24/7 da sein.
Final wollte ich mich irgendwann mal damit beschäftigen, dass wir die DBs gesynct auf mehreren Blechen betreiben, um eine höhere Verfügbarkeit zu gewährleisten, aber....Zeit, Geld, Knowledge...Ihr kennt das.

MfG Michael

[martin.koeditz]

Hallo Michael,

danke für den abschließenden Bericht. Das wird sicherlich dem einen oder anderen noch hilfreich sein.

Gruß
Martin

[bfuerchau]

Ein eigener Server nur für die DB ist unseren Kunden i.d.R. zu teuer. Warum hat man denn einen 16/24/nn-Core-Rechner wenn man für die DB einen eigenen Hardwareserver nehmen soll?
Wenn die richtige VM-Steuerung keine Überbuchung von CPU oder Speicher zulässt bzw. darauf geachtet wird, ist eine VM nicht nachteilig.
Bei Linux hast du das Lizenzproblem nicht so wie bei Windows. Aber Windows wird halt nach Cores lizensiert. Unsere Anwendungen sind Windowsanwendungen und benötigen daher Windowsserver. Selbst die kleinsten Servermodelle haben bereits 8 Cores, 16 Threads, was für unsere FB-Anwendung schon überdimensioniert sind.

[RS667]

Ein eigener Server nur für die DB ist unseren Kunden i.d.R. zu teuer. Warum hat man denn einen 16/24/nn-Core-Rechner wenn man für die DB einen eigenen Hardwareserver nehmen soll?
Wenn die richtige VM-Steuerung keine Überbuchung von CPU oder Speicher zulässt bzw. darauf geachtet wird, ist eine VM nicht nachteilig.
Bei Linux hast du das Lizenzproblem nicht so wie bei Windows. Aber Windows wird halt nach Cores lizensiert. Unsere Anwendungen sind Windowsanwendungen und benötigen daher Windowsserver. Selbst die kleinsten Servermodelle haben bereits 8 Cores, 16 Threads, was für unsere FB-Anwendung schon überdimensioniert sind.

Ja, das kann ich verstehen. Ist auch etwas OT, aber ich antworte trotzdem mal. Meiner Erfahrung nach sind sowohl Firebird als auf Maria wirklich feinfühlig, was Latenzen angeht. Darüber nachgedacht hatte ich das erste mal, als ich ein Paper von Holger gelesen habe, in dem es um "Firebird und die Cloud" ging. Laut seinen tests - und die kann ich mittlerweile tatsächlich bestätigen - bemerkt man sogar einen Unterschied, wenn ein RAID Controller oder fiber zwischen CPU und dem Speicher hängt. Und gleiches gilt für den zusätzlichen Layer, den eine Virtualisierungsumgebung mit sich bringt.
Das mag man in vielen Szenarien nicht bemerken, ich bin aber der Meinung, dass wir das hier bei uns in den Firmen schon bemerkt haben. Gerade, wenn wir viele User parallel auf unseren Webapplikationen haben, während der Innendienst auf der Delphi Applikation arbeitet und wir viele Importe machen. Das kann natürlich auch daran liegen, dass die closed source Geschichte teils immens unoptimiert auf der DB herum rackert, aber trotzdem ist bei höheren Loads schon gut festzustellen, dass Zugriffe wirklich schnell statt finden mittlerweile. Auch wenn ich die durch einen wirklich, wirklich großen Cache sehr minimieren konnte, zumindest lesend.

MfG Michael

[bfuerchau]

Vieles kann man mit entsprechenden Cacheeinstellungen ausgleichen.
a) Den Windows Filecache nicht abschalten.
b) Den Cache der FB habe ich auf 16GB (1Mio. Pages á 16K) hochgesetzt (halber Speicher).
Dann halte ich eine permanente Verbindung aufrecht, die alle 60 Sekunden eine leere Transaktion durchführt. Dies hält den Cache aufrecht und oldest Transaction wächst mit.
Die einzelnen DB-Aktionen werden mit Open/Aktion1....AktionN/Commit/Close durchgeführt. Den FBClient-Pool nutze ich nicht, da sonst mal Transaktionen hängenbleiben und Satzversionen auflaufen können.
Der Windows-Filecache ist auch nicht zu verachten, da die FB, zumindest auf Windows, mit Memorymapped File arbeitet und da wirkt auch der Cache.
Ein Test diesbezüglich zwischen VM und Real lief sogar zugunsten der VM, da der Cache hier eine wesentliche Verbesserung brachte. Mehr als 16GB brachten da seltsamer Weise nichts mehr, da wohl der Overhead der Verwaltung zu teuer wird.
Daher auch die Hinweise an die Kunden, eine VM gezielt herunter zu fahren, damit der Write-Cache der FB noch geschrieben werden kann und die Konsistenz der FB erhalten bleibt.
Dies alles mit FB3.0, mit 4 oder 5 sollte es da nicht schlechter laufen.

[RS667]

Vieles kann man mit entsprechenden Cacheeinstellungen ausgleichen.
a) Den Windows Filecache nicht abschalten.
b) Den Cache der FB habe ich auf 16GB (1Mio. Pages á 16K) hochgesetzt (halber Speicher).
Dann halte ich eine permanente Verbindung aufrecht, die alle 60 Sekunden eine leere Transaktion durchführt. Dies hält den Cache aufrecht und oldest Transaction wächst mit.
Die einzelnen DB-Aktionen werden mit Open/Aktion1....AktionN/Commit/Close durchgeführt. Den FBClient-Pool nutze ich nicht, da sonst mal Transaktionen hängenbleiben und Satzversionen auflaufen können.
Der Windows-Filecache ist auch nicht zu verachten, da die FB, zumindest auf Windows, mit Memorymapped File arbeitet und da wirkt auch der Cache.
Ein Test diesbezüglich zwischen VM und Real lief sogar zugunsten der VM, da der Cache hier eine wesentliche Verbesserung brachte. Mehr als 16GB brachten da seltsamer Weise nichts mehr, da wohl der Overhead der Verwaltung zu teuer wird.
Daher auch die Hinweise an die Kunden, eine VM gezielt herunter zu fahren, damit der Write-Cache der FB noch geschrieben werden kann und die Konsistenz der FB erhalten bleibt.
Dies alles mit FB3.0, mit 4 oder 5 sollte es da nicht schlechter laufen.

Interessant. Die einzigen Momente, in denen ich keine Verbesserung der Performance durch höhere cache Sttings feststellen konnte waren die, in denen der Cache nicht voll genutzt wurde. Wie groß sind denn die verwendeten Dbs? Und reden wir da von vielen Blob Fields? Hier ist das recht gemischt. Bei den Webapplikationen haben wir auch einen connection hold drin. Ein frischer Aufbau und nach Abarbeitung sauberes schließen ist von der Performance her sehr nachteilig gewesen, das wurde anfangs getestet. Jetzt ist es so, dass pro "ankommendem" user eine Connection geöffnet wird, und diese Connection wird dann durch die gesamte Session hindurch reused. Geschlossen werden Verbindungen nur, wenn sie nicht mehr genutzt wird, und die Anzahl der Connections oberhalb der konfigurierten Mindestmenge ist.

[bfuerchau]

Weiter Off Topic .
Bei uns gehts fast ausschließlich um BI, also ETL und Dashoards.
Dabei werden i.W. nur wenige Typen benötigt:
Date, varchar, int, bigint, double.
BLOB's spielen gar keine Rolle, da diese im Zweifel sowieso aufbereitet und verwertbare Daten extrahiert werden. Double hat sich trotz Ungenaugikeiten auch für Finanz-Dashboards bewährt und die berühmten 1-Cent-Differenzen treten auch nicht auf. Hinzu kommt die native Unterstützung für jedewede Berechnung durch die Hardware, die bei Decimal längst nicht so effektiv ist.
ETL-Prozesse erzeugen naturgemäß viele und große Satzversionen, da alte Daten entfernt und neue Daten hinzugefügt werden. Updates gibts i.W. nicht, Delete/Insert (via SQL-Bulk) ist die effektivste Methode.
Bei Abfragen wird ein SQL, der i.W. durch Klick-Methoden in einem Designer modelliert wird, analysiert und es werden sogar dynamisch Indizes erstellt.
Diese werden beim ETL dann deaktiviert und hinterher aktiviert, was immer noch zwischen 10.000 und 25.000 Inserts/Sekunde (je nach Anzahl Spalten) ermöglicht.
Beim Query werden die Daten ebenso auch aggregiert, bevor sie an das Dashboard übergeben werden. Der Group by, automatisch generiert, kann da schon mal 50 Spalten umfassen. Via der Caches kommen dann trotzdem noch zwischen 15.000 und 30.000 Zeilen/Sekund als Result zurück.
Beim Laden der Dashboards wird je Tabelle ein paralleler Query (die 2.5 im Classic-Mode, je Query 1 Prozess) ausgeführt. Wobei Tabelle da zu enschränkend ist, da auch hier ein Modell mit zig Joins (1-255) möglich ist. So 3-10 ist da die Regel.
Und wenn alle Queries durch sind werden diese im Web gecached um eine 2. oder weitere ähnliche Abfragen nicht zu wiederholen.
Anschließend sind alle Verbindungen wieder zu.
Durch eine eigene Poolverwaltung werden nicht mehr Queries erzeugt als CPU's vorhanden sind und ansonsten halt gequeued. So lassen sich durchaus einige 100 User über einen Server behandeln.

[martin.koeditz]

Die Test-Restores führen wir mittlerweile in den Abendstunden durch. Durch die Parallelisierung ist das so schnell, dass wir keine Probleme mehr mit Zeitfenstern haben. Das ist schon fix geworden.