Datenbank-Speicher von Lexware-Server erhöhen

Unser Firma hat den Lexware-Server auf sehr potente Hardware umgezogen (SSD-Raid, 4 CPUs, 16GB RAM, 10GBit LAN), aber die Performance ist trotzdem mies (Öffnen von Lohn&Gehalt direkt auf dem Server dauert >20 Sekunden). Es ist ein Windows Server 2012 (64 Bit) und mir fiel auf, dass der Datenbank-Prozess „SQL Anywhere Network Server (32Bit)“ nur knapp über 500MB RAM belegt, auch wenn an vielen Mandanten gleichzeitg gearbeitet wird.

An anderer Stelle im Forum habe ich gelesen, dass man dem Server über eine Änderung an der Datei lxstart.txt bis zu 3,5GB zuweisen kann, was dem Lese-Cache und der allgemeinen Performance zugute kommen soll. Bei der aktuellen Programmversion von Financial Office Pro gibt es diese Datei aber nicht mehr. Auch in der Registry habe ich keinen entsprechenden Eintrag gefunden.

Weiß jemand, wie man den RAM-Zuweisung erhöhen kann? Gibt es den Lexware-Server eigentlich auch in 64Bit? Und habt ihr noch andere Tipps, um den Server bzw. die Lexware-Datenbank zu beschleunigen?

Danke vorab für euer Feedback!

1 „Gefällt mir“

Interessiert mich auch! :slight_smile: Wenn du eine Lösung hast: gerne teilen.

Der Registryeintrag befindet sich unter den Windows Diensten:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\Lexware_Premium_Datenbank\Parameters
Eventuell kann es auch ControlSet001 sein, also
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Lexware_Premium_Datenbank\Parameters

Dort dann den Parameter ‚-c 4GB‘ einstellen. Dies erhöht die Speicheraufnahme auf 3,5GB des Datenbankservers.

Ich selbst habe auch schon mit der AWE Option der Sybase Datenbank experimentiert. Dadurch könnte man einem 32Bit Prozess theoretisch mehr als 4GB Arbeitsspeicher zuweisen. Hat leider nicht funktioniert und der Lexware Support hat dies auch direkt bestätigt.

Zusätzlich sollte die Datenbank und die Auslagerungsdatei auf der SSD liegen.
Wenn möglich, würde ich auch eine RDP oder Terminalverbindung zum Server aufbauen und alle Clients auf dem Server arbeiten lassen. Dies geht immer noch schneller, als im selben Netzwerk mit einem performanten Client zu arbeiten.


Warum Lexware keine 64Bit des Servers anbietet ist mir auch völlig unverständlich. Dies würde die meisten Performanceprobleme der Software lösen, denn die Datenbank (entsprechend deren Größe) könnte dann wohl komplett im Arbeitsspeicher liegen. Dazu habe ich mich in diesem Beitrag schon mal geäußert:

Wow, das ist ja der Wahnsinn! :open_mouth: Flori, dein Registry-Eintrag hat (sobald der Cache ordendlich vorgewärmt ist) die Startzeit von Lohn&Gehalt von 25 auf 12 Sekunden reduziert. Habe es mehrfach nachgemessen.

Und gleich noch ein weiteres Experiment gemacht: es macht Null Unterschied in der Performance, ob man dem Server mehr als 2 Prozessorkerne gibt. Also skaliert die Datenbank auch nicht so richtig bei höherem Core-Count. Gibt es da auch einen Startparameter, der das ändert?

Noch eine Frage: wenn die DB sowieso nur 3,5GB nutzt, macht es dann überhaupt Sinn, dem ganzen Lexware-Server mehr als 8GB RAM zuzuweisen? :question:

Und bezüglich Disk-IO: kann man der Datenbank bzw. dem Lexware Server irgendwo das Logging abgewöhnen? Die ständigen Schreibzugriffe verschlechtern ja bestimmt auch die Latenz beim Raid-Zugriff, sofern man Write-Through verwendet. :unamused:

Ich habe hier die Syntax der Datenbankparameter gefunden:
http://dcx.sap.com/sa160/de/dbadmin/da-dbserver.html

Sehr interessant sehen folgende Parameter aus:

-gb level Setzt die Datenbank-Prozessprioritätsklasse auf level

-gt num Legt die maximale Anzahl von verwendbaren physischen Prozessoren (bis Lizenzlimit) fest. Diese Option ist nur bei Mehrprozessorsystemen sinnvoll.

Hat jemand schon damit experimentiert?

Ob mehr Prozessorkerne deine Datenbank beschleunigen, kann ich nicht sagen. Bei wenigen Benutzern (< 10) und einer performanten CPU würde ich mal behaupten, dass dies wenig Auswirkung auf die Performance hat.

Der Datenbank mehr als 4Gbyte zuzweisen hat keinen Effekt, da das ganze eben als 32Bit Prozess läuft. Das sehe ich eben immernoch als Hauptursache für langsames Arbeiten bei Lexware. Denn wie du schon schreibst, verkürzen sich die Ladezeiten enorm, sobald die Datenbank im Arbeitsspeicher liegt.

in welchem RAID Verbund laufen denn seine SSDs? Die Transkationslogs kann man bei Datenbanken nciht ausschalten und sind zwingend erforderlich. Man kann die Logs höchstens verkürzen, sodass man Speicherplatz spart.

Write-Through ist natürlich generell schlecht für die Performance. Bei einem Server solltest du allerdings auf Hardware setzen die auch in einem RAID Verbund gut performt. Das bedeutet, dass die SSDs und dein RAID Controller eine Powerloss Protection haben sollten.
Dadurch kannst du dann Write-Back, anstelle von Write Through verwenden.

Es handelt sich um ein ganz normales RAID5 aus 5 SSDs. Und eine super performante NAS mit schnellem Controller, eine QNAP TS-1677X. Das Transaktionslog ist für die Datenbank natürlich notwendig. Ich meinte auch eher Info-Logs, wie sie z.B. in der Ereignisanzeige von Windows auftauchen. Write-Through werde ich mal testen, sobald unsere defekte USV wieder läuft. Bis dahin ist es mir zu riskant.

Es gibt ja einige gut bezahlte Dienstleister welche behaupten, die Lexware-Datenbank um den Faktor 10 schneller machen zu können. Ich frage mich, was die wohl tun… Und auch warum das Tool LxTuner nicht mehr existiert, welches vor ein paar Jahren noch als Geheimtipp gehandelt wurde. :unamused:

Das hat bei meinem Warenwirtschaft Premium leider nciht funktioniert.

Ich habe bei beiden Einträgen Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services\Lexware_Premium_Datenbank\Parameters
UND
Computer\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Lexware_Premium_Datenbank\Parameters

Den Wert ‚-c 500M‘ auf ‚-c 4GB‘ geändert, alleridngs startet der Dienst danach nicht mehr?!

Hallo,

c 500M‘ auf ‚-c 4GB ← 4GB ist der Fehler, es muss 4000M sein, dann gehts

Ich selbst habe es mit 3500M getestet

Grüße

1 „Gefällt mir“

Danke, das hat geklappt!

1 „Gefällt mir“