Neu JTL Wawi optimieren

[gnarx]

Wir haben jetzt einen neuen JTL Server mit Win Server 2019 und SQL 2016.
RAM 128 GB und 2 CPU`s mit jeweils 6 Kernen und nochmal 6 Hyperthreading Kernen.

1. Was gebe ich nun für eine RAM Größe an?
"Begrenzt den Arbeitsspeicher auf 80 Prozent des tatsächlich vorhandenen Arbeitsspeichers. So bleiben dem Betriebssystem genug Ressourcen, so dass hierdurch keine Performance-Einbußen entstehen. Laufen weitere Anwendungen auf dem Rechner, ist eine stärkere Einschränkung auf 60 bis 70 Prozent angebracht. "

2. Wieviele Kerne gebe ich an?
"Begrenzt die maximale Anzahl an parallel arbeitenden CPUs. Nutzt ihr mehr als 4, raten wir zu der Variante „Hälfte der Menge an CPUs -1“. Wer also 8 CPUs im Einsatz hat, sollte maximal 3 parallel nutzen. Für 4 und weniger CPUs ist der parallele Einsatz von 2 Kernen ideal. Keine Sorge, der Rest eurer Prozessoren bleibt derweil nicht untätig. Ihr legt mit dieser Definition lediglich die Menge der CPU-Kerne fest, die gleichzeitig an derselben Abfrage arbeiten. So bleibt euren Prozessoren genug Leistung, um neben großen Datenbankabfragen für mehr als einen Prozessor auch weiterhin andere Aufgaben und Abfragen mit der restlichen Kapazität zu bearbeiten. "

3. Unsere Datenbank ist über 10 GB gross, was soll ich da nun als Anfangsgöße angeben? Also wenn sie 12 GB groß ist gleich 15GB angeben?

 

[Rico Giesler]

Du hast dir die Fragen eigentlich schon selbst beantwortet.
1. 60-70 Prozent wären 75-90 GB. Bei 80 Prozent sind es 100 GB. Mit 90 GB seit ihr also auf der sicheren Seite
2. Da ihr 2 CPUs habt mit jeweils 6 Kernen solltet ihr die Parallelität auf 2 stellen
3. Du kannst hier auch mehr als Startgröße angeben. Vorteil ist, dass SQL dann die Erweiterung erst später vornehmen muss. Hast du also für die DB eine 128er Platte kannst du getrost 50 oder 60 GB eintragen. Diese werden dann einfach "vorreserviert" und somit entfällt eine Vergrößerung während des laufenden Betriebes.

 

[css-umsetzung]

3. Du kannst hier auch mehr als Startgröße angeben. Vorteil ist, dass SQL dann die Erweiterung erst später vornehmen muss. Hast du also für die DB eine 128er Platte kannst du getrost 50 oder 60 GB eintragen. Diese werden dann einfach "vorreserviert" und somit entfällt eine Vergrößerung während des laufenden Betriebes.

Hier kommt eine Frage auf die ich mir schon ewig stelle.
Warum soll ich meine Datenbank auf z.B. 60G setzen wenn ich aktuell nur 12 benötige, denn wenn ich das so mache muss ich bei jeder Sicherung (die ja hoffentlich gemacht wird) 60G wegsichern was den Rechner ja auch gut belasten wird.

Ich würde meine Datenbank immer um 1G vergrößern lassen, denn es ist ja nicht so das die Datenbank nun mehrfach am Tag 1G hinzufügen muss,
denn das wird ja vermutlich wenn ständig mehr Artikel hinzukommen einmal pro Woche passieren oder nur einmal am Tag.

Warum also gleich mit einer so überdimensionierten Datenbank starten?

 

[Rico Giesler]

Wenn ich recht informiert bin wird nur die tatsächliche Größe der DB gesichert. Die voreingestellte Größe dient nur als Reservierung für den Platz um unnötige Vergrößerungen zu umgehen.

 

[MartinK]

Hier kommt eine Frage auf die ich mir schon ewig stelle.
Warum soll ich meine Datenbank auf z.B. 60G setzen wenn ich aktuell nur 12 benötige, denn wenn ich das so mache muss ich bei jeder Sicherung (die ja hoffentlich gemacht wird) 60G wegsichern was den Rechner ja auch gut belasten wird.

Ich würde meine Datenbank immer um 1G vergrößern lassen, denn es ist ja nicht so das die Datenbank nun mehrfach am Tag 1G hinzufügen muss,
denn das wird ja vermutlich wenn ständig mehr Artikel hinzukommen einmal pro Woche passieren oder nur einmal am Tag.

Warum also gleich mit einer so überdimensionierten Datenbank starten?

Bei der Sicherung wird nur der tatsächlich belegte Speicher für das Backup benötigt. Ein Wachstum von 1GB kann eine Datenbank je nachdem was gerade am Server schon los ist durchaus auch mal für ein paar Minuten komplett lahm legen, wenn es blöd läuft und ggf. zu Verbindungsabbrüchen führen. Deswegen sollte man - wenn man einfach die Möglichkeit hat - ein Wachstum der Datenbank möglichst vermeiden. Zusätzlich führt Wachstum einer DB zur Fragmentierung der Daten innerhalb der DB und zieht damit insgesamt die Performance runter.

 

[css-umsetzung]

Bei der Sicherung wird nur der tatsächlich belegte Speicher für das Backup benötigt. Ein Wachstum von 1GB kann eine Datenbank je nachdem was gerade am Server schon los ist durchaus auch mal für ein paar min komplett lahm legen, wenn es blöd läuft und ggf. zu Verbindungsabbrüchen führen. Deswegen sollte man - wenn man einfach die Möglichkeit hat - ein Wachstum der Datenbank möglichst vermeiden. Zusätzlich führt Wachstum einer DB zur Fragmentierung der Daten innerhalb der DB und zieht damit insgesamt die Performance runter.

Danke @MartinK für die Info, dann muss man sich da also keine Sorgen machen.