Win11 ewige Baustelle

TErxleben

Distinguished Member
Oct 20, 2008
1,093
401
153
Hamburg
Windows Probleme kommen und gehen. So z.B. das keine Verbindungen zu Freigaben ständig nicht verfügbar sind kam irgendwann mit Win10 (oder gar Win7) und verschwanden mit Win11. Das in der Pipeline hängende Updates bis zum Neustart zu Zickereien führen, Schwamm drüber.

Nun quaken aber Win11-Kisten gerne über angeblichen Arbeitsspeichermangel(?).
Hat das jemand schon beobachtet und das Problem gelöst?
Oder verträgt dieses Möchtegern-OS die üblichen langen Laufzeiten einer VM tatsächlich einfach nicht?
 
Das OS klagt oder die User?

Bisher habe ich da noch nie Probleme gehabt. Setze aber zu 90% nur IoT LTSC ein, nicht den Prosumer-K*ck. Fraglich, was Du an Ressourcen zugewiesen hast und ob Ballooning genutzt wird.
 
Ballooning an? Das ist bei Win11 der Klassiker. Wenn min und max RAM unterschiedlich sind, zieht der Balloon-Treiber Speicher vom Gast ab und Windows meckert dann über Speichermangel, während im PVE-Graph alles fein aussieht. Bei Windows-Gästen fahr ich Ballooning grundsätzlich aus, min = max, dann ist Ruhe. Kostet halt Overcommit, aber der Ärger ist es mir nicht wert.

Falls Ballooning schon aus ist: meldet Windows generisch "wenig Arbeitsspeicher" oder ist es eine konkrete Anwendung? Bei Uptimes von Wochen würd ich mal mit poolmon oder RAMMap auf Nonpaged Pool und Handles schauen, das wächst gern durch irgendeinen Treiber langsam voll und ist nach nem Reboot wieder weg, klassisches Leak-Muster. Auslagerungsdatei auf Auto oder fix gesetzt?

Wieviel RAM hat die VM denn und welche virtio-Treiberversion ist drin?
 
Ballooning an? Das ist bei Win11 der Klassiker. Wenn min und max RAM unterschiedlich sind, zieht der Balloon-Treiber Speicher vom Gast ab und Windows meckert dann über Speichermangel, während im PVE-Graph alles fein aussieht. Bei Windows-Gästen fahr ich Ballooning grundsätzlich aus, min = max, dann ist Ruhe. Kostet halt Overcommit, aber der Ärger ist es mir nicht wert.

Falls Ballooning schon aus ist: meldet Windows generisch "wenig Arbeitsspeicher" oder ist es eine konkrete Anwendung? Bei Uptimes von Wochen würd ich mal mit poolmon oder RAMMap auf Nonpaged Pool und Handles schauen, das wächst gern durch irgendeinen Treiber langsam voll und ist nach nem Reboot wieder weg, klassisches Leak-Muster. Auslagerungsdatei auf Auto oder fix gesetzt?

Wieviel RAM hat die VM denn und welche virtio-Treiberversion ist drin?
Ist es nun ein reines Win-Problem oder der komplette quemu-Mechanismus, der für Probleme sorgt?
Die Kiste um es sich dreht hat 8/32-Ballooning. Der Host kann beides bedienen.
Würde 16/32 evtl. schon etwas verbessern?
 
Ich betreue nen Taxi-Unternehmer. Da haben wir vor 3 oder 4 Jahren 4 Lenovo Thinkcentre Mx angeschafft.
Reine Office-PCs.
War ein Angebot, Windows 11 pro mit "nur" 8 GB Ram.

Seit knapp 3-4 Monaten können alle 4 Mitarbeiter kaum noch anständig arbeiten (2 Standorte).
Und wir reden von Office (Outlook, Excel). Da wird fast nur getippt den ganzen Tag.

Ram von speicher.de auf 16GB aufgerüstet und die Kisten laufen wieder anständig...
 
