Hallo zusammen,
ich habe aktuell ein massives Performance-Problem mit Firebird 2.5 unter Windows Server 2022.
Vorher lief dieselbe Datenbank auf einem Windows Server 2016 völlig problemlos und schnell – identische Hardware, identische Firebird-Version, dieselbe Anwendung.
Seit dem Umstieg auf Windows Server 2022 ist alles extrem träge:
Formularaufrufe dauern mehrere Sekunden, Abfragen brauchen deutlich länger, obwohl CPU und RAM kaum ausgelastet sind.
Details:
Firebird 2.5 (Superserver-Modus)
Windows Server 2022 Standard
SSD, genug RAM, aktuelle Treiber
Gleiche Konfiguration wie vorher (kein Wechsel von Embedded auf Netzwerk usw.)
Hat jemand ähnliche Erfahrungen gemacht?
Kann es an Kompatibilitätsproblemen zwischen Firebird 2.5 und Windows Server 2022 liegen?
Oder an neuen Sicherheitsfeatures, die z. B. die Dateizugriffe bremsen?
Bin für jeden Hinweis dankbar – evtl. muss ich sonst wieder auf Server 2016 zurück.
gruß Chris
Firebird 2.5 auf Windows Server 2022 extrem langsam – vorher unter Server 2016 alles schnell
Moderator: martin.koeditz
Bei mir hat sich der Superserver der 2.5 generell als Engpass im Multiuser-Betrieb herausgestellt.
Es kann nur 1 DB je Thread verarbeitet werden. Wenn also mehrere Connections einer DB Abfragen quasi gleichzeitig machen, werden diese nacheinander verarbeitet.
Der Classic-Server mit Prozess je Connection war da dann doch effektiver.
Ansonsten hatte ich bei der 2.5 auch auf dem 2022er-Server keine Probleme.
Hier helfen nur Analysen über die Indexverwendung von Abfragen.
Auch ein Save/Restore kann da schon mal Wunder bewirken.
Es kann nur 1 DB je Thread verarbeitet werden. Wenn also mehrere Connections einer DB Abfragen quasi gleichzeitig machen, werden diese nacheinander verarbeitet.
Der Classic-Server mit Prozess je Connection war da dann doch effektiver.
Ansonsten hatte ich bei der 2.5 auch auf dem 2022er-Server keine Probleme.
Hier helfen nur Analysen über die Indexverwendung von Abfragen.
Auch ein Save/Restore kann da schon mal Wunder bewirken.
-
martin.koeditz
- Beiträge: 509
- Registriert: Sa 31. Mär 2018, 14:35
Kann mich den Aussagen von bfuerchau nur anschließen. War bei uns genauso.
Gruß
Martin
Gruß
Martin
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
-
martin.koeditz
- Beiträge: 509
- Registriert: Sa 31. Mär 2018, 14:35
Was mir noch einfällt:
Virenscanner aktiv? Journaling im Dateisystem?
Virenscanner aktiv? Journaling im Dateisystem?
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
ich habe im ersten Beitrag vergessen zu erwähnen, dass es sich konkret um einen Windows Server 2022 als Terminalserver handelt. Das Problem betrifft nicht den Datenbank-Server selbst, sondern die Performance der Anwendung auf dem Terminalserver, die auf eine Firebird-2.5-Datenbank zugreift.
Zur Situation:
Die Firebird-Datenbank (.fdb) ist ca. 2 GB groß, das Verzeichnis insgesamt ca. 250 GB.
Die Anwendung läuft lokal auf Clients (z. B. Windows 10) schnell und ohne Auffälligkeiten.
Auf dem Terminalserver 2022 ist die Performance extrem schlecht – also nur bei Zugriff innerhalb einer Remotesitzung.
Der Virenscanner wurde testweise deinstalliert, alle relevanten Verzeichnisse waren vorher bereits korrekt ausgeschlossen – keine Verbesserung.
Das Dateisystem ist NTFS, ob Journaling einen Einfluss hat, konnten wir nicht sicher prüfen.
Könnte es also am Betriebssystem (Server 2022 als RDS) liegen?
Die Hinweise aus dem Thread zum Superserver-Modell (1 Thread für alle Verbindungen) sind auch bei uns ein möglicher Faktor – allerdings lief exakt dieselbe Konstellation unter Server 2016 jahrelang problemlos.
Gibt es Erfahrungen oder Empfehlungen, ob:
ein Wechsel auf Classic Server oder
ein Backup + Restore (zur Indexreorganisation) helfen könnte?
oder ob es grundsätzliche Inkompatibilitäten oder Performanceprobleme von Firebird 2.5 unter Server 2022 als Terminalserver gibt?
Zur Situation:
Die Firebird-Datenbank (.fdb) ist ca. 2 GB groß, das Verzeichnis insgesamt ca. 250 GB.
Die Anwendung läuft lokal auf Clients (z. B. Windows 10) schnell und ohne Auffälligkeiten.
Auf dem Terminalserver 2022 ist die Performance extrem schlecht – also nur bei Zugriff innerhalb einer Remotesitzung.
Der Virenscanner wurde testweise deinstalliert, alle relevanten Verzeichnisse waren vorher bereits korrekt ausgeschlossen – keine Verbesserung.
Das Dateisystem ist NTFS, ob Journaling einen Einfluss hat, konnten wir nicht sicher prüfen.
Könnte es also am Betriebssystem (Server 2022 als RDS) liegen?
Die Hinweise aus dem Thread zum Superserver-Modell (1 Thread für alle Verbindungen) sind auch bei uns ein möglicher Faktor – allerdings lief exakt dieselbe Konstellation unter Server 2016 jahrelang problemlos.
Gibt es Erfahrungen oder Empfehlungen, ob:
ein Wechsel auf Classic Server oder
ein Backup + Restore (zur Indexreorganisation) helfen könnte?
oder ob es grundsätzliche Inkompatibilitäten oder Performanceprobleme von Firebird 2.5 unter Server 2022 als Terminalserver gibt?
Also 2GB DB ist ja extrem klein. Die kann man ja schon fast als Cache in den Speicher laden (Angabe der Cacheseiten in der config, was allerdings bei Classic wiederum nichts bringt, sondern erst ab 3.0).
Wichtig ist auf jeden Fall bei virtuellen Installationen:
- Write-Cache zulassen
- Windows Filecache nicht ausschalten
- auf einem TS genügend Speicher je Client!
Vor allem für letzteres gilt ja: Die Clients und der FB-Server teilen sich den Speicher.
Wenn also eine Anwednung mal so eben und gerne 500MB Speicher benötigt, muss man bei 10 Usern schon mal 5 GB Speicher rechnen. Windows braucht auch noch mal 3-4 GB und der Rest wären weitere Anwendungen, z.B. im Hintergrund. Und der Rest dann vom FB-Serever.
Also prüfen:
Nach Serverstart und Start aller Dienste ohne Useranmeldung die Speicherbelegung prüfen (Taskmanager => Leistung => Arbeitsspeicher).
Prüfen, wieviel Speicher die Clients auf dem TS jeweils benötigen (Taskmanager => Details => Prozesse des Users => Arbeitsspeicher. Letzteres kann bei der Verarbeitung von Tabellen recht groß werden, da die Daten im Speicher nicht komprimiert werden. Die 2GB der Db kann dann schnelle mal unkomprimiert 20GB im Speicher der Clients ausmachen, in Abhängigkeit, wie die Daten genutzt werden.
Und auch prüfen, ob der Server in 64-Bit läuft, denn das ist unabhängig von der Anwendung.
Wichtig ist auf jeden Fall bei virtuellen Installationen:
- Write-Cache zulassen
- Windows Filecache nicht ausschalten
- auf einem TS genügend Speicher je Client!
Vor allem für letzteres gilt ja: Die Clients und der FB-Server teilen sich den Speicher.
Wenn also eine Anwednung mal so eben und gerne 500MB Speicher benötigt, muss man bei 10 Usern schon mal 5 GB Speicher rechnen. Windows braucht auch noch mal 3-4 GB und der Rest wären weitere Anwendungen, z.B. im Hintergrund. Und der Rest dann vom FB-Serever.
Also prüfen:
Nach Serverstart und Start aller Dienste ohne Useranmeldung die Speicherbelegung prüfen (Taskmanager => Leistung => Arbeitsspeicher).
Prüfen, wieviel Speicher die Clients auf dem TS jeweils benötigen (Taskmanager => Details => Prozesse des Users => Arbeitsspeicher. Letzteres kann bei der Verarbeitung von Tabellen recht groß werden, da die Daten im Speicher nicht komprimiert werden. Die 2GB der Db kann dann schnelle mal unkomprimiert 20GB im Speicher der Clients ausmachen, in Abhängigkeit, wie die Daten genutzt werden.
Und auch prüfen, ob der Server in 64-Bit läuft, denn das ist unabhängig von der Anwendung.
Ein Test mit Classic Server oder Firebird 3.0 ist aktuell leider nicht möglich, da wir hier auf die Vorgaben und das Setup des Softwareherstellers angewiesen sind.
Unser Terminalserver (Windows Server 2022, RDS) verfügt über 64 GB RAM und wird in der Regel nur von drei Benutzern gleichzeitig verwendet. Die RAM-Auslastung liegt dabei bei lediglich 10–12 GB, es besteht also keinerlei Speichermangel.
Der Write-Cache ist sowohl im Hypervisor (VMware bzw. Proxmox) als auch im Gastsystem aktiv.
Der Windows Filecache sollte nach unserem Kenntnisstand standardmäßig aktiv sein – uns ist keine Möglichkeit bekannt, diesen gezielt zu deaktivieren (auch nicht über Registry-Einträge).
Als Festplattensystem ist NVMe im Einsatz – hier konnten wir bisher keine Hinweise auf Engpässe feststellen.
Zum Thema Benchmarking:
Wir haben Tests mit dem IBExpert Benchmark durchgeführt – das Verhalten ist dabei sehr inkonsistent:
Teilweise normale Werte,
teilweise extrem langsame Werte,
und das selbst bei direkt aufeinanderfolgenden Durchläufen.
Auf lokalen Clients außerhalb des Terminalservers läuft die Anwendung deutlich schneller, obwohl sie ebenfalls auf dieselbe Datenbank zugreifen.
Netzwerktests (z. B. iperf3, SMB-Kopiertests) zeigen durchgehend volle 1 Gbit/s Leistung zwischen Server und Clients – die Verbindung ist also performant und stabil.
Unser Terminalserver (Windows Server 2022, RDS) verfügt über 64 GB RAM und wird in der Regel nur von drei Benutzern gleichzeitig verwendet. Die RAM-Auslastung liegt dabei bei lediglich 10–12 GB, es besteht also keinerlei Speichermangel.
Der Write-Cache ist sowohl im Hypervisor (VMware bzw. Proxmox) als auch im Gastsystem aktiv.
Der Windows Filecache sollte nach unserem Kenntnisstand standardmäßig aktiv sein – uns ist keine Möglichkeit bekannt, diesen gezielt zu deaktivieren (auch nicht über Registry-Einträge).
Als Festplattensystem ist NVMe im Einsatz – hier konnten wir bisher keine Hinweise auf Engpässe feststellen.
Zum Thema Benchmarking:
Wir haben Tests mit dem IBExpert Benchmark durchgeführt – das Verhalten ist dabei sehr inkonsistent:
Teilweise normale Werte,
teilweise extrem langsame Werte,
und das selbst bei direkt aufeinanderfolgenden Durchläufen.
Auf lokalen Clients außerhalb des Terminalservers läuft die Anwendung deutlich schneller, obwohl sie ebenfalls auf dieselbe Datenbank zugreifen.
Netzwerktests (z. B. iperf3, SMB-Kopiertests) zeigen durchgehend volle 1 Gbit/s Leistung zwischen Server und Clients – die Verbindung ist also performant und stabil.
-
martin.koeditz
- Beiträge: 509
- Registriert: Sa 31. Mär 2018, 14:35
Klingt nach Problemen mit der Ressourcenzuteilung durch den Hypervisor. Liegt eine Überbuchung vor?
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
Unter den genannten Bedingungen würde ich auch auf den Host tippen.
Es gibt 2 Formen der Überbuchung:
- Memory Zuteilung
- CPU Zuteilung
Da sich das phasenweise auswirkt tippe ich auf massiven Ressourcenverbrauch anderer VM's auf dem Host.
Das Netzwerk mit 1GBit/Sekunde (= 100 MB/Sekunde) sind in Bezug auf die Schreib/Lesegeschwindigkeiten von HDD (150-300MB/Sekunde) und gerade auch SSD (500-900MB/Sekunde) der Engpass überhaupt.
Jedoch ist das Intranetzwerk einer VM nicht an die Physik des LAN's/WLAN's gebunden und geht mit erhebliche höheren Datenraten, was eben durch Ressourcenverbrauch anderer Anwendungen/VM's erheblichen Einfluss hat.
Abschalten des Filecaches ist eine Funktion der Firebird selber.
https://firebirdsql.org/file/documentat ... cache.html
Ob es die bei FB 3.0ff noch gibt kann ich nicht beurteilen.
Es gibt 2 Formen der Überbuchung:
- Memory Zuteilung
- CPU Zuteilung
Da sich das phasenweise auswirkt tippe ich auf massiven Ressourcenverbrauch anderer VM's auf dem Host.
Das Netzwerk mit 1GBit/Sekunde (= 100 MB/Sekunde) sind in Bezug auf die Schreib/Lesegeschwindigkeiten von HDD (150-300MB/Sekunde) und gerade auch SSD (500-900MB/Sekunde) der Engpass überhaupt.
Jedoch ist das Intranetzwerk einer VM nicht an die Physik des LAN's/WLAN's gebunden und geht mit erhebliche höheren Datenraten, was eben durch Ressourcenverbrauch anderer Anwendungen/VM's erheblichen Einfluss hat.
Abschalten des Filecaches ist eine Funktion der Firebird selber.
https://firebirdsql.org/file/documentat ... cache.html
Ob es die bei FB 3.0ff noch gibt kann ich nicht beurteilen.