Mehr RAM sinnvoll? Windows Server 2016 SBS
Hallo zusammen,
ich betreibe einen kleinen Dell Server mit MS Server 2016 SBS (EDIT: Ist MS 2016 Essentials). Habe ca. 7 Workstations die auf ein paar Dateien aber hauptsächlich auf eine POSTGRES Datenbank/Software zugreifen.
Der Server hat 16GB RAM. Der RAM ist nie komplett voll. Meist min 2GB frei.
Sollte ich den RAM dennoch upgraden um eine bessere Performance zu erreichen?
Ein Systembetreuer meinte ich solle es machen aber ich denke solange ich da nicht am Limit bin wird das nichts bringen.
Anbei ein Screenshot wie es gerade aussieht (Alle Clients online)
Würde mich freuen wenn mir jemand helfen könnte.
ich betreibe einen kleinen Dell Server mit MS Server 2016 SBS (EDIT: Ist MS 2016 Essentials). Habe ca. 7 Workstations die auf ein paar Dateien aber hauptsächlich auf eine POSTGRES Datenbank/Software zugreifen.
Der Server hat 16GB RAM. Der RAM ist nie komplett voll. Meist min 2GB frei.
Sollte ich den RAM dennoch upgraden um eine bessere Performance zu erreichen?
Ein Systembetreuer meinte ich solle es machen aber ich denke solange ich da nicht am Limit bin wird das nichts bringen.
Anbei ein Screenshot wie es gerade aussieht (Alle Clients online)
Würde mich freuen wenn mir jemand helfen könnte.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4572133334
Url: https://administrator.de/contentid/4572133334
Ausgedruckt am: 21.11.2024 um 21:11 Uhr
21 Kommentare
Neuester Kommentar
Ram des RAM wegens, ja schadet nicht.
Was genau dein Problem ist?
Was genau dein Problem ist?
Nagel mich jetzt nicht fest mit Windows und RAM Mamangement habe ich mich jetzt schon lange nicht mehr beschäftigt (weil mehr RAM einfacher ist) aber ich würde sagen bei 75% fängt Windows an so viel wie möglich zu swappen um Reserven zu haben. Wie jetzt in dem Screenshot die 19,8GB commited zustande kommen musst du mal nachlesen aber er dürfte mit Sicherheit die Auslagerungsdatei stärker nutzen als dir lieb sein kann.
Datenbanken verhalten sich übrigens auch so. Sie nie nutzen RAM nur wenn er da ist und i.d.R. auch nicht 100% sondern abzüglich Reserve. (Auch wenn du vermutlich jetzt nicht die Killer-Datenbank darauf fährst.)
Mit mehr RAM verfügbar wird also vermutlich auch mehr RAM genutzt.
Datenbanken verhalten sich übrigens auch so. Sie nie nutzen RAM nur wenn er da ist und i.d.R. auch nicht 100% sondern abzüglich Reserve. (Auch wenn du vermutlich jetzt nicht die Killer-Datenbank darauf fährst.)
Mit mehr RAM verfügbar wird also vermutlich auch mehr RAM genutzt.
Moin,
Ja, das wird die Performance verbessern. Datenbanken verhalten sich in der Regel so:
"Da ist RAM? Her damit! Kann ich vielleicht mal brauchen." Ein wenig technischer ausgedrückt heißt das, dass sich eine DB möglichst viel RAM reserviert, um dort alles Mögliche zu cachen. Richtig schnell wird es, wenn man so viel RAM hat, dass die gesamten Tabellen ins RAM geladen werden können. Daher ist es auf einem DB-Server vollkommen normal, dass die Auslastung einen geraden Strich bildet, wie in Deinem Screenshot zu sehen ist. Wenn Du jetzt 32GB reinstopfst, dann wird der Strich sich wahrscheinlich bei 30GB einpendeln.
hth
Erik
Zitat von @morpheus2010:
ich betreibe einen kleinen Dell Server mit MS Server 2016 SBS. Habe ca. 7 Workstations die auf ein paar Dateien aber hauptsächlich auf eine POSTGRES Datenbank/Software zugreifen.
Der Server hat 16GB RAM. Der RAM ist nie komplett voll. Meist min 2GB frei.
Sollte ich den RAM dennoch upgraden um eine bessere Performance zu erreichen?
Ein Systembetreuer meinte ich solle es machen aber ich denke solange ich da nicht am Limit bin wird das nichts bringen.
ich betreibe einen kleinen Dell Server mit MS Server 2016 SBS. Habe ca. 7 Workstations die auf ein paar Dateien aber hauptsächlich auf eine POSTGRES Datenbank/Software zugreifen.
Der Server hat 16GB RAM. Der RAM ist nie komplett voll. Meist min 2GB frei.
Sollte ich den RAM dennoch upgraden um eine bessere Performance zu erreichen?
Ein Systembetreuer meinte ich solle es machen aber ich denke solange ich da nicht am Limit bin wird das nichts bringen.
Ja, das wird die Performance verbessern. Datenbanken verhalten sich in der Regel so:
"Da ist RAM? Her damit! Kann ich vielleicht mal brauchen." Ein wenig technischer ausgedrückt heißt das, dass sich eine DB möglichst viel RAM reserviert, um dort alles Mögliche zu cachen. Richtig schnell wird es, wenn man so viel RAM hat, dass die gesamten Tabellen ins RAM geladen werden können. Daher ist es auf einem DB-Server vollkommen normal, dass die Auslastung einen geraden Strich bildet, wie in Deinem Screenshot zu sehen ist. Wenn Du jetzt 32GB reinstopfst, dann wird der Strich sich wahrscheinlich bei 30GB einpendeln.
hth
Erik
Zitat von @morpheus2010:
Meine Branchensoftware welche auf das Postgres zugreift ist sehr langsam.
Softwarehersteller mein mein Netzwerk wäre schnell und der Server auch gut. Nur man könnt ggf. RAM aufstocken.
Weiß nicht wo der Bottleneck ist. Habe die Branchensoftware selber in Verdacht. Ist mit jedem Update langsamer geworden.
Zitat von @2423392070:
Was genau dein Problem ist?
Was genau dein Problem ist?
Meine Branchensoftware welche auf das Postgres zugreift ist sehr langsam.
Softwarehersteller mein mein Netzwerk wäre schnell und der Server auch gut. Nur man könnt ggf. RAM aufstocken.
Weiß nicht wo der Bottleneck ist. Habe die Branchensoftware selber in Verdacht. Ist mit jedem Update langsamer geworden.
Würde die Software denn mit mehr RAM skalieren was die Geschwindigkeit angeht?
Moin,
Na wenn der Hersteller der SW das empfiehlt ...
Erfahrungsgemäß wird eine DB mit mehr RAM schneller. Wenn die SW mit der Zeit immer langsamer geworden ist, kann das zwei Ursachen haben: Neue Features und/oder größere Datenmengen. Letzteres ist ja ein Phänomen, das bei der Nutzung der DB immer auftritt.
Ein weiterer Tipp: Reindizieren und komprimieren der DB. Das hilft immer, wenn eine DB längere Zeit benutzt wurde und dadurch langsamer wird.
Liebe Grüße
Erik
Zitat von @2423392070:
Würde die Software denn mit mehr RAM skalieren was die Geschwindigkeit angeht?
Zitat von @morpheus2010:
Meine Branchensoftware welche auf das Postgres zugreift ist sehr langsam.
Softwarehersteller mein mein Netzwerk wäre schnell und der Server auch gut. Nur man könnt ggf. RAM aufstocken.
Weiß nicht wo der Bottleneck ist. Habe die Branchensoftware selber in Verdacht. Ist mit jedem Update langsamer geworden.
Zitat von @2423392070:
Was genau dein Problem ist?
Was genau dein Problem ist?
Meine Branchensoftware welche auf das Postgres zugreift ist sehr langsam.
Softwarehersteller mein mein Netzwerk wäre schnell und der Server auch gut. Nur man könnt ggf. RAM aufstocken.
Weiß nicht wo der Bottleneck ist. Habe die Branchensoftware selber in Verdacht. Ist mit jedem Update langsamer geworden.
Würde die Software denn mit mehr RAM skalieren was die Geschwindigkeit angeht?
Na wenn der Hersteller der SW das empfiehlt ...
Erfahrungsgemäß wird eine DB mit mehr RAM schneller. Wenn die SW mit der Zeit immer langsamer geworden ist, kann das zwei Ursachen haben: Neue Features und/oder größere Datenmengen. Letzteres ist ja ein Phänomen, das bei der Nutzung der DB immer auftritt.
Ein weiterer Tipp: Reindizieren und komprimieren der DB. Das hilft immer, wenn eine DB längere Zeit benutzt wurde und dadurch langsamer wird.
Liebe Grüße
Erik
Wenn die Datenbank nichts zu tun hat, dann wird sie entsprechende Parameter gesetzt, auch den zusätzlichen RAM konsumieren ohne schneller zu werden. Ob das so ist und was genau die Stellschraube wäre zum Tuning könnte der Hersteller am besten beantworten.
Mahlzeit,
aus meiner Sicht ist die CPU auch etwas schwach, wobei Sie ja scheinbar auch nicht gefordert wird.
Der Support der Branchensoftware hilft dir da bestimmt / hoffentlich.
Du kannst ja auch "nur" die Datenbank selbst auf ein anderes Speichermedium schieben. Die SSD bringt schon einen ziemlich "kick" in das System.
Gruß
aus meiner Sicht ist die CPU auch etwas schwach, wobei Sie ja scheinbar auch nicht gefordert wird.
Zitat von @morpheus2010:
Sollte das die Branchensoftware nicht selber manchmal machen?
Wie kann man das anstoßen bei Postgres?
Zitat von @erikro:
Ein weiterer Tipp: Reindizieren und komprimieren der DB. Das hilft immer, wenn eine DB längere Zeit benutzt wurde und dadurch langsamer wird.
Sollte das die Branchensoftware nicht selber manchmal machen?
Wie kann man das anstoßen bei Postgres?
Der Support der Branchensoftware hilft dir da bestimmt / hoffentlich.
Zitat von @morpheus2010:
Nein. Aber bei Fileservern auch ehr bisschen problematisch bzw. teuer.
Läuft der schon mit SSD´s?
Nein. Aber bei Fileservern auch ehr bisschen problematisch bzw. teuer.
Du kannst ja auch "nur" die Datenbank selbst auf ein anderes Speichermedium schieben. Die SSD bringt schon einen ziemlich "kick" in das System.
Gruß
Moin,
die Aussage kenne ich. Unsere Software ist so langsam weil euer SQL Serverhardware zu langsam ist.
Das ist meistens schwachsinn und lässt sich durch das Monitoring der Auslastung CPU,RAM,Netzwerk, Festplatte über den Tag ziemlich gut einschätzen.
Schaut euch lieber mal die SQL Statements an die abgesetzt werden und fangt da an zu optimieren.
Viele "Programmierer" haben keine Ahnung wie eine performante SQL Abfrage gebaut wird.
Eine SQL Analyse des Ausführungsplan zeigt euch wo die langsamen Abfragen sind. (Meistens die mit vielen Outer Joins) Das ist so als würdest du am Samstag mit dem 40 Tonner zu Aldi fahren, den ganzen Markt einladen nach Hause karren und dir daheim dann 3 Brothen einen Salatkopf und eine Flasche Wein rausnehmen. Der Rest geht dann wieder zurück zu Aldi. So eine Abfrage kannst du auch mit 200 PB RAM nicht schneller bekommen.
die Aussage kenne ich. Unsere Software ist so langsam weil euer SQL Serverhardware zu langsam ist.
Das ist meistens schwachsinn und lässt sich durch das Monitoring der Auslastung CPU,RAM,Netzwerk, Festplatte über den Tag ziemlich gut einschätzen.
Schaut euch lieber mal die SQL Statements an die abgesetzt werden und fangt da an zu optimieren.
Viele "Programmierer" haben keine Ahnung wie eine performante SQL Abfrage gebaut wird.
Eine SQL Analyse des Ausführungsplan zeigt euch wo die langsamen Abfragen sind. (Meistens die mit vielen Outer Joins) Das ist so als würdest du am Samstag mit dem 40 Tonner zu Aldi fahren, den ganzen Markt einladen nach Hause karren und dir daheim dann 3 Brothen einen Salatkopf und eine Flasche Wein rausnehmen. Der Rest geht dann wieder zurück zu Aldi. So eine Abfrage kannst du auch mit 200 PB RAM nicht schneller bekommen.
Das kann man alles machen aber in erster Linie ist ja der Hersteller der Software verantwortlich und sollte das im Blick haben, das ist nicht Sache des Kunden. Auf eigene Faust eingreifen und irgendwelchen SQL Code optimieren sollte der Kunde auch nicht machen, das kann eigentlich nur scheitern wenn man nicht grade eine eigene Entwicklungsabteilung betreibt oder die Software selber pflegt.
Auch sind die Optimierungsmöglichkeiten meist gar nicht so groß, das soll mal schön der Hersteller entscheiden.
Auf der anderen Seite kann man vom Kunden schon erwarten ein paar mehr GB RAM zu spendieren. 16GB RAM kosten auf jeden Fall deutlich weniger als der Aufwand die SQL Querys zu analysieren.
Auch sind die Optimierungsmöglichkeiten meist gar nicht so groß, das soll mal schön der Hersteller entscheiden.
Auf der anderen Seite kann man vom Kunden schon erwarten ein paar mehr GB RAM zu spendieren. 16GB RAM kosten auf jeden Fall deutlich weniger als der Aufwand die SQL Querys zu analysieren.
Wir standen vor 15 Jahren vor dem selben Problem und waren mit dem Vorwurf des Softwarehauses wegen unzureichender Hardware konfrontiert. Eine Anzeige der Stammdatenseite eines Debitors dauerte bis zu 30 Minuten.
Die Hardware wurde entsprechend der Vorgaben des Softwarehauses massiv aufgerüstet und die Debitorenseite war schon nach 25 Minuten da.
Anschliessend haben wir einen SQL Spezialisten engagiert der sich den SQL Code der Abfrage angeschaut hat und den Tränen nahe war (vor Lachen). Er hat aus der Abfrage 2 Befehle entfernt und die Debitorenseite was in 15 Sekunden am Bildschirm.
Der Erfolg war dass das Softwarehaus die Kosten für die Aufrüstung und den Einsatz den SQL Profis übernehmen musste und den Programmierer entlassen hat. Alle anderen Programmierer bekamen dann eine Schulung !!!
Die Hardware wurde entsprechend der Vorgaben des Softwarehauses massiv aufgerüstet und die Debitorenseite war schon nach 25 Minuten da.
Anschliessend haben wir einen SQL Spezialisten engagiert der sich den SQL Code der Abfrage angeschaut hat und den Tränen nahe war (vor Lachen). Er hat aus der Abfrage 2 Befehle entfernt und die Debitorenseite was in 15 Sekunden am Bildschirm.
Der Erfolg war dass das Softwarehaus die Kosten für die Aufrüstung und den Einsatz den SQL Profis übernehmen musste und den Programmierer entlassen hat. Alle anderen Programmierer bekamen dann eine Schulung !!!
Ja das ist natürlich ein ideales Szenario.
Meist dürfte das aber nicht so eindeutig sein und meist ist es auch nicht unbedingt ein Fehler oder suboptimaler Code sondern eben irgendeine Funktionalität die man eventuell gar nicht nutzt aber die die Software erwartet. Auch reagiert nicht jedes Software Haus auf diese Weise, theoretisch könnten die auch Anwälte bemühen und Vorwüfe erheben, gerechtfertigt oder nicht.
Es ist erstmal recht günstig und mit Sicherheit sinnvoll hier einfach ein bisschen RAM nach zu legen. Wenn das nicht reicht und sich ein Performance Problem in einer Software abzeichnet dann muss man sich die Software angucken.
Meist dürfte das aber nicht so eindeutig sein und meist ist es auch nicht unbedingt ein Fehler oder suboptimaler Code sondern eben irgendeine Funktionalität die man eventuell gar nicht nutzt aber die die Software erwartet. Auch reagiert nicht jedes Software Haus auf diese Weise, theoretisch könnten die auch Anwälte bemühen und Vorwüfe erheben, gerechtfertigt oder nicht.
Es ist erstmal recht günstig und mit Sicherheit sinnvoll hier einfach ein bisschen RAM nach zu legen. Wenn das nicht reicht und sich ein Performance Problem in einer Software abzeichnet dann muss man sich die Software angucken.