morpheus2010
Goto Top

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.
ram

Content-Key: 4572133334

Url: https://administrator.de/contentid/4572133334

Printed on: April 28, 2024 at 13:04 o'clock

Member: LauneBaer
Solution LauneBaer Nov 10, 2022 at 08:20:59 (UTC)
Goto Top
Servus,

also schaden tut es sicherlich nicht, viel hilft viel. Aber der Takt deiner CPU ist arg niedrig, da würde ich mir mal die Energieeinstellungen anschauen. Server stelle ich persönlich immer auf das Profil "Höchstleistung".

Grüße
Member: VGem-e
VGem-e Nov 10, 2022 at 08:26:40 (UTC)
Goto Top
Moin,

@to: Einen SBS 2016 gibt es doch von MS nicht mehr?! Meinst Du einen Windows Server 2016 Essentials?

Gruß
Mitglied: 2423392070
2423392070 Nov 10, 2022 updated at 08:35:24 (UTC)
Goto Top
Ram des RAM wegens, ja schadet nicht.

Was genau dein Problem ist?
Member: OlliSe
OlliSe Nov 10, 2022 updated at 08:35:00 (UTC)
Goto Top
RAM ist durch nichts zu ersetzen, als durch RAM, 16GB ... nehm 64 und du hast genug face-wink kostet ja nicht die Welt face-wink

Läuft der schon mit SSD´s?

Das bringt dich nochmals nach vorne !
Member: ukulele-7
ukulele-7 Nov 10, 2022 at 08:40:48 (UTC)
Goto Top
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.
Member: erikro
Solution erikro Nov 10, 2022 at 11:58:54 (UTC)
Goto Top
Moin,

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.

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
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 07:49:51 (UTC)
Goto Top
@to: Einen SBS 2016 gibt es doch von MS nicht mehr?! Meinst Du einen Windows Server 2016 Essentials?

Sorry, ja genau den meine ich.
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 07:52:00 (UTC)
Goto Top
Zitat von @2423392070:
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.
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 07:57:19 (UTC)
Goto Top
Zitat von @erikro:

"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.


Hört sich vernünftig an. Dann werde ich das machen.
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 08:11:12 (UTC)
Goto Top
Zitat von @OlliSe:

RAM ist durch nichts zu ersetzen, als durch RAM, 16GB ... nehm 64 und du hast genug face-wink kostet ja nicht die Welt face-wink

Der ECC Server RAM geht dann doch schon bisschen ins Geld. Mainboard lässt leider auch nur 32GB zu.


Läuft der schon mit SSD´s?

Nein. Aber bei Fileservern auch ehr bisschen problematisch bzw. teuer.
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 08:11:54 (UTC)
Goto Top
Zitat von @LauneBaer:

also schaden tut es sicherlich nicht, viel hilft viel. Aber der Takt deiner CPU ist arg niedrig, da würde ich mir mal die Energieeinstellungen anschauen. Server stelle ich persönlich immer auf das Profil "Höchstleistung".

Super. Vielen Dank! Habe ich gleich geändert. Läuft jetzt mit 1333 MHz
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 08:16:15 (UTC)
Goto Top
Danke für die rege Beteiligung! Jetzt bin ich um einiges schlauer!
Mitglied: 2423392070
2423392070 Nov 11, 2022 at 10:43:56 (UTC)
Goto Top
Zitat von @morpheus2010:

Zitat von @2423392070:
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?
Member: erikro
erikro Nov 11, 2022 at 11:02:44 (UTC)
Goto Top
Moin,

Zitat von @2423392070:

Zitat von @morpheus2010:

Zitat von @2423392070:
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
Mitglied: 2423392070
2423392070 Nov 11, 2022 at 11:45:03 (UTC)
Goto Top
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.
Member: morpheus2010
morpheus2010 Nov 11, 2022 at 11:46:35 (UTC)
Goto Top
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?

VG
und schönes Wochenende
Member: CH3COOH
CH3COOH Nov 11, 2022 at 12:04:03 (UTC)
Goto Top
Mahlzeit,
aus meiner Sicht ist die CPU auch etwas schwach, wobei Sie ja scheinbar auch nicht gefordert wird.

Zitat von @morpheus2010:

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:


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ß
Member: Saftnase
Saftnase Nov 14, 2022 at 07:59:03 (UTC)
Goto Top
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.
Member: ukulele-7
ukulele-7 Nov 14, 2022 at 10:29:16 (UTC)
Goto Top
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.
Member: Saftnase
Saftnase Nov 14, 2022 at 11:00:53 (UTC)
Goto Top
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 !!!
Member: ukulele-7
ukulele-7 Nov 14, 2022 at 11:12:17 (UTC)
Goto Top
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.