1
Windows 2016 nimmt wenig RAM zum Cachen
Hallo!
Ich habe hier einen Windows 2016 Cluster mit Storage-Spaces (ohne direct) als shared Storage.
Was mich wunder ist, dass das System einfach nicht das RAM nutzt, das es nutzen könnte. In beiden Knoten sind je 96GB RAM.
Beim primären Knoten sind aktuell nur 46 GB genutzt und nur 10,9 GB "im Cache". Wenn ich Daten vom Storage lese, füllt sich kurzzeitig der Cache, aber wird dann wieder freigegeben, obwohl dafür gar keine Not ist.
Habt ihr eine Idee, warum nicht ein größerer Teil des ungenutzten Speichers als Cache genutzt wird?
Kennt ihr eine Möglichkeit, das Verhalten zu ändern?
Windows 2019 scheint das anders zu machen. Hier sehe ich auf meinen Beispielsystemen deutlich mehr "Cache-Nutzung".
Danke und Grüße
Phil
Ich habe hier einen Windows 2016 Cluster mit Storage-Spaces (ohne direct) als shared Storage.
Was mich wunder ist, dass das System einfach nicht das RAM nutzt, das es nutzen könnte. In beiden Knoten sind je 96GB RAM.
Beim primären Knoten sind aktuell nur 46 GB genutzt und nur 10,9 GB "im Cache". Wenn ich Daten vom Storage lese, füllt sich kurzzeitig der Cache, aber wird dann wieder freigegeben, obwohl dafür gar keine Not ist.
Habt ihr eine Idee, warum nicht ein größerer Teil des ungenutzten Speichers als Cache genutzt wird?
Kennt ihr eine Möglichkeit, das Verhalten zu ändern?
Windows 2019 scheint das anders zu machen. Hier sehe ich auf meinen Beispielsystemen deutlich mehr "Cache-Nutzung".
Danke und Grüße
Phil
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1126091764
Url: https://administrator.de/contentid/1126091764
Printed on: April 23, 2024 at 08:04 o'clock
1 Comment
Denk mal daran, daß die Clients ja auch ein Filesytemcache im RAM betreiben. Sprich eine LEsenaforderung an dieselbe Datei wird nur einmal am Storage Server sichtbar, und wenn der nur das im Cache hält, was häufig gelesen wrid, dann hat man vermuztlich schon die Ursache identifiziert.