Beides ein bisschen, aber der Auslöser ist der Mechanismus. Die VM startet mit den 32, und wenn der Host Druck macht, bläst der Balloon-Treiber im Gast auf und nimmt dir Speicher weg. Im Task-Manager stehen aber immer noch 32 GB total, die geklauten Seiten tauchen einfach als belegt auf. Linux-Gäste stecken das besser weg weil die schlicht Cache freigeben, Windows fängt an zu jammern.

16/32 verschiebt nur die Untergrenze, das Verhalten bleibt gleich. Ich würd bei der Kiste das Balloon-Device ganz rausnehmen (Häkchen weg, nicht nur min=max) und fix 16 oder 24 geben. Dafür siehst du im PVE-Graph dann nur noch das Zugewiesene, nicht den gastinternen Verbrauch, aber damit kann ich leben.

Was @kleinp mit den 8 GB beschreibt, ist wahrscheinlich genau dein Problem: dein min steht auf 8, und da landet die VM im Zweifel. Für ein aktuelles Win11 mit Office ist das heute einfach zu knapp. PVE bläst aber erst ab ~80% Host-RAM auf – läuft auf dem Host sonst noch was, das zeitweise ordentlich reinhaut?
 
ich bin immer davon ausgegangen, der Client startet mit dem Minimum und schnappt sich mehr sobald gebraucht. Sinkt der Verbrauch, wird Speicher wieder an den Host gegeben.

Es handelt sich um einen Datev-Server. Datev gibt 16GB schon als mittelhochtief an.

Die Sache passiert so selten, dass mir noch der Antrieb fehlt, den Holzhammer auszupacken und Ballooning abzuschalten. Selbst wenn Host es hergeben würde. Win "repariert", verschlimmbessert sich ja erratisch gerne.
 
Last edited:
Grundsätzlich sollte man die Resourcen bei VMs fest verplanen. Damit erspart man sich so einige Probleme. Irgendjemand muss ja entscheiden welcher Maschine etwas entzogen wird, und dann ist es garantiert aus Adminsicht die falsche!

Es gilt immer noch die Devise „Speicher ist durch nichts zu ersetzen, außer durch noch mehr Speicher“. Das wurste schon die alte Faxware unter Novell Netware 3.x.
 
  • Like
Reactions: Johannes S
Nun leben wir ja nicht im Lebkuchenland. Innerhalb einer Arbeitsstation addierst du ja nun auch nicht die Maximalverbräuche aller installierten SW auf um das RAM entsprechend zu kaufen. Das es Zeiten gab, in den RAM latent ein knappes Gut waren, ist auch klar.
Gerade auf einem VHost kann ich doch wunderbar planen, wann welche VM speicherintensive Tasks laufen lässt.
Mit 5 VMs, die geplant hohe Auslastungen erzeugen und sonst vor sich hin bummeln, kann ich einen VHost optimal ausnutzen.
 
Last edited:
Die Idee ist gut, wenn das Betriebssystem in der VM richtig spurt. Aber davon ist Windows schon sehr lange weg. Würde MS hier mal wieder mehr in Qualität statt Quantität stecken, dann könnte das was werden. Das Teil wird mit seinem Eigenleben immer unhandlicher und fetter. Aber cloud und KI werden das schon richten … lol
 
  • Like
Reactions: Johannes S
Windows, der Quell jeglicher Freude und Expierence.
Traurig aber wahr.
Ich hadere immer mehr mit dem Gedanken, wieder mal eine Extrawurst zu braten um Unzulänglichkeiten von Heckenpennern wegzubügeln. Lieber kommuniziere ich inzwischen immer mehr, wo das Problem zu verorten ist und welche zusätzliche Kosten daraus entstehen.
Steter Tropfen hölt den Stein.
 
Last edited:
Datev-Server ändert die Lage aber schon. Für virtualisierte Datev-Server will Datev meines Wissens fest zugewiesenen RAM, da funktioniert dynamische Speicherzuteilung nicht. Falls dir mal wirklich was um die Ohren fliegt und du beim Datev-Support landest, ist das erfahrungsgemäß der erste Punkt, auf den die zeigen. Deswegen würd ich bei genau der Kiste den Holzhammer auspacken, Häkchen beim Ballooning raus, fix 24 oder 32 rein, fertig. Mit nem Reboot im nächsten Wartungsfenster hast du das Thema für immer vom Tisch. Overcommit kannst du ja bei den unkritischen VMs weiterfahren.
 
  • Like
Reactions: ThoSo
Da sagt Datev gar nichts zu. Der Hypervisor ist denen egal. Da ich bewusst auf AD und Ätzgeraffel verzichte, handelt es sich bei dem (ptp)-Server auch nur um eine Win11-VM auf der halt ein MSSQL-Server läuft.
Mein Verdacht (Speicherleck) liegt z.Zt. auf der hohen Laufzeit der Server-VM. Ich werde weiter beobachten und beim nächsten Auftreten mal einen wöchentlichen Neustart erzwingen und dann wieder beobachten.
 
Also offiziell sind bei der DATEV die Hypervisor vSphere, HyperV und XenServer (https://wissensplattform.apps.datev.de/help/document/1080080)
Als "Server" listet DATEV ab Windows Server 2019 bis 2025 keine Workstation Versionen (Windows 10 / 11).

RAM mindestens 16GB (Geeignet bis 15 Benutzer- der Witz ist gut!) dann reden die im selben Dokument etwas darunter bei 6-8 Benutzer aber schon von 32GB RAM. Also 32 GB, - besser ist das. Das galt übrigens für "bis vor drei Jahren" - dann kommt schon zukunftssicher nebendran!
(https://wissensplattform.apps.datev.de/help/document/0908081#D549439155897175051)

Also ich würde dir ja empfehlen, bei kleinen Gruppen evtl. den Windows Server in der Essentials Variante (Preislich) zu Nutzen, statt Windows Prof 11.

Aber wenn es denn ein 11 sein muss, dann :
- hast du die Leistungseinstellungen im Windows umgestellt auf HIntergrunddienste?
- Auch sämtliche optischen Killefiz Einstellungen (auf optimale Leistung) würde ich rausnehmen - spart CPU, RAM, Grafik und sieht dann wenigsten aus wie ein Server OS.
- Ebenso die Einstellungen Datenübermittlung, Windows Updates cachen für andere rausnehmen.

Übrigens SQL Server von MS mögen Speicher!
Wenn die Maschine anfängt auszulagern wird's genauso doof wie wenn es Linux wäre.
 
Last edited:
Also offiziell sind bei der DATEV die Hypervisor vSphere, HyperV und XenServer (https://wissensplattform.apps.datev.de/help/document/1080080)
Als "Server" listet DATEV ab Windows Server 2019 bis 2025 keine Workstation Versionen (Windows 10 / 11).

RAM mindestens 16GB (Geeignet bis 15 Benutzer- der Witz ist gut!) dann reden die im selben Dokument etwas darunter bei 6-8 Benutzer aber schon von 32GB RAM. Also 32 GB, - besser ist das. Das galt übrigens für "bis vor drei Jahren" - dann kommt schon zukunftssicher nebendran!
(https://wissensplattform.apps.datev.de/help/document/0908081#D549439155897175051)

Also ich würde dir ja empfehlen, bei kleinen Gruppen evtl. den Windows Server in der Essentials Variante (Preislich) zu Nutzen, statt Windows Prof 11.

Aber wenn es denn ein 11 sein muss, dann :
- hast du die Leistungseinstellungen im Windows umgestellt auf HIntergrunddienste?
- Auch sämtliche optischen Killefiz Einstellungen (auf optimale Leistung) würde ich rausnehmen - spart CPU, RAM, Grafik und sieht dann wenigsten aus wie ein Server OS.
- Ebenso die Einstellungen Datenübermittlung, Windows Updates cachen für andere rausnehmen.

Übrigens SQL Server von MS mögen Speicher!
Wenn die Maschine anfängt auszulagern wird's genauso doof wie wenn es Linux wäre.
Die Datev-"Wissensplattform" bereitet mir mit ihren Vorschlägen auch seit 30J viel Freude.
Im Leben werde ich von Win11 pro nicht weggehen. Alleine weil Datev in der kleinsten Darreichungsform von Einzelarbeitsplätzen ausgeht. Das nun bummelige meist 10 Clients an diesen Quasiservern (so heißen die ptp-Server im Datevjargon) hängen, spielt nun auch keine Rolle. Das MSSQL seinen Tribut fordert ist auch klar. Darum ja die 32GB max.
An den Win-Einstellungen "optimiere" ich nie. Ich habe ja auch kein Performanceproblem. Wie ich schrieb habe ich Geduld und werde mich ranrobben.
 
MSSQL auf der Kiste macht den Leck-Verdacht erstmal unwahrscheinlich. Der Buffer Pool ist per Default unbegrenzt und zieht sich alles was da ist, gibt ihn aber kaum wieder her. Von außen sieht das exakt aus wie ein langsames Leak: nach Tagen ist der RAM voll, nach dem Reboot wieder frei, und der wöchentliche Neustart "hilft" dann auch brav. Schau mal was SELECT value_in_use FROM sys.configurations WHERE name = 'max server memory (MB)' ausspuckt. Steht da 2147483647, hat das noch nie jemand angefasst. Ich lass bei so Quasiservern grob 6 bis 8 GB für Windows übrig und deckel den Rest, danach ist meist Ruhe.

Mit dem Balloon wirds dann richtig eklig, weil sich SQL den Speicher nimmt und der Balloon ihn gleichzeitig wieder rausziehen will. Beobachten ist ok, aber schau dir den einen Wert vorher an, sonst beobachtest du am Ende nur, wie MSSQL seinen Job macht.
 
MSSQL auf der Kiste macht den Leck-Verdacht erstmal unwahrscheinlich. Der Buffer Pool ist per Default unbegrenzt und zieht sich alles was da ist, gibt ihn aber kaum wieder her. Von außen sieht das exakt aus wie ein langsames Leak: nach Tagen ist der RAM voll, nach dem Reboot wieder frei, und der wöchentliche Neustart "hilft" dann auch brav.
Wenn ich mir die RAM-Auslastung im PVE-Host ansehe, dann sehe ich durchaus 32GB-Peaks. Allerdings sinken die erwartungsgemäß auch wieder auf 12GB.
Mit dem Balloon wirds dann richtig eklig, weil sich SQL den Speicher nimmt und der Balloon ihn gleichzeitig wieder rausziehen will.
An solche Kollisionen kann ich nicht richtig glauben. Belegter Speicher ist belegter Speicher. Da entzieht Ballooning nichts.
Ist auch eher akademischer Natur. Die Ereignisse und Meldungen in Windows sind so beschissenes BlaBla, das man den Grund maschinenintern einfach nicht feststellen kann. Hilft nur Indianertaktik gepaart mit Geduld.
 

Attachments

  • Bildschirmfoto_20260905_190108.png
    Bildschirmfoto_20260905_190108.png
    75.8 KB · Views: 2
Last edited:
Die anderen Infos im Graphen wie zB. Host Memory Usage wären vielleicht interressant gewesen.
 
Last edited:
Die anderen Infos mm Graphen wie zB. Host Memory Usage wären vielleicht interressant gewesen.
Eher langweilig...
P.S.: Was auf dem Host sonst läuft, siehe ebenfalls Anhang.
 

Attachments

  • Bildschirmfoto_20260905_194459-1.png
    Bildschirmfoto_20260905_194459-1.png
    85.8 KB · Views: 3
  • Bildschirmfoto_20260905_195743.png
    Bildschirmfoto_20260905_195743.png
    73 KB · Views: 3
Last edited: