Keine Rückmeldung in JTL Wawi sobald SQL Server Memory durch Database Cache ausgeslastet ist

[Morgan_Pup]

Hallo zusammen,

wir haben ein Problem mit unserem JTL wo uns der Support bis jetzt nocht nicht weiterhelfen konnte. Folgend eine kurze Schilderung.

- Unserem SQL Server Dienst haben wir 24 GB Ram zugewiesen (bei 22 GB Datenbank)
- Wir konnten nun öfters beobachten das sobald der SQL Server Dienst die 24 GB komplett genommen hat, JTL dann immer wieder in "Keine Rückmeldung" geht
- Das was wir nicht verstehen, ist das von den 24GB quasi 20 GB lediglich für den Database Cache genutzt werden.
- Direkt per SSMS kann man Queries ausführen wie man will, es funktioniert alles.
- Deshalb verstehen wir nicht warum JTL Wawi dann nicht mehr läuft.


Weil meines Verständniss nach sollte sich JTL Wawi dann einfach was vom Database Cache nehmen um die Queries auszuführen.

 

[SebiW]

Habt Ihr die GPo "Sperren von Seiten im Speicher" für den SQL User aktiviert? Kann gut sein dass Windows swappt weil der RAM voll ist und JTL dann in Timeouts rennt.
Unabhängig davon braucht der SQL ja auch Cache für interne Prozesse etc, bei 22 GB DB wären ~28 GB optimal. 22 für die DB, ~6 für internes Caching der Ausführungspläne etc.
Kurz, der RAM ist mit der DB voll und die SQL Server hat für seine eigenen Prozesse nicht genug Arbeitsspeicher zur Verfügung. Heisst RAM freimachen, auf die Platte swappen, warten.

 

[Morgan_Pup]

Habt Ihr die GPo "Sperren von Seiten im Speicher" für den SQL User aktiviert? Kann gut sein dass Windows swappt weil der RAM voll ist und JTL dann in Timeouts rennt.
Unabhängig davon braucht der SQL ja auch Cache für interne Prozesse etc, bei 22 GB DB wären ~28 GB optimal. 22 für die DB, ~6 für internes Caching der Ausführungspläne etc.
Kurz, der RAM ist mit der DB voll und die SQL Server hat für seine eigenen Prozesse nicht genug Arbeitsspeicher zur Verfügung. Heisst RAM freimachen, auf die Platte swappen, warten.

Hey, auf 28 GB haben wir schon erhöht an RAM für den SQL Service.

Die GPO die du erwähnt hast ist nicht aktiviert. Als Info, der Server hat nun insgesamt 40 GB RAM und SQL Service ist auf 28 GB begrenzt.
Der eigentliche Server RAM wird entsprechend nie voll ausgelastet, deshalb sollte auch kein Swap passieren.

 

[SebiW]

Da macht Windows gerne mal Zeug im Hintergrund - auf ein "Sollte" würde ich mich nicht verlassen. Die GPO erlaubt dem SQL Server den Speicher zu fixieren so dass Windows da die Griffel von lässt:
https://learn.microsoft.com/de-de/s...n-memory-option-windows?view=sql-server-ver17
https://learn.microsoft.com/de-de/s...ew=sql-server-ver17#lock-pages-in-memory-lpim
Sollte auf jedem Server mit genug Speicher immer aktiviert sein.
Sind bei Euch die übrigen SQL Konfigurationen gemäß JTL best practices eingerichtet? Auch falsche Paralleltität ist da gerne mal ein Aas. Und natürlich die Frage ob die TempDBs etc korrekt konfiguriert sind.
https://guide.jtl-software.com/jtl-wawi/installation/sql-server-optimal-einrichten/
JTL hat da mittlerweile ja ein nettes Tool mit dabei das da die Grundeinstellungen setzt.

Ah ja und bare metal oder VM? Wenn VM: Mal geprüft ob es da nicht schlicht zu Engstellen bei CPU und IOPS kommt?

 

[Morgan_Pup]

Da macht Windows gerne mal Zeug im Hintergrund - auf ein "Sollte" würde ich mich nicht verlassen. Die GPO erlaubt dem SQL Server den Speicher zu fixieren so dass Windows da die Griffel von lässt:
https://learn.microsoft.com/de-de/s...n-memory-option-windows?view=sql-server-ver17
https://learn.microsoft.com/de-de/s...ew=sql-server-ver17#lock-pages-in-memory-lpim
Sollte auf jedem Server mit genug Speicher immer aktiviert sein.
Sind bei Euch die übrigen SQL Konfigurationen gemäß JTL best practices eingerichtet? Auch falsche Paralleltität ist da gerne mal ein Aas. Und natürlich die Frage ob die TempDBs etc korrekt konfiguriert sind.
https://guide.jtl-software.com/jtl-wawi/installation/sql-server-optimal-einrichten/
JTL hat da mittlerweile ja ein nettes Tool mit dabei das da die Grundeinstellungen setzt.

Ah ja und bare metal oder VM? Wenn VM: Mal geprüft ob es da nicht schlicht zu Engstellen bei CPU und IOPS kommt?

Ich habe die GPO mal eingestellt.

Da ich das System erst seit ein paar Monaten betreue, weiß ich nicht was in der Vergangenheit gemacht wurde,
aber bezüglich TempDB -> Die Gibts bei uns gar nicht. Abgesehen davon sind die empfohlenen Einstellungen soweit gemacht anscheinend.

Engstellen in den anderen Themen konnten wir nicht sehen.
Wie gesagt das Problem tritt Punkt genau dann auf wenn der SQL Service denn RAM den er zugewiesen hat, komplett ausnutzt. Und nutzen tut er denn
ja im Endeffekt nur für Database Cache.
Abgesehen davon das JTL dann in Keine Rückmeldung gibt, sieht und merkt man sonst nichts am SQL Server. Wie gesagt Queries die ich per SSMS ausführe laufen auch ohne Probleme.

 

[SebiW]

Es muss eine TempDB geben. In der TempDB laufen alle aktiven Prozesse rein:
https://learn.microsoft.com/de-de/s...tabases/tempdb-database?view=sql-server-ver17
Ich glaube nicht dass das Ding im aktiven Betrieb ohne TempDB überhaupt lauffähig ist?

Und: Wie sind die Konfigurationen für Datenbankwachstum? Habt Ihr da vernünftige Schwellenwerte? Wenn der SQL bei jeder Abfrage häppchenweise die Datenbank um Miniwerte wie 64 MB erhöht hättet Ihr auch ständig IO Last.
Der SQL Server muss ja trotzdem ständig lokal schreiben. Ich würde mal primär in dieser Richtung forschen und mir ansehen wie die Auslastung auf dem Server bei den entsprechenden Prozessen ist. Wenn Du da ständig ne 100% Festplattenauslastung fährst hast Du Deinen Schuldigen.

Und wenn der SQL den zugewiesenen Speicher voll ausnutzt heisst das im Normalfall, dass der Speicher nicht genügt. Meiner hat 128GB zugewiesen und nimmt sich davon etwa 80. Bei Bedarf steigt das. Wenn Dein SQL Server sofort weiteren zugewiesenen RAM blockiert bedeutet das zwangsweise, dass nicht alles im Speicher gehalten werden kann. Was widerum bedeutet: swappen. Hast Du mal im SQL Server nachgeschaut wieviel er wirklich belegt?

Insofern mal Page Life Expectancy prüfen, wenn die problematisch ist weisst Du worans liegt.

 

[Morgan_Pup]

Es muss eine TempDB geben. In der TempDB laufen alle aktiven Prozesse rein:
https://learn.microsoft.com/de-de/s...tabases/tempdb-database?view=sql-server-ver17
Ich glaube nicht dass das Ding im aktiven Betrieb ohne TempDB überhaupt lauffähig ist?

Und: Wie sind die Konfigurationen für Datenbankwachstum? Habt Ihr da vernünftige Schwellenwerte? Wenn der SQL bei jeder Abfrage häppchenweise die Datenbank um Miniwerte wie 64 MB erhöht hättet Ihr auch ständig IO Last.
Der SQL Server muss ja trotzdem ständig lokal schreiben. Ich würde mal primär in dieser Richtung forschen und mir ansehen wie die Auslastung auf dem Server bei den entsprechenden Prozessen ist. Wenn Du da ständig ne 100% Festplattenauslastung fährst hast Du Deinen Schuldigen.

Und wenn der SQL den zugewiesenen Speicher voll ausnutzt heisst das im Normalfall, dass der Speicher nicht genügt. Meiner hat 128GB zugewiesen und nimmt sich davon etwa 80. Bei Bedarf steigt das. Wenn Dein SQL Server sofort weiteren zugewiesenen RAM blockiert bedeutet das zwangsweise, dass nicht alles im Speicher gehalten werden kann. Was widerum bedeutet: swappen. Hast Du mal im SQL Server nachgeschaut wieviel er wirklich belegt?

Ignorier meinen Kommentar zu der Tempdb, da hab ich an was anderes gedacht als die SQL System Databases.

Wie gesagt die restlichen Auslastungen sind nicht auffällig.

Der RAM steigt relativ stetig, auffällig ist das zu bestimmten Zeitpunkten die Nutzung relativ plötzlich steigt, wahrscheinlich bei bestimmten Aktionen in JTL die ich aber nicht ausfindig machen kann.
Ich werde die Begrenzung eventuell mal rausnehmen, um zu beobachten wie viel er sich nehmen würde. RAM -Daten vom SQL kann ich wie folgt sehen (momentan Auslastung) im Anhang:

 

[SebiW]

Was sagt denn die PLE? Wenn er da nicht auffällig niedrige Werte bringt sollte das zumindest als Fehler ausgeschlossen werden können.
Wie siehts mit Deadlocks aus? Läuft irgendwas externes parallel, das die Wawi da flach legt? Autoimporte, externe Tools usw.

 

[Morgan_Pup]

Im Anhang sind die PLE Werte, generell läuft nichts außer ein automatisiertes Backup der Datenbank. Bezüglich PLE muss ich schauen was für uns "gute" Werte sind.

 

[Morgan_Pup]

Ich konnte heute mehr sehen, auch wenn mir das noch nicht weiterhilft.
Bei bestimmten Aktionen in JTL wird vor allem der Buffer POOL der tempdb massive ausgeweitet.

Das Problem ist also auf jeden Fall bei der tempdb. Diese ist gerade auf 21 GB Buffer Cache hochgesprungen aber mir wird nocht nicht klar, warum.