Windows 11 - Unerträgliche Ressourcenverschwendung - groteske RAM Reservierungen
Moin Zusammen,
ich habe in dem folgenden Beitrag …
Windows 11 - Unerträgliche Ressourcenverschwendung
… ja schon geschrieben, dass ich das Ressourcen-Handling eines aktuellen Windows 11 mehr als bedenklich empfinde und nun habe ich auch den eindeutigen Beweis gefunden, dass bedenklich in dem Fall eher noch eine Untertreibung ist. 😔
Deshalb habe ich nun auch beschlossen, diesem neusten und im wahrsten Sinne Horror-Fund, einen eigenen Beitrag, sprich, diesen zu widmen.
Und gleich im Vorfeld, wer sich die Osterfeiertage nicht versauen möchte, sollte diesen Beitrag erst danach lesen.
So, nun aber alles der Reihe/Ruhe nach. 🙃
Die Sache mit meiner ständig langsam werdenden Workstation hat mit einfach keine Ruhe gelassen und so habe ich heute, wären sich meine beiden Hausdrachen (Frau/Tochter) mit unseren beiden jungen Katern auf dem Sofa mal austoben mal ausruhten, mir den Windows 11 Murks nochmals genauer angesehen.
Mitunter habe ich mir die laufenden Prozesse auch mit dem „Process Explorer“ mal genauer angesehen und als ich bei diesem …

… noch die „Virtual Size“ einblenden liess und anschliessend den Wert einiger Prozesse sah, dachte ich zuerst, oh … das ist jetzt aber ein netter Oster-BUG, denn das was mir der „Process Explorer“ da darstellte, konnte ich schlichtweg nicht glauben. 🙃
Bevor ich jetzt jedoch verrate, was meine 🦊-👀 zu sehen bekommen haben, möchte ich im Vorfeld die entsprechenden Grundlagen dazu mal zumindest grob durchgehen.
Und zwar wird unter „Virtual Size“ eines Prozesses dargestellt, wieviel RAM dieser aktuell bei der Memory-Verwaltung von dem entsprechenden Windows reserviert hat. Hierbei ist jedoch zu beachten, dass reservierter RAM nicht gleich auch belegter RAM ist … zum Glück.
Des Weiteren sollte man noch beachten/wissen, dass ein aktuelles Windows in Summe maximal 256TB an Virtualem Memory adressieren/verwalten kann.
Nun wird sich der eine oder andere Denken, warum spricht dieser 🦊 von solchen Limits, die für so gut wie alle Normalsterbliche vollkommen irrelevant sind.
Ähm, ja, im Normallfall würde ich hier auch zustimmen … aber, das sieht insbesondere Microsoft wohl etwas anders. 😔
Denn, nachdem ich den „Process Explorer“ auch die „Virtual Size“, sprich, die grösse der RAM-Reservierung der Prozesse anzeigen liess, habe ich das folgende zu sehen bekommen …
… und zwar einen Haufen msedge.exe Prozesse, von denen jeder eine RAM-Reservierung von ~ 1.500.000.000K, sprich, !!! ~1,5 TByte !!! hatte. 😱
Natürlich habe ich zuerst gedacht, das kann doch nicht wirklich so sein, die Redmond-Microsoftianer werden doch mittlerweile nicht wirklich so bescheuert geworden sein und habe deshalb das Ganze nochmal per Power-Shell abgefragt …
… und habe auch hier …
(Werte sind in Bytes)
… genau denselben Horror zum sehen bekommen. 😭
Dann habe ich kurz das folgende Power-Shell Skript …
… erstellt, um zu sehen, wieviel Virtual Memory (RAM) bereits in Summe bei meinem System reserviert sind und habe nach dem Ausführen dieses, das folgende zum Sehen bekommen …
… und zwar, das in meiner Workstation bereits !!! 110,80 TB !!! RAM, durch meistens von Microsoft kommenden Prozessen reserviert sind. 🙈
Dabei habe ich gerade nur zwei Edge Browser, mit in Summe ~30 Tabs, Outlook und Word noch offen. 😔
Das erklärt nun auch, warum mein Rechner, vor allem bei noch mehr offenen Edge Tabs irgendwann mal anfängt lahm zu werden, denn mehr als 256TB RAM, kann ein aktuelles Windows leider nicht adressieren. 🙃
Gruss Alex
ich habe in dem folgenden Beitrag …
Windows 11 - Unerträgliche Ressourcenverschwendung
… ja schon geschrieben, dass ich das Ressourcen-Handling eines aktuellen Windows 11 mehr als bedenklich empfinde und nun habe ich auch den eindeutigen Beweis gefunden, dass bedenklich in dem Fall eher noch eine Untertreibung ist. 😔
Deshalb habe ich nun auch beschlossen, diesem neusten und im wahrsten Sinne Horror-Fund, einen eigenen Beitrag, sprich, diesen zu widmen.
Und gleich im Vorfeld, wer sich die Osterfeiertage nicht versauen möchte, sollte diesen Beitrag erst danach lesen.
So, nun aber alles der Reihe/Ruhe nach. 🙃
Die Sache mit meiner ständig langsam werdenden Workstation hat mit einfach keine Ruhe gelassen und so habe ich heute, wären sich meine beiden Hausdrachen (Frau/Tochter) mit unseren beiden jungen Katern auf dem Sofa mal austoben mal ausruhten, mir den Windows 11 Murks nochmals genauer angesehen.
Mitunter habe ich mir die laufenden Prozesse auch mit dem „Process Explorer“ mal genauer angesehen und als ich bei diesem …

… noch die „Virtual Size“ einblenden liess und anschliessend den Wert einiger Prozesse sah, dachte ich zuerst, oh … das ist jetzt aber ein netter Oster-BUG, denn das was mir der „Process Explorer“ da darstellte, konnte ich schlichtweg nicht glauben. 🙃
Bevor ich jetzt jedoch verrate, was meine 🦊-👀 zu sehen bekommen haben, möchte ich im Vorfeld die entsprechenden Grundlagen dazu mal zumindest grob durchgehen.
Und zwar wird unter „Virtual Size“ eines Prozesses dargestellt, wieviel RAM dieser aktuell bei der Memory-Verwaltung von dem entsprechenden Windows reserviert hat. Hierbei ist jedoch zu beachten, dass reservierter RAM nicht gleich auch belegter RAM ist … zum Glück.
Des Weiteren sollte man noch beachten/wissen, dass ein aktuelles Windows in Summe maximal 256TB an Virtualem Memory adressieren/verwalten kann.
Nun wird sich der eine oder andere Denken, warum spricht dieser 🦊 von solchen Limits, die für so gut wie alle Normalsterbliche vollkommen irrelevant sind.
Ähm, ja, im Normallfall würde ich hier auch zustimmen … aber, das sieht insbesondere Microsoft wohl etwas anders. 😔
Denn, nachdem ich den „Process Explorer“ auch die „Virtual Size“, sprich, die grösse der RAM-Reservierung der Prozesse anzeigen liess, habe ich das folgende zu sehen bekommen …
… und zwar einen Haufen msedge.exe Prozesse, von denen jeder eine RAM-Reservierung von ~ 1.500.000.000K, sprich, !!! ~1,5 TByte !!! hatte. 😱
Natürlich habe ich zuerst gedacht, das kann doch nicht wirklich so sein, die Redmond-Microsoftianer werden doch mittlerweile nicht wirklich so bescheuert geworden sein und habe deshalb das Ganze nochmal per Power-Shell abgefragt …
Get-Process -Name "msedge" | Select-Object Name, @{Name="WorkingSet";Expression={$_.WorkingSet64}}, @{Name="PageFileUsage";Expression={$_.PageFileUsage}}, VirtualMemorySize64
… und habe auch hier …
(Werte sind in Bytes)
… genau denselben Horror zum sehen bekommen. 😭
Dann habe ich kurz das folgende Power-Shell Skript …
# Virtual Memory Size aller Prozesse abfragen
$totalVirtualMemoryBytes = Get-Process | Measure-Object -Property VirtualMemorySize64 -Sum | Select-Object -ExpandProperty Sum
# Bytes in Terabyte umrechnen
$totalVirtualMemoryTB = $totalVirtualMemoryBytes / 1024 / 1024 / 1024 / 1024
# Ergebnis ausgeben
Write-Output ("Gesamte Virtual Memory Belegung aller Prozesse: {0:N2} TB" -f $totalVirtualMemoryTB)
… erstellt, um zu sehen, wieviel Virtual Memory (RAM) bereits in Summe bei meinem System reserviert sind und habe nach dem Ausführen dieses, das folgende zum Sehen bekommen …
… und zwar, das in meiner Workstation bereits !!! 110,80 TB !!! RAM, durch meistens von Microsoft kommenden Prozessen reserviert sind. 🙈
Dabei habe ich gerade nur zwei Edge Browser, mit in Summe ~30 Tabs, Outlook und Word noch offen. 😔
Das erklärt nun auch, warum mein Rechner, vor allem bei noch mehr offenen Edge Tabs irgendwann mal anfängt lahm zu werden, denn mehr als 256TB RAM, kann ein aktuelles Windows leider nicht adressieren. 🙃
Gruss Alex
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 672537
Url: https://administrator.de/forum/windows-11-unertraegliche-ressourcenverschwendung-groteske-ram-reservierungen-672537.html
Ausgedruckt am: 30.05.2025 um 05:05 Uhr
129 Kommentare
Neuester Kommentar
Denn, nachdem ich den „Process Explorer“ auch die „Virtual Size“, sprich, die grösse der RAM-Reservierung der Prozesse anzeigen liess, habe ich das folgende zu sehen bekommen …
Die virtual Size ist keine Reservierung sondern die Größe des virtuellen Addressraums, also die virtuellen Adressen, die ein Prozess nutzen kann. Dass der bei 64 Bit Prozessen so groß ist bzw. Sein kann, ist normal.
Des Weiteren sollte man noch beachten/wissen, dass ein aktuelles Windows in Summe maximal 256TB an Virtualem Memory adressieren/verwalten kann.
Das bezieht sich auf die max. Größe des Page Files (oder virtuellem Speicher) und hat nichts mit dem virtuellen Adressraum eines Prozesses zu tun.
https://stackoverflow.com/questions/27937099/what-can-be-the-maximum-siz ...
Gruß,
Avoton
Jeder Prozess erhält (sowohl auf Windows als auch auf Linux) seinen komplett unabhängigen virtuellen Arbeitsspeicher in der vollen festgelegten Größe (128 TB seit Windows 8.1), das ist völlig normal.
Wenn der 🦊mehr darüber erfahren will, bietet sich jedes beliebige Buch zu OS-Architektur, oder speziell zu Windows:
Windows Internals Part 1 und 2. Hier aus Part 1, Virtual Memory:
Wenn der 🦊mehr darüber erfahren will, bietet sich jedes beliebige Buch zu OS-Architektur, oder speziell zu Windows:
Windows Internals Part 1 und 2. Hier aus Part 1, Virtual Memory:
Virtual memory
Windows implements a virtual memory system based on a flat (linear) address space that provides each
process with the illusion of having its own large, private address space. Virtual memory provides a logical
view of memory that might not correspond to its physical layout. At run time, the memory manager—
with assistance from hardware—translates, or maps, the virtual addresses into physical addresses, where
the data is actually stored. By controlling the protection and mapping, the OS can ensure that individual
processes don’t bump into each other or overwrite OS data.
Windows implements a virtual memory system based on a flat (linear) address space that provides each
process with the illusion of having its own large, private address space. Virtual memory provides a logical
view of memory that might not correspond to its physical layout. At run time, the memory manager—
with assistance from hardware—translates, or maps, the virtual addresses into physical addresses, where
the data is actually stored. By controlling the protection and mapping, the OS can ensure that individual
processes don’t bump into each other or overwrite OS data.
Nachtrag speziell zu Edge:
die unterliegende V8 Javascript-Engine erstellt für jeden Prozess eine Sandbox mit einem virtuellen Adressbereich in der Größenordnung von 1 TB
https://github.com/v8/v8/blob/main/src/sandbox/GLOSSARY.md#sandbox
die unterliegende V8 Javascript-Engine erstellt für jeden Prozess eine Sandbox mit einem virtuellen Adressbereich in der Größenordnung von 1 TB
https://github.com/v8/v8/blob/main/src/sandbox/GLOSSARY.md#sandbox
Zitat von @MysticFoxDE:
Moin @CamelCase,
auch das ist nicht korrekt, zumindest, dass die 128TB per Default festgelegt werden.
Korrekter ist eher, dass seit Windows 8.1 oder Windows Server 2012 R2, jeder Prozess bis zu max. 128GB grossen Virtuellen Adressraum reservieren kann.
Gruss Alex
Moin @CamelCase,
Jeder Prozess erhält (sowohl auf Windows als auch auf Linux) seinen komplett unabhängigen virtuellen Arbeitsspeicher in der vollen festgelegten Größe (128 TB seit Windows 8.1), das ist völlig normal.
auch das ist nicht korrekt, zumindest, dass die 128TB per Default festgelegt werden.
Korrekter ist eher, dass seit Windows 8.1 oder Windows Server 2012 R2, jeder Prozess bis zu max. 128GB grossen Virtuellen Adressraum reservieren kann.
Gruss Alex
Ich habe es falsch erklärt, aber du hast es anscheinend verstanden 👍🏻
Tippfehler?
jeder Prozess bis zu max. 128 TB grossen Virtuellen Adressraum reservieren kann.
A 64-bit process on 64-bit Windows has a virtual address space within the 128-terabyte range 0x000'00000000 through 0x7FFF'FFFFFFFF.
https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarte ...
Und dass der Virtuelle Adressraum eines Windows auf max 256TB beschränkt ist, steht übrigens ebenfalls in der ersten Antworten des Beitrags auf den du selber verlinkst.
Steht es nicht. Der virtuelle Speicher ist auf diese Größe beschränkt. Das hat nichts, absolut gar nichts, mit der Größe des jeweiligen virtuellen Addressraums der Prozesse zu tun, wie @CamelCase auch dargelegt hat.
Wie dieser virtuelle Adressraum des Prozesses auf den Speicher (physisch oder virtuell) des Computers gemappt wird, ist wieder eine komplett eigene Geschichte.
Gruß,
Avoton
Bei mir sind es 2 - 3,5 TB; Ist aber auch kein Problem oder auch nur ein Anzeichen davon...
PS C:\Users\Thomas> get-process "msedge" | Select-Object Name,@{N="VM_TB";E={[math]::Round($_.VirtualMemorySize64 / 1TB, 2)}}
Name VM_TB
---- -----
msedge 3,42
msedge 3,42
msedge 3,42
msedge 2,07
msedge 3,42
msedge 2,1
msedge 3,42
msedge 2,1
msedge 2,1
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,43
msedge 3,42
msedge 3,42
msedge 3,42
msedge 2,1
msedge 3,42
msedge 3,42
msedge 2,1
msedge 3,42
msedge 3,42
msedge 3,42
msedge 2,16
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
msedge 3,42
Es kann dazu führen, aber rein die Tatsache, dass viel virtueller Speicher reserviert wird, führt nicht zu Performanceproblemen. Eher wie man mit dem Speicher selbst umgeht.. Die Copilot-Antwort ist ziemlicher Schrott...
Wie gesagt macht das die V8 JS-Engine, die in jedem Chrome-basierten Browser werkelt, in jedem Prozess wird eine Sandbox mit > 1 TB virtuellem Speicher erstellt.
Zurück zum Thema, du hast verstanden warum dein Eingangspost sinnfrei ist?
Wie gesagt macht das die V8 JS-Engine, die in jedem Chrome-basierten Browser werkelt, in jedem Prozess wird eine Sandbox mit > 1 TB virtuellem Speicher erstellt.
Zurück zum Thema, du hast verstanden warum dein Eingangspost sinnfrei ist?
Sprich, es geht definitiv auch anders, sprich definitiv auch viel sparsamer/effektiver.
Weniger virtuellen Speicher zu reservieren ist weder automatisch sparsamer noch effektiver, das Gegenteil kann der Fall sein, wenn man wiederholt Speicher nachallocaten muss, weil man zuwenig reserviert hat.
Die Größe des virtuellen Speichers ist für die Performance erstmal irrelevant. Es ist lediglich eine "Zahl auf dem Papier"
Und der Beweis, dass 100 TB genau so lange zum reservieren brauchen wie 100 MB
Code dafür
Wie gesagt, nur eine Zahl auf dem Papier 😉
Code dafür
#include <windows.h>
#include <stdio.h>
void measure_reserve(SIZE_T size, const char* label, LPVOID* out_ptr) {
LARGE_INTEGER freq, start, end;
QueryPerformanceFrequency(&freq);
QueryPerformanceCounter(&start);
LPVOID base = VirtualAlloc(NULL, size, MEM_RESERVE, PAGE_NOACCESS);
QueryPerformanceCounter(&end);
double ms = (end.QuadPart - start.QuadPart) * 1000.0 / freq.QuadPart;
printf("[+] %s reserved: %.3f ms at address: %p\n", label, ms, base);
*out_ptr = base;
}
int main() {
SIZE_T size_100mb = 100ULL * 1024 * 1024;
SIZE_T size_100tb = 100ULL * 1024 * 1024 * 1024 * 1024;
LPVOID mem_100mb = NULL;
LPVOID mem_100tb = NULL;
measure_reserve(size_100mb, "100 MB", &mem_100mb);
measure_reserve(size_100tb, "100 TB", &mem_100tb);
printf("\n[?] Enter to exit...\n");
getchar();
if (mem_100mb) VirtualFree(mem_100mb, 0, MEM_RELEASE);
if (mem_100tb) VirtualFree(mem_100tb, 0, MEM_RELEASE);
return 0;
}
Wie gesagt, nur eine Zahl auf dem Papier 😉
Die meinen mit "available" den nutzbaren Bereich des virtuellen Addressraums. Dass der nicht größer sein kann, als physischer Speicher plus Page Files / Swap Space ist ja klar, wo sollten die Daten dann hin?
Hindert den Prozess aber nicht daran, sich einen viel größeren Adressraum zu reservieren.
Nein, ich sehe nur, dass du über vor allem effektives Memory-Mamagement, noch einiges lernen musst.
Geil, selbst Unrecht haben und anderen sagen, sie hätten noch viel zu lernen...
Zitat von @MysticFoxDE:
Moin @CamelCase,
der virtuelle Adressraum eines Prozesses, kann am Ende des Tages nur auf den Physikalischen Adressraum, der bei mir lediglich 128GByte gross ist umgemapt werden oder im Notfall auf das PagingFile, welches gemäss Microsoft eigenen vorgaben, etwa die doppelte Grösse, sprich, in meinem Fall 256GByte haben sollte. Damit steht einem Prozess in Summe, real nur ein maximal nutzbarer Adressraum von 384TB zur Vefügung, welcher jedoch auch von anderen Prozessen verwendet wird.
Nun erklär mir mal bitte, aber so dass ich das auch verstehe, welchen Sinn es machen soll, bei einem Prozess per Default einen 1,5 TByte grossen Adressraum für den RAM zu reservieren, wenn tatsächlich nur ein Bruchteil davon wirklich belegt werden kann.
Moin @CamelCase,
Weniger virtuellen Speicher zu reservieren ist weder automatisch sparsamer noch effektiver, das Gegenteil kann der Fall sein, wenn man wiederholt Speicher nachallocaten muss, weil man zuwenig reserviert hat.
der virtuelle Adressraum eines Prozesses, kann am Ende des Tages nur auf den Physikalischen Adressraum, der bei mir lediglich 128GByte gross ist umgemapt werden oder im Notfall auf das PagingFile, welches gemäss Microsoft eigenen vorgaben, etwa die doppelte Grösse, sprich, in meinem Fall 256GByte haben sollte. Damit steht einem Prozess in Summe, real nur ein maximal nutzbarer Adressraum von 384TB zur Vefügung, welcher jedoch auch von anderen Prozessen verwendet wird.
Nun erklär mir mal bitte, aber so dass ich das auch verstehe, welchen Sinn es machen soll, bei einem Prozess per Default einen 1,5 TByte grossen Adressraum für den RAM zu reservieren, wenn tatsächlich nur ein Bruchteil davon wirklich belegt werden kann.
Kannst du dir im Designdokument von V8 durchlesen. Ist für die Eingangsfrage aber auch komplett irrelevant.
https://docs.google.com/document/d/1PM4Zqmlt8ac5O8UNQfY7fOsem-6MhbsB-vjF ...
Die Größe des virtuellen Speichers ist für die Performance erstmal irrelevant. Es ist lediglich eine "Zahl auf dem Papier"
Ist es eben nicht, denn je grösser der Adressraum eines Prozesses ist umso mehr Ressorcen verschlingt auch dessen Management. 😔
Gruss Alex
Nein, eben nicht. Die Größe alleine sagt gar nichts darüber aus, wie viele Ressourcen für die Verwaltung verwendet werden. Ein einziger 64 bit Pointer kann problemlos den ganzen Bereich adressieren, egal ob dieser 1 MB oder 100 TB groß ist.
Wenn ich natürlich die oben reservierten 100 TB vollschreibe, bekomme ich ein Problem. Aber reservieren und verwalten ist irrelevant.
Nun erklär mir mal bitte, aber so dass ich das auch verstehe, welchen Sinn es machen soll, bei einem Prozess per Default einen 1,5 TByte grossen Adressraum für den RAM zu reservieren, wenn tatsächlich nur ein Bruchteil davon wirklich belegt werden kann.
Hat er doch oben schon: Weil es aus Performance Sicht mehr Sinn macht, zu viel zu reservieren und nie zu belegen als mit ein paar MB anzufangen und dann immer nachallocaten zu müssen.
Gruß,
Avoton
OK und wohin sollen die Daten aus dem Prozess-Adressraum den hin gemapt werden? 🙃
Wer sagt denn, dass der ganze Bereich gemappt werden muss? Reservieren ist eine Sache, verwendet wird deutlich weniger. Schau dir mal das private working set an, dieses wird auch im Endeffekt auf deinen realen RAM gemappt.
Zitat von @MysticFoxDE:
Moin @CamelCase,
und welchen Sinn macht es einen Adressbereich zu reservieren, denn man so überhaupt nie wirklich mappen kann?
Moin @CamelCase,
Wer sagt denn, dass der ganze Bereich gemappt werden muss? Reservieren ist eine Sache, verwendet wird deutlich weniger.
und welchen Sinn macht es einen Adressbereich zu reservieren, denn man so überhaupt nie wirklich mappen kann?
Das vereinfacht manchmal die Programmlogik, wenn man direkt mit Adressen einfacher rechnen kann statt mehrfach umzurechnen.
lks
und welchen Sinn macht es einen Adressbereich zu reservieren, denn man so überhaupt nie wirklich mappen kann?
Zusätzlich zu @Lochkartenstanzer: Kann auch Sicherheitsvorteile haben, weil ein Angreifer dann nicht einfach Speicheradressen erraten kann.
Gruß,
Avoton
Moin,
Wenn es wirklich so wäre, wie konnte ich dann im obigen Beispiel 100 TB reservieren mit meinen lächerlichen 64 GB Arbeitsspeicher? Und das noch in den gleichen 3 Mikrosekunden wie 100 MB?
Nochmal, ganz wichtig: RAM reservieren ist nicht gleich RAM benutzen
Windows 11 - Unerträgliche Ressourcenverschwendung - groteske RAM Reservierungen
Zitat von @MysticFoxDE:
Sprich, je mehr RAM durch einen Prozess reserviert wird, umso grösser ist auch seine Page Table und zwar ganz unabhängig davon, wieviel RAM der Prozess dann tatsächlich benötigt und oder auch tatsächlich zugewiesen bekommen kann.
Sprich, je mehr RAM durch einen Prozess reserviert wird, umso grösser ist auch seine Page Table und zwar ganz unabhängig davon, wieviel RAM der Prozess dann tatsächlich benötigt und oder auch tatsächlich zugewiesen bekommen kann.
Wenn es wirklich so wäre, wie konnte ich dann im obigen Beispiel 100 TB reservieren mit meinen lächerlichen 64 GB Arbeitsspeicher? Und das noch in den gleichen 3 Mikrosekunden wie 100 MB?
Nochmal, ganz wichtig: RAM reservieren ist nicht gleich RAM benutzen
Windows 11 - Unerträgliche Ressourcenverschwendung - groteske RAM Reservierungen
Was gibt es überhaupt noch ohne Chromium?
Leider nicht mehr viel. Das ganze Web wird ja auch für Chromium optimiert inzwischen.
Dazu kommt dass Firefox hinterherhängt was Kompatibilität, Performance, und Features angeht, ich kann ihn nicht mehr benutzen. Ich wünsche mir sehr, dass Firefox wieder an Chromium rankommt, vor allem um Google ein bisschen Macht zu nehmen (Manifest v3 lässt grüßen), bis dahin verwende ich Edge...
Zitat von @MysticFoxDE:
Moin @CamelCase,
dann versuch doch mal die von dir Reservierten 100TB "Virtual Memory" auch mal mit Daten zu füllen, dann merkst du auch recht schnell selber, wie absolut sinnlos diese Reservierung ist. 😉
Sprich, du kannst natürlich gerne in einem Lokal was für maximal 64 Personen ausgelegt ist, versuchen ein Event für gleichzeitig 102.400 Personen zu buchen, ich fürchte jedoch, dass dir der entsprechende Lokalbesitzer, genau dasselbe erzählen wird, wie auch ich, sprich, dass das so überhaupt keinen Sinn macht. 🙃
Gruss Alex
Moin @CamelCase,
Wenn es wirklich so wäre, wie konnte ich dann im obigen Beispiel 100 TB reservieren mit meinen lächerlichen 64 GB Arbeitsspeicher? Und das noch in den gleichen 3 Mikrosekunden wie 100 MB?
dann versuch doch mal die von dir Reservierten 100TB "Virtual Memory" auch mal mit Daten zu füllen, dann merkst du auch recht schnell selber, wie absolut sinnlos diese Reservierung ist. 😉
Sprich, du kannst natürlich gerne in einem Lokal was für maximal 64 Personen ausgelegt ist, versuchen ein Event für gleichzeitig 102.400 Personen zu buchen, ich fürchte jedoch, dass dir der entsprechende Lokalbesitzer, genau dasselbe erzählen wird, wie auch ich, sprich, dass das so überhaupt keinen Sinn macht. 🙃
Gruss Alex
Dein Punkt war doch eingangs, dass die Programme zu viel virtuellen Arbeitsspeicher "verbrauchen". Ich habe dir gezeigt, dass reservieren nicht gleich verbrauchen ist, und ich problemlos ohne Performanceimplikationen 100 TB reservieren kann. Dass ich die 100 TB nicht verwenden kann, ist mir auch klar 🤪
Zitat von @MysticFoxDE:
Des Weiteren sollte man noch beachten/wissen, dass ein aktuelles Windows in Summe maximal 256TB an Virtualem Memory adressieren/verwalten kann.
Das betrifft physikalischen RAM und hat mit virtual memory nichts zu tunDes Weiteren sollte man noch beachten/wissen, dass ein aktuelles Windows in Summe maximal 256TB an Virtualem Memory adressieren/verwalten kann.
Ähm, ja, im Normallfall würde ich hier auch zustimmen … aber, das sieht insbesondere Microsoft wohl etwas anders. 😔
Das ist nicht Microsoft, das sind die Entwickler hinter V8 (Google)Natürlich habe ich zuerst gedacht, das kann doch nicht wirklich so sein, die Redmond-Microsoftianer werden doch mittlerweile nicht wirklich so bescheuert geworden sein und habe deshalb das Ganze nochmal per Power-Shell abgefragt …
Nein, es sind immer noch nicht die bösen "Redmond-Microsoftianer"… erstellt, um zu sehen, wieviel Virtual Memory (RAM) bereits in Summe bei meinem System reserviert sind und habe nach dem Ausführen dieses, das folgende zum Sehen bekommen …
… und zwar, das in meiner Workstation bereits !!! 110,80 TB !!! RAM, durch meistens von Microsoft kommenden Prozessen reserviert sind. 🙈
Gratuliere, du hast einen völlig sinnfreien und irrelevanten Wert ausgerechnet.… und zwar, das in meiner Workstation bereits !!! 110,80 TB !!! RAM, durch meistens von Microsoft kommenden Prozessen reserviert sind. 🙈
Das erklärt nun auch, warum mein Rechner, vor allem bei noch mehr offenen Edge Tabs irgendwann mal anfängt lahm zu werden, denn mehr als 256TB RAM, kann ein aktuelles Windows leider nicht adressieren. 🙃
Falsch, wie du hier siehst kann man problemlos mehr als 256 TB RAM in mehreren Prozessen reservieren...
Nach deiner Logik wäre dies so gar nicht möglich
Unbelegte halluzinierte Copilot-Aussagen tun deiner Position nicht gerade gut...
da hast du dich irgendwo aber gewaltigst verlesen.
Denn bereits im Titel steht klipp und klar ...
Windows 11 - Unerträgliche Ressourcenverschwendung - groteske RAM Reservierungen
... Reservierung und nicht Verbrauch/Belegung geschrieben.
Denn bereits im Titel steht klipp und klar ...
Windows 11 - Unerträgliche Ressourcenverschwendung - groteske RAM Reservierungen
... Reservierung und nicht Verbrauch/Belegung geschrieben.
@CamelCase hat sich nicht verlesen, du verstehst es nicht.
Die Programme reservieren keinen RAM, sondern einen Adressraum.
Das ist ein Unterschied wie Tag und Nacht.
Gruß,
Avoton
Wenn du KI so sehr akzeptierst: Habe den ganzen Beitrag mal in ChatGPT o3 mit Deep Research gepostet mit dem Prompt
Link zum Chat mit ausführlicher Antwort
https://chatgpt.com/share/6803594e-c2a0-8002-9d20-7491be000dc4
Fazit
Fazit: In der Diskussion haben CamelCase und Avoton die Funktionsweise der Windows-Speicherverwaltung korrekt dargestellt. Sie untermauerten ihre Erklärungen mit Quellen und praktischen Beispielen (Windows-Dokumentation, V8-Sandbox) und konnten zeigen, dass große virtuelle Adressräume normal, gewollt und unschädlich sind. MysticFoxDE hingegen zog falsche Schlüsse aus den beobachteten Werten. Seine Aussagen – etwa dass Windows hier „Ressourcen verschwendet“ – erwiesen sich als irreführend. Er unterschätzte den Unterschied zwischen Adressraum und tatsächlicher RAM-Nutzung und überschätzte den Verwaltungs-Overhead moderner Systeme. Zwar hatte er recht, dass theoretisch nicht der gesamte 1+ TB-Bereich physisch genutzt werden kann – das muss er aber auch gar nicht. Seine Kritik an der „RAM-Reservierung“ greift daher ins Leere: Windows 11 reserviert eben keinen physischen RAM in Terabyte-Größenordnung für einzelne Prozesse, sondern stellt nur virtuellen Adressplatz bereit. Die Diskussion zeigte, dass MysticFoxDEs Verständnis lückenhaft war. Er lag mit seiner Fundamentalkritik neben der Spur, während CamelCase (mit Avoton) die Mechanismen richtig beschrieben hat und damit im Recht war.
Zusammenfassung der Aussagen
wer liegt hier im recht und wer im unrecht. Belege die asussagen
Link zum Chat mit ausführlicher Antwort
https://chatgpt.com/share/6803594e-c2a0-8002-9d20-7491be000dc4
Fazit
Quelle: KI
Fazit: In der Diskussion haben CamelCase und Avoton die Funktionsweise der Windows-Speicherverwaltung korrekt dargestellt. Sie untermauerten ihre Erklärungen mit Quellen und praktischen Beispielen (Windows-Dokumentation, V8-Sandbox) und konnten zeigen, dass große virtuelle Adressräume normal, gewollt und unschädlich sind. MysticFoxDE hingegen zog falsche Schlüsse aus den beobachteten Werten. Seine Aussagen – etwa dass Windows hier „Ressourcen verschwendet“ – erwiesen sich als irreführend. Er unterschätzte den Unterschied zwischen Adressraum und tatsächlicher RAM-Nutzung und überschätzte den Verwaltungs-Overhead moderner Systeme. Zwar hatte er recht, dass theoretisch nicht der gesamte 1+ TB-Bereich physisch genutzt werden kann – das muss er aber auch gar nicht. Seine Kritik an der „RAM-Reservierung“ greift daher ins Leere: Windows 11 reserviert eben keinen physischen RAM in Terabyte-Größenordnung für einzelne Prozesse, sondern stellt nur virtuellen Adressplatz bereit. Die Diskussion zeigte, dass MysticFoxDEs Verständnis lückenhaft war. Er lag mit seiner Fundamentalkritik neben der Spur, während CamelCase (mit Avoton) die Mechanismen richtig beschrieben hat und damit im Recht war.
Zusammenfassung der Aussagen
Moin.
Was du da entdeckt hast, nennt man virtuelle Speicherverwaltung. Das bedeutet, daß zusammenhängende Speicherbereiche von einem laufendem Programm angefordert werden können. Reserviert ist davon erstmal nichts!
Dafür stellt das Betriebssystem (hier Windows 11) einen Bereich zur Verfügung, und der muss nicht mit dem tatsächlich vorhandenem Speicher korrelieren. Falls der von der Applikation angeforderte Speicherbereich größer als dein Hauptspeicher ist, gibt es Verfahren wie Swapfiles usw.
Du kannst dir sicher sein, daß sich andere Betriebssysteme mit virtueller Speicherverwaltung kein bischen anders benehmen. Abhängig davon, ob das BS 16-, 32- oder 64-bittig ist, berechnet sich die Größe des maximal zugesicherten virtuellen Speichers. Das jeweilige Programm tut ebenfalls seinen Teil dazu bei, ein 32-Bit Programm wird keinen 64-bittigen Bereich anfordern.
Erinnert sich noch jemand an DOS und UppperMemoryBlocks? Ich habe den Eindruck. dass du gerne das Verhalten von DOS ohne UMB in Windows 11 hättest. Das funktiniert nicht.
Diese Zusammenfassung ist ausgesprochen kurz. Programmierer, die noch mit malloc() und co zu tun haben, werden dazu noch ganz andere Sachen zu sagen haben. Und ja, alle, die bis jetzt auf dich eingeredet haben, haben eher recht.
Der nächte Punkt ist, daß du den Prozess-Explorer falsch interpretierst. Wirklich wichtig für die Anzeige des von Programmen in Beschlag genommenen Speichers sind die Spalten Private Bytes und Working Set. Working Set ist der aktuell komplett belegte Speicher eines Programms, Private Bytes das, was das Programm zur Ausführung wirklich benötigt.
Es ist die Regel, das die Größe des Working Sets größer ist, damit schnell benötigter Speicher nicht extra alloziiert werden muss. Denn das kostet Ressourssen, und der Speicher ist danach eventuell fragmentiert. Und das nennt man dann Dynamische Speicherverwaltung.
Unter diesem Gesichtspunkten ist es klar, dass du tatsächlich ein anderes Problem mit deinem Windows hast. Zugesicherter Speicher ist es nicht. Ich würde an deiner Stelle mit Autostart durchforsten beginnen, nach Viren scannen usw...
Aber eventuell habe ich eine Lösung für die jenigen, die sich über das Vorhandensein des MSEdge im Taskmanger wundern, obwohl sie den noch nie benutzt haben:
Deaktiviert den im Autostart. Das geht auch im Taskmanager unter Autostart von Apps bzw Autostart unter Windows 10.
Allerdings solltet ihr das testen, denn es ist möglich, das andere Programme MSEdge oder WebView benutzen.
Wenn ich
aufrufe erscheint folgendes:
Und das läuft echt prima. Und ich dachte, Firefox ist ein Speicherfreser...
So long
/random
Was du da entdeckt hast, nennt man virtuelle Speicherverwaltung. Das bedeutet, daß zusammenhängende Speicherbereiche von einem laufendem Programm angefordert werden können. Reserviert ist davon erstmal nichts!
Dafür stellt das Betriebssystem (hier Windows 11) einen Bereich zur Verfügung, und der muss nicht mit dem tatsächlich vorhandenem Speicher korrelieren. Falls der von der Applikation angeforderte Speicherbereich größer als dein Hauptspeicher ist, gibt es Verfahren wie Swapfiles usw.
Du kannst dir sicher sein, daß sich andere Betriebssysteme mit virtueller Speicherverwaltung kein bischen anders benehmen. Abhängig davon, ob das BS 16-, 32- oder 64-bittig ist, berechnet sich die Größe des maximal zugesicherten virtuellen Speichers. Das jeweilige Programm tut ebenfalls seinen Teil dazu bei, ein 32-Bit Programm wird keinen 64-bittigen Bereich anfordern.
Erinnert sich noch jemand an DOS und UppperMemoryBlocks? Ich habe den Eindruck. dass du gerne das Verhalten von DOS ohne UMB in Windows 11 hättest. Das funktiniert nicht.
Diese Zusammenfassung ist ausgesprochen kurz. Programmierer, die noch mit malloc() und co zu tun haben, werden dazu noch ganz andere Sachen zu sagen haben. Und ja, alle, die bis jetzt auf dich eingeredet haben, haben eher recht.
Der nächte Punkt ist, daß du den Prozess-Explorer falsch interpretierst. Wirklich wichtig für die Anzeige des von Programmen in Beschlag genommenen Speichers sind die Spalten Private Bytes und Working Set. Working Set ist der aktuell komplett belegte Speicher eines Programms, Private Bytes das, was das Programm zur Ausführung wirklich benötigt.
Es ist die Regel, das die Größe des Working Sets größer ist, damit schnell benötigter Speicher nicht extra alloziiert werden muss. Denn das kostet Ressourssen, und der Speicher ist danach eventuell fragmentiert. Und das nennt man dann Dynamische Speicherverwaltung.
Unter diesem Gesichtspunkten ist es klar, dass du tatsächlich ein anderes Problem mit deinem Windows hast. Zugesicherter Speicher ist es nicht. Ich würde an deiner Stelle mit Autostart durchforsten beginnen, nach Viren scannen usw...
Aber eventuell habe ich eine Lösung für die jenigen, die sich über das Vorhandensein des MSEdge im Taskmanger wundern, obwohl sie den noch nie benutzt haben:
Deaktiviert den im Autostart. Das geht auch im Taskmanager unter Autostart von Apps bzw Autostart unter Windows 10.
Allerdings solltet ihr das testen, denn es ist möglich, das andere Programme MSEdge oder WebView benutzen.
Wenn ich
Get-Process -Name "msedge" | Select-Object Name, @{Name="WorkingSet";Expression={$_.WorkingSet64}}, @{Name="PageFileUsage";Expression={$_.PageFileUsage}}, VirtualMemorySize64
aufrufe erscheint folgendes:
PS C:\Windows\system32> Get-Process -Name "msedge" | Select-Object Name, @{Name="WorkingSet";Expression={$_.WorkingSet64}}, @{Name="PageFileUsage";Expression={$_.PageFileUsage}}, VirtualMemorySize64
Get-Process : Es kann kein Prozess mit dem Namen "msedge" gefunden werden. Überprüfen Sie den Prozessnamen, und rufen Sie das Cmdlet erneut auf.
In Zeile:1 Zeichen:1
+ Get-Process -Name "msedge" | Select-Object Name, @{Name="WorkingSet"; ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (msedge:String) [Get-Process], ProcessCommandException
+ FullyQualifiedErrorId : NoProcessFoundForGivenName,Microsoft.PowerShell.Commands.GetProcessCommand
Und das läuft echt prima. Und ich dachte, Firefox ist ein Speicherfreser...
So long
/random
@DivideByZero
Es kommt jetzt darauf an herauszufinden, welche Weltverschwörer zu welchem Zweck diese KI so programmiert haben, um uns den Käsekuchen als Schwimmbad zu verkaufen.
Kreuzberger
ohne die Diskussion anheizen zu wollen, stelle ich doch beeindruckt fest, dass wir mit der KI nun einen neuen Schiedsrichter haben, der uns sagt, wo wir stehen. Schöne neue Welt!
Es kommt jetzt darauf an herauszufinden, welche Weltverschwörer zu welchem Zweck diese KI so programmiert haben, um uns den Käsekuchen als Schwimmbad zu verkaufen.
Kreuzberger
Zitat von @DivideByZero:
Moin,
ohne die Diskussion anheizen zu wollen, stelle ich doch beeindruckt fest, dass wir mit der KI nun einen neuen Schiedsrichter haben, der uns sagt, wo wir stehen. Schöne neue Welt! 🙄
Moin,
ohne die Diskussion anheizen zu wollen, stelle ich doch beeindruckt fest, dass wir mit der KI nun einen neuen Schiedsrichter haben, der uns sagt, wo wir stehen. Schöne neue Welt! 🙄
Nur daß der "Schiedsrichter" überhaupt keine Ahnung von Thema hat und meint trotzdem seinen Senf dazugeben zu müssen.
Schöne Feiertage Euch allen.
lks
alle die immer noch der Meinung sind, dass die viel zu grosse Virtual Memory Reservierung, insbesondere von den aktuellen Chromium basierten Browsern, so ganz normal sei, sollte sich den folgenden Screen-Shot mal genauer ansehen.
Das ist keine Meinung, das ist Fakt, weil es eine Designentscheidung von V8 ist, aber du willst es offenbar nicht verstehen...
Hallo,
nur mal so ein kleiner Hinweis zum Thema Anfragen bei KIs:
In neueren Versionen kann man deren Denkprozesse einschalten und ausgeben lassen, das solltet Ihr mal machen.
Ihr werdet feststellen, daß die KIs so gebaut sind, daß sie möglichst positive Antworten geben, die die Frage bestätigen.
Wenn man also sinnvolle Antworten erhalten will, sollte man die Frage unbedingt so formulieren, daß die erwartete Antwort nicht implizit schon mitgegeben wird, weil die KI versuchen wird, so gut es eben geht, diese zu bestätigen.
Stellt die Frage so, daß alles offen ist, so daß die KI keine Orientierungsmöglichkeit an der Frage hat, außerdem möglichst nicht in einem alten Chatverlauf, der sich bereits früher mit der Frage beschäftigt hat, da die KI die alten Fragen/Antworten mit benutzen wird.
Ich habe meinen Prompt an Gemini (Google) mal so formuliert:
"Ich habe eine Frage zu Speicherverwaltung von Windows. Kannst Du mir erläutern, warum sich Prozesse viel mehr Speicher reservieren als virtueller Speicher, als physikalisches RAM und Pagefile-Größe vorhanden ist?"
Ich gebe nicht mit, ob ich das gut oder schlecht finde oder welche Beeinträchtigung ich denke, daß dabei herauskommen könnte - ich frage die KI, mir zu erläutern, warum das so ist, so daß sie selbst eine Antwort finden muß.
Die Antwort von Gemini war durchaus nicht schlecht, wie ich finde, und erläutert genau das, was hier diskutiert wurde.
Man kann also auch kürzer formulieren: Der virtuelle Speicher ist keine Reservierung, sondern nur ein theoretisch nutzbarer Adressraum, der daher auch genauso schnell "reserviert" wird, ob klein oder groß, wie die Messung oben ja bestätigt hat. Einfach, weil nichts reserviert wird, solange das betreffende Programm nicht sagt "so, jetzt brauche ich aber wirklich soundsoviel Speicher" - erst dann schafft das Betriebssystem das RAM heran, was benötigt wird, inkl. Platz im Auslagerungsspeicher. Oder sagt eben: Nö, geht nicht, kein Platz. Erst bei erfolgreicher Reservierung ("committed") wird dann auch Verwaltung benötigt.
Ich habe Gemini noch konkret gefragt:
"Warum dann z.B. 1,5TB Adressraum vergeben, wenn man z.B. nur 32GB Speicher hat?"
Die Antwort, inbesondere fand ich den Telefonnummer-Vergleich gut:
Gruß
Christian
nur mal so ein kleiner Hinweis zum Thema Anfragen bei KIs:
In neueren Versionen kann man deren Denkprozesse einschalten und ausgeben lassen, das solltet Ihr mal machen.
Ihr werdet feststellen, daß die KIs so gebaut sind, daß sie möglichst positive Antworten geben, die die Frage bestätigen.
Wenn man also sinnvolle Antworten erhalten will, sollte man die Frage unbedingt so formulieren, daß die erwartete Antwort nicht implizit schon mitgegeben wird, weil die KI versuchen wird, so gut es eben geht, diese zu bestätigen.
Stellt die Frage so, daß alles offen ist, so daß die KI keine Orientierungsmöglichkeit an der Frage hat, außerdem möglichst nicht in einem alten Chatverlauf, der sich bereits früher mit der Frage beschäftigt hat, da die KI die alten Fragen/Antworten mit benutzen wird.
Ich habe meinen Prompt an Gemini (Google) mal so formuliert:
"Ich habe eine Frage zu Speicherverwaltung von Windows. Kannst Du mir erläutern, warum sich Prozesse viel mehr Speicher reservieren als virtueller Speicher, als physikalisches RAM und Pagefile-Größe vorhanden ist?"
Ich gebe nicht mit, ob ich das gut oder schlecht finde oder welche Beeinträchtigung ich denke, daß dabei herauskommen könnte - ich frage die KI, mir zu erläutern, warum das so ist, so daß sie selbst eine Antwort finden muß.
Die Antwort von Gemini war durchaus nicht schlecht, wie ich finde, und erläutert genau das, was hier diskutiert wurde.
Quelle: Gemini KI
Das ist eine sehr gute und insightful-Frage, die oft zu Verwirrung führt, wenn man die Speicherinformationen im Task-Manager oder anderen Tools betrachtet.
Die Erklärung liegt im Unterschied zwischen reserviertem (reserved) und zugesichertem (committed) virtuellem Speicher.
Lassen Sie es mich Schritt für Schritt erläutern:
Virtueller Speicher: Windows verwendet das Konzept des virtuellen Speichers. Jedem Prozess wird ein großer, privater virtueller Adressraum zugewiesen (bei 64-Bit-Systemen ist dieser extrem groß, Terabytes). Dieser virtuelle Adressraum ist nur eine Abstraktion und hat nicht direkt mit dem physikalischen RAM oder der Auslagerungsdatei zu tun.
Physikalisches RAM und Auslagerungsdatei (Pagefile): Das ist der tatsächliche Speicher, der physisch vorhanden ist (RAM) oder als "Erweiterung" des Speichers auf der Festplatte dient (Pagefile). Die Summe aus physikalischem RAM und der aktuellen Größe der Auslagerungsdatei (plus etwas Overhead) bildet den maximal verfügbaren zugesicherten Systemspeicher.
Reservierter Speicher (Reserved Memory): Wenn ein Prozess Speicher anfordert, kann er einen Bereich in seinem virtuellen Adressraum reservieren. Das bedeutet lediglich, dass der Prozess dem Betriebssystem mitteilt: "Ich möchte diesen Bereich im virtuellen Adressraum für mich beanspruchen. Niemand anderes soll diesen Bereich verwenden." Das Betriebssystem merkt sich das. Für diesen reservierten Speicherbereich wird zu diesem Zeitpunkt KEIN physikalischer Speicher (weder im RAM noch in der Auslagerungsdatei) zugewiesen oder reserviert. Es ist wie das Reservieren eines großen Blocks von Sitzplätzen in einem Kino – man hat die Plätze blockiert, aber man hat noch keine Eintrittskarten dafür gekauft, und das Kino muss die Plätze noch nicht physisch mit Personen belegen.
Zugesicherter Speicher (Committed Memory): Erst wenn der Prozess den reservierten Speicherbereich tatsächlich verwenden (beschreiben oder lesen) möchte, muss er diesen Speicherbereich zusichern. Das bedeutet, der Prozess fordert das Betriebssystem auf: "Ich brauche jetzt tatsächlich physikalischen Speicher für diesen Bereich in meinem virtuellen Adressraum." Das Betriebssystem muss dann sicherstellen, dass genug physikalischer Speicherplatz (entweder im RAM oder in der Auslagerungsdatei) zur Verfügung steht, um diesen zugesicherten Speicher aufzunehmen, FALLS er irgendwann ausgelagert werden müsste. Nur für den zugesicherten Speicher muss das Betriebssystem eine "Backing Store" finden, d.h. einen Platz im RAM oder einen Slot in der Auslagerungsdatei.
Warum ist der reservierte Speicher oft viel größer als RAM + Pagefile?
Weil die Summe des reservierten Speichers über alle Prozesse hinweg keine physikalische Ressource (RAM oder Pagefile-Slot) beansprucht. Das Betriebssystem muss nur sicherstellen, dass die Summe des zugesicherten Speichers aller Prozesse nicht den maximal verfügbaren zugesicherten Systemspeicher (RAM + Pagefile-Größe) überschreitet.
Prozesse reservieren oft sehr viel mehr virtuellen Speicher, als sie jemals benötigen oder zusichern, um:
Flexibilität bei der Speicherverwaltung zu haben (z.B. für potenziell große, dynamisch wachsende Datenstrukturen).
Fragmentierung des virtuellen Adressraums zu vermeiden, indem sie große, zusammenhängende Blöcke reservieren.
Mit Speicherbereichen für DLLs, Code, etc. zu arbeiten, die potenziell sehr groß sein können, aber nur teilweise physikalisch geladen werden müssen.
Zusammenfassend:
Was Sie in Task-Manager-Tools oft als "Speicher" oder "Virtueller Speicher" sehen, kann je nach Spalte entweder den Arbeitssatz (Working Set - der Teil des zugesicherten Speichers, der gerade im physikalischen RAM ist), den zugesicherten Speicher oder den reservierten Speicher meinen. Die Spalte, die oft sehr hohe Werte zeigt, ist in der Regel der reservierte virtuelle Adressraum.
Der entscheidende Engpass ist der zugesicherte Systemspeicher (Committed System Memory), der durch die Größe von RAM und Pagefile begrenzt ist. Solange die Summe des zugesicherten Speichers aller Prozesse nicht über diesen Wert steigt, ist alles in Ordnung, auch wenn die Summe des reservierten Speichers um ein Vielfaches höher liegt.
Es ist also ein normales und gewolltes Verhalten von Windows zur effizienten Verwaltung des riesigen virtuellen Adressraums, insbesondere auf 64-Bit-Systemen.
Die Erklärung liegt im Unterschied zwischen reserviertem (reserved) und zugesichertem (committed) virtuellem Speicher.
Lassen Sie es mich Schritt für Schritt erläutern:
Virtueller Speicher: Windows verwendet das Konzept des virtuellen Speichers. Jedem Prozess wird ein großer, privater virtueller Adressraum zugewiesen (bei 64-Bit-Systemen ist dieser extrem groß, Terabytes). Dieser virtuelle Adressraum ist nur eine Abstraktion und hat nicht direkt mit dem physikalischen RAM oder der Auslagerungsdatei zu tun.
Physikalisches RAM und Auslagerungsdatei (Pagefile): Das ist der tatsächliche Speicher, der physisch vorhanden ist (RAM) oder als "Erweiterung" des Speichers auf der Festplatte dient (Pagefile). Die Summe aus physikalischem RAM und der aktuellen Größe der Auslagerungsdatei (plus etwas Overhead) bildet den maximal verfügbaren zugesicherten Systemspeicher.
Reservierter Speicher (Reserved Memory): Wenn ein Prozess Speicher anfordert, kann er einen Bereich in seinem virtuellen Adressraum reservieren. Das bedeutet lediglich, dass der Prozess dem Betriebssystem mitteilt: "Ich möchte diesen Bereich im virtuellen Adressraum für mich beanspruchen. Niemand anderes soll diesen Bereich verwenden." Das Betriebssystem merkt sich das. Für diesen reservierten Speicherbereich wird zu diesem Zeitpunkt KEIN physikalischer Speicher (weder im RAM noch in der Auslagerungsdatei) zugewiesen oder reserviert. Es ist wie das Reservieren eines großen Blocks von Sitzplätzen in einem Kino – man hat die Plätze blockiert, aber man hat noch keine Eintrittskarten dafür gekauft, und das Kino muss die Plätze noch nicht physisch mit Personen belegen.
Zugesicherter Speicher (Committed Memory): Erst wenn der Prozess den reservierten Speicherbereich tatsächlich verwenden (beschreiben oder lesen) möchte, muss er diesen Speicherbereich zusichern. Das bedeutet, der Prozess fordert das Betriebssystem auf: "Ich brauche jetzt tatsächlich physikalischen Speicher für diesen Bereich in meinem virtuellen Adressraum." Das Betriebssystem muss dann sicherstellen, dass genug physikalischer Speicherplatz (entweder im RAM oder in der Auslagerungsdatei) zur Verfügung steht, um diesen zugesicherten Speicher aufzunehmen, FALLS er irgendwann ausgelagert werden müsste. Nur für den zugesicherten Speicher muss das Betriebssystem eine "Backing Store" finden, d.h. einen Platz im RAM oder einen Slot in der Auslagerungsdatei.
Warum ist der reservierte Speicher oft viel größer als RAM + Pagefile?
Weil die Summe des reservierten Speichers über alle Prozesse hinweg keine physikalische Ressource (RAM oder Pagefile-Slot) beansprucht. Das Betriebssystem muss nur sicherstellen, dass die Summe des zugesicherten Speichers aller Prozesse nicht den maximal verfügbaren zugesicherten Systemspeicher (RAM + Pagefile-Größe) überschreitet.
Prozesse reservieren oft sehr viel mehr virtuellen Speicher, als sie jemals benötigen oder zusichern, um:
Flexibilität bei der Speicherverwaltung zu haben (z.B. für potenziell große, dynamisch wachsende Datenstrukturen).
Fragmentierung des virtuellen Adressraums zu vermeiden, indem sie große, zusammenhängende Blöcke reservieren.
Mit Speicherbereichen für DLLs, Code, etc. zu arbeiten, die potenziell sehr groß sein können, aber nur teilweise physikalisch geladen werden müssen.
Zusammenfassend:
Was Sie in Task-Manager-Tools oft als "Speicher" oder "Virtueller Speicher" sehen, kann je nach Spalte entweder den Arbeitssatz (Working Set - der Teil des zugesicherten Speichers, der gerade im physikalischen RAM ist), den zugesicherten Speicher oder den reservierten Speicher meinen. Die Spalte, die oft sehr hohe Werte zeigt, ist in der Regel der reservierte virtuelle Adressraum.
Der entscheidende Engpass ist der zugesicherte Systemspeicher (Committed System Memory), der durch die Größe von RAM und Pagefile begrenzt ist. Solange die Summe des zugesicherten Speichers aller Prozesse nicht über diesen Wert steigt, ist alles in Ordnung, auch wenn die Summe des reservierten Speichers um ein Vielfaches höher liegt.
Es ist also ein normales und gewolltes Verhalten von Windows zur effizienten Verwaltung des riesigen virtuellen Adressraums, insbesondere auf 64-Bit-Systemen.
Man kann also auch kürzer formulieren: Der virtuelle Speicher ist keine Reservierung, sondern nur ein theoretisch nutzbarer Adressraum, der daher auch genauso schnell "reserviert" wird, ob klein oder groß, wie die Messung oben ja bestätigt hat. Einfach, weil nichts reserviert wird, solange das betreffende Programm nicht sagt "so, jetzt brauche ich aber wirklich soundsoviel Speicher" - erst dann schafft das Betriebssystem das RAM heran, was benötigt wird, inkl. Platz im Auslagerungsspeicher. Oder sagt eben: Nö, geht nicht, kein Platz. Erst bei erfolgreicher Reservierung ("committed") wird dann auch Verwaltung benötigt.
Ich habe Gemini noch konkret gefragt:
"Warum dann z.B. 1,5TB Adressraum vergeben, wenn man z.B. nur 32GB Speicher hat?"
Die Antwort, inbesondere fand ich den Telefonnummer-Vergleich gut:
Quelle: Gemini KI
Das ist genau der Punkt, an dem das Konzept des virtuellen Speichers ins Spiel kommt und sich von der physischen Realität abkoppelt.
Hier sind die Hauptgründe, warum jedem 64-Bit-Prozess ein so riesiger virtueller Adressraum zugewiesen wird (oft viel mehr als 1,5 TB, abhängig von der Windows-Version und Konfiguration, potenziell bis zu 128 TB oder sogar mehr), selbst wenn das System nur 32 GB physikalisches RAM und eine Auslagerungsdatei hat:
Vereinfachung für Entwickler: Dies ist einer der Hauptvorteile. Programmierer müssen sich beim Schreiben ihrer Anwendungen nicht darum kümmern, wie viel physikalischer Speicher tatsächlich vorhanden ist oder wo andere Programme im Speicher liegen. Jeder Prozess bekommt die Illusion eines riesigen, sauberen, zusammenhängenden Adressraums, beginnend bei Adresse 0. Das macht das Speichermanagement im Code viel einfacher und weniger fehleranfällig. Sie können Zeiger verwenden und Speicherblöcke reservieren, ohne sich Sorgen machen zu müssen, mit anderen Programmen in Konflikt zu geraten.
Isolation und Sicherheit: Jeder Prozess hat seinen eigenen privaten virtuellen Adressraum. Adressen in Prozess A zeigen standardmäßig nicht auf Speicher in Prozess B. Dies bietet einen starken Schutzmechanismus. Ein fehlerhaftes Programm kann nicht einfach auf den Speicher eines anderen Programms zugreifen und es zum Absturz bringen oder Daten stehlen (es sei denn, es gibt absichtliche Freigabemechanismen, die vom Betriebssystem verwaltet werden).
Flexibilität bei der Speicherzuweisung: Prozesse können große Bereiche ihres virtuellen Adressraums reservieren (siehe vorherige Erklärung). Das kostet fast keine physikalische Ressource, gibt dem Prozess aber die Garantie, dass dieser Adressbereich für ihn verfügbar ist, wenn er ihn später zusichern und nutzen möchte. Das ist nützlich für dynamisch wachsende Datenstrukturen oder die Handhabung großer potenzieller Speicherbedarfe.
Effizientes Laden von Programmen und DLLs (Memory Mapping): Wenn ein Programm oder eine DLL geladen wird, ordnet das Betriebssystem die Datei in den virtuellen Adressraum des Prozesses ein. Nicht der gesamte Code und die Daten müssen sofort ins RAM geladen werden. Nur die Teile, auf die tatsächlich zugegriffen wird, werden bei Bedarf ("on demand") vom Betriebssystem von der Festplatte ins RAM geholt (wiederum über Page Faults). Ein großer Adressraum ermöglicht es, sehr große Programme, Bibliotheken oder sogar Daten-/Kartendateien einfach in den Adressraum "einzublenden", ohne dass sie komplett im physikalischen Speicher liegen müssen.
Vermeidung von Fragmentierung im virtuellen Adressraum: Bei einem sehr großen Adressraum ist es unwahrscheinlicher, dass die "Löcher" (nicht zugesicherte Bereiche), die durch das Reservieren und Freigeben entstehen, zu einem praktischen Problem werden. Ein Prozess kann einfach große zusammenhängende Blöcke reservieren, was das Management vereinfacht.
Der entscheidende Punkt ist:
Die Summe des zugesicherten Speichers aller laufenden Prozesse auf dem System (plus dem Speicherbedarf des Betriebssystems selbst) darf das Limit von physikalischem RAM + Pagefile nicht überschreiten.
Der große virtuelle Adressraum prozessindividuell (1,5 TB oder mehr) ist ein separates Konzept, das die mögliche Reichweite der Adressen innerhalb eines Prozesses beschreibt. Es ist nicht der tatsächlich genutzte oder physikalisch hinterlegte Speicher.
Stellen Sie sich das wie Telefonnummern vor: Sie könnten theoretisch jedem Menschen auf der Welt eine eindeutige 10-stellige Telefonnummer zuweisen. Die Menge der möglichen Telefonnummern (der Adressraum) ist riesig. Aber die Menge der tatsächlichen Kontakte, die Sie auf Ihrem Handy gespeichert haben (der zugesicherte Speicher), ist durch den physikalischen Speicher Ihres Handys begrenzt. Die große Anzahl möglicher Telefonnummern schränkt die Kapazität Ihres Handys nicht ein, solange Sie nur die benötigten Nummern und Daten speichern.
Genauso ermöglicht der große virtuelle Adressraum den Prozessen, mit einem riesigen Adressbereich zu arbeiten, aber die tatsächliche physikalische Speichernutzung (RAM + Pagefile) wird vom Betriebssystem auf das verfügbare Hardware-Limit beschränkt.
Hier sind die Hauptgründe, warum jedem 64-Bit-Prozess ein so riesiger virtueller Adressraum zugewiesen wird (oft viel mehr als 1,5 TB, abhängig von der Windows-Version und Konfiguration, potenziell bis zu 128 TB oder sogar mehr), selbst wenn das System nur 32 GB physikalisches RAM und eine Auslagerungsdatei hat:
Vereinfachung für Entwickler: Dies ist einer der Hauptvorteile. Programmierer müssen sich beim Schreiben ihrer Anwendungen nicht darum kümmern, wie viel physikalischer Speicher tatsächlich vorhanden ist oder wo andere Programme im Speicher liegen. Jeder Prozess bekommt die Illusion eines riesigen, sauberen, zusammenhängenden Adressraums, beginnend bei Adresse 0. Das macht das Speichermanagement im Code viel einfacher und weniger fehleranfällig. Sie können Zeiger verwenden und Speicherblöcke reservieren, ohne sich Sorgen machen zu müssen, mit anderen Programmen in Konflikt zu geraten.
Isolation und Sicherheit: Jeder Prozess hat seinen eigenen privaten virtuellen Adressraum. Adressen in Prozess A zeigen standardmäßig nicht auf Speicher in Prozess B. Dies bietet einen starken Schutzmechanismus. Ein fehlerhaftes Programm kann nicht einfach auf den Speicher eines anderen Programms zugreifen und es zum Absturz bringen oder Daten stehlen (es sei denn, es gibt absichtliche Freigabemechanismen, die vom Betriebssystem verwaltet werden).
Flexibilität bei der Speicherzuweisung: Prozesse können große Bereiche ihres virtuellen Adressraums reservieren (siehe vorherige Erklärung). Das kostet fast keine physikalische Ressource, gibt dem Prozess aber die Garantie, dass dieser Adressbereich für ihn verfügbar ist, wenn er ihn später zusichern und nutzen möchte. Das ist nützlich für dynamisch wachsende Datenstrukturen oder die Handhabung großer potenzieller Speicherbedarfe.
Effizientes Laden von Programmen und DLLs (Memory Mapping): Wenn ein Programm oder eine DLL geladen wird, ordnet das Betriebssystem die Datei in den virtuellen Adressraum des Prozesses ein. Nicht der gesamte Code und die Daten müssen sofort ins RAM geladen werden. Nur die Teile, auf die tatsächlich zugegriffen wird, werden bei Bedarf ("on demand") vom Betriebssystem von der Festplatte ins RAM geholt (wiederum über Page Faults). Ein großer Adressraum ermöglicht es, sehr große Programme, Bibliotheken oder sogar Daten-/Kartendateien einfach in den Adressraum "einzublenden", ohne dass sie komplett im physikalischen Speicher liegen müssen.
Vermeidung von Fragmentierung im virtuellen Adressraum: Bei einem sehr großen Adressraum ist es unwahrscheinlicher, dass die "Löcher" (nicht zugesicherte Bereiche), die durch das Reservieren und Freigeben entstehen, zu einem praktischen Problem werden. Ein Prozess kann einfach große zusammenhängende Blöcke reservieren, was das Management vereinfacht.
Der entscheidende Punkt ist:
Die Summe des zugesicherten Speichers aller laufenden Prozesse auf dem System (plus dem Speicherbedarf des Betriebssystems selbst) darf das Limit von physikalischem RAM + Pagefile nicht überschreiten.
Der große virtuelle Adressraum prozessindividuell (1,5 TB oder mehr) ist ein separates Konzept, das die mögliche Reichweite der Adressen innerhalb eines Prozesses beschreibt. Es ist nicht der tatsächlich genutzte oder physikalisch hinterlegte Speicher.
Stellen Sie sich das wie Telefonnummern vor: Sie könnten theoretisch jedem Menschen auf der Welt eine eindeutige 10-stellige Telefonnummer zuweisen. Die Menge der möglichen Telefonnummern (der Adressraum) ist riesig. Aber die Menge der tatsächlichen Kontakte, die Sie auf Ihrem Handy gespeichert haben (der zugesicherte Speicher), ist durch den physikalischen Speicher Ihres Handys begrenzt. Die große Anzahl möglicher Telefonnummern schränkt die Kapazität Ihres Handys nicht ein, solange Sie nur die benötigten Nummern und Daten speichern.
Genauso ermöglicht der große virtuelle Adressraum den Prozessen, mit einem riesigen Adressbereich zu arbeiten, aber die tatsächliche physikalische Speichernutzung (RAM + Pagefile) wird vom Betriebssystem auf das verfügbare Hardware-Limit beschränkt.
Gruß
Christian
Tach Alex!
Ich habe mir die ganzen Diskussionen aufmerksam angeschaut und war des Öfteren fast dabei, diese zu kicken. In so einem Forum geht es primär nicht darum, Recht zu haben, sondern Probleme zu lösen und dabei noch Neues dazuzulernen. Meine Vorschreiber haben bereits alle Zusammenhänge richtig dargelegt – warum sich weiterhin dagegen wehren?
Das hilft dir, das Problem einzugrenzen. Nun kannst du die Ursache woanders suchen und das Thema „Virtuelle Speicherverwaltung“ ad acta legen. Alles andere ist Zeitverschwendung.
Vielleicht liegt dein Performanceproblem ganz woanders. Hier eine kleine Erfahrung nach Windows-Updates, die ich des Öfteren erlebt habe:
Trotz schnellem Laptop mit viel Leistung (i9, SSD, 32 GB RAM) hatte ich mehrfach das Problem, dass das System nach Updates extrem langsam war – teils über Stunden hinweg. Die Festplatte war ständig aktiv, der Prozessor hatte gut zu tun, und alles fühlte sich zäh an, selbst nach einem Neustart.
Ich verwende Visual Studio, um C#-Anwendungen zu entwickeln, und habe dafür so ziemlich alle .NET-Frameworks und -Versionen installiert. Nach einem Windows-Update startet das System dann im Hintergrund viele Prozesse: Es wird neu indiziert (also die Dateisuche vorbereitet), der Virenscanner prüft große Datenmengen erneut – und zusätzlich werden die .NET-Komponenten optimiert und vorbereitet. Das braucht ordentlich Rechenleistung und Zeit.
Gerade mit einer umfangreichen Entwicklungsumgebung wie meiner kann das zu einer echten Geduldsprobe werden. Der Rechner ist nicht kaputt – er ist nur hinter den Kulissen voll beschäftigt.
Bist du Entwickler und hast du vielleicht dasselbe Problem?
LG
René
Ich habe mir die ganzen Diskussionen aufmerksam angeschaut und war des Öfteren fast dabei, diese zu kicken. In so einem Forum geht es primär nicht darum, Recht zu haben, sondern Probleme zu lösen und dabei noch Neues dazuzulernen. Meine Vorschreiber haben bereits alle Zusammenhänge richtig dargelegt – warum sich weiterhin dagegen wehren?
Das hilft dir, das Problem einzugrenzen. Nun kannst du die Ursache woanders suchen und das Thema „Virtuelle Speicherverwaltung“ ad acta legen. Alles andere ist Zeitverschwendung.
Vielleicht liegt dein Performanceproblem ganz woanders. Hier eine kleine Erfahrung nach Windows-Updates, die ich des Öfteren erlebt habe:
Trotz schnellem Laptop mit viel Leistung (i9, SSD, 32 GB RAM) hatte ich mehrfach das Problem, dass das System nach Updates extrem langsam war – teils über Stunden hinweg. Die Festplatte war ständig aktiv, der Prozessor hatte gut zu tun, und alles fühlte sich zäh an, selbst nach einem Neustart.
Ich verwende Visual Studio, um C#-Anwendungen zu entwickeln, und habe dafür so ziemlich alle .NET-Frameworks und -Versionen installiert. Nach einem Windows-Update startet das System dann im Hintergrund viele Prozesse: Es wird neu indiziert (also die Dateisuche vorbereitet), der Virenscanner prüft große Datenmengen erneut – und zusätzlich werden die .NET-Komponenten optimiert und vorbereitet. Das braucht ordentlich Rechenleistung und Zeit.
Gerade mit einer umfangreichen Entwicklungsumgebung wie meiner kann das zu einer echten Geduldsprobe werden. Der Rechner ist nicht kaputt – er ist nur hinter den Kulissen voll beschäftigt.
Bist du Entwickler und hast du vielleicht dasselbe Problem?
LG
René
Hallo,
wollte noch hinzufügen: Ich habe Windows 10 Prof. 64Bit mit 32GB Speicher, bekomme von dem ersten Powershell-Skript oben das hier ausgegeben:
Gesamte Virtual Memory Belegung aller Prozesse: 273,23 TB
Da muß man natürlich gleich wieder einschränkend bemerken, daß das Wort "Belegung" aus dem Skript kommt. Es ist ja kein Speicher "belegt".
Gruß
Christian
wollte noch hinzufügen: Ich habe Windows 10 Prof. 64Bit mit 32GB Speicher, bekomme von dem ersten Powershell-Skript oben das hier ausgegeben:
Gesamte Virtual Memory Belegung aller Prozesse: 273,23 TB
Da muß man natürlich gleich wieder einschränkend bemerken, daß das Wort "Belegung" aus dem Skript kommt. Es ist ja kein Speicher "belegt".
Gruß
Christian
Ja, ich war in meinem Berufsleben auch schon Entwickler und hatte sowohl zu dieser Zeit aber auch danach, mitunter auch schon sehr viel mit komplexen Datenstrukturen und grossen Datenbanken zu tun. Sprich, das Thema effizientes Datenhandling ist mit alles andere als fremd.
Du gehst weiterhin von einem völlig anderen Thema aus. Ich sprach von den Folgen aktueller Windows- und .NET-Updates und nicht von grundsätzlichen Fragen der Speicherverwaltung oder Datenverarbeitung.
Dass du in deinem Berufsleben viel mit komplexen Datenstrukturen und großen Datenbanken zu tun hattest, will ich dir gar nicht absprechen. Aber genau deshalb wundert es mich, dass du das Verhalten der virtuellen Speicherverwaltung hier als „Fehler“ bezeichnest. Das, was du beobachtest, ist völlig normales und beabsichtigtes Verhalten moderner Betriebssysteme – kein Bug, kein Workaround, keine Misskonfiguration.
Wenn du massive Performance-Probleme hast, dann liegt die Ursache mit hoher Wahrscheinlichkeit woanders. Dass du dich nun ausgerechnet an der virtuellen Speicherreservierung festbeißt, obwohl das technisch erklärbar und erwartbar ist, führt in die falsche Richtung. Du hast da eine Beobachtung gemacht, sie falsch interpretiert und dich darauf eingeschossen – aber das bringt uns inhaltlich nicht weiter. Schlafe lieber eine Nacht darüber...
LG
René
Du stützt deine vehemente Kritik allein auf die im Process Explorer angezeigte “Virtual Size”, obwohl diese nur den reservierten virtuellen Adressraum abbildet und nicht die tatsächliche RAM‐Belegung oder das Commit‑Charge.
Seit Windows 8.1 stehen jedem 64‑Bit‑Prozess bis zu 128 TB User‑Mode‑Adressraum zur Verfügung – ganz ohne physischen Speicherverbrauch. Große Reservierungen sind in dieser Generation zudem “billig”: Erst beim Commit werden tatsächlich Ressourcen (RAM oder Pagefile) gebunden, vorher entsteht kein nennenswerter Overhead .
Der Commit‑Wert zeigt in Resource Monitor an, wie viel Speicher maximal gebraucht werden könnte – eine grobe Pagefile‑Schätzung, erst bei Zugriff werden Seiten in RAM oder Pagefile geschrieben. Das Working Set (tatsächlich im RAM) bleibt deutlich niedriger, selbst wenn du “Virtual Size” im Terabyte‑Bereich siehst.
Auch Chromium‑Engines (V8) reservieren Sandbox‑Bereiche von bis zu 1 TB, damit Sicherheitstechnik (ASLR, Heap‑Isolation) funktioniert – Design, kein Bug . Dass du daraus “Giganten‑RAM‑Reservierungen” bastelst, zeigt, dass du Grundlagen nicht verinnerlicht hast.
Die offiziellen Grenzwerte bestätigen: 128 TB User‑Mode, 128 TB Kernel‑Mode, erst beim Commit fällt physischer Verbrauch an. Wenn du echte Performance‑Engpässe hast, schaust du auf Working Set, Commit Charge und Pagefile Usage – nicht auf reservierten Adressraum.
Und mal ganz ehrlich: Dein großes “Wer” – sei es Microsoft‑Experte oder Superspezialist – beeindruckt hier niemanden, wenn die Fachkenntnis fehlt. Bevor du mit Titeln protzt, solltest du dich erst informieren, statt dich an rein virtuellen Zahlen festzubeißen.
Seit Windows 8.1 stehen jedem 64‑Bit‑Prozess bis zu 128 TB User‑Mode‑Adressraum zur Verfügung – ganz ohne physischen Speicherverbrauch. Große Reservierungen sind in dieser Generation zudem “billig”: Erst beim Commit werden tatsächlich Ressourcen (RAM oder Pagefile) gebunden, vorher entsteht kein nennenswerter Overhead .
Der Commit‑Wert zeigt in Resource Monitor an, wie viel Speicher maximal gebraucht werden könnte – eine grobe Pagefile‑Schätzung, erst bei Zugriff werden Seiten in RAM oder Pagefile geschrieben. Das Working Set (tatsächlich im RAM) bleibt deutlich niedriger, selbst wenn du “Virtual Size” im Terabyte‑Bereich siehst.
Auch Chromium‑Engines (V8) reservieren Sandbox‑Bereiche von bis zu 1 TB, damit Sicherheitstechnik (ASLR, Heap‑Isolation) funktioniert – Design, kein Bug . Dass du daraus “Giganten‑RAM‑Reservierungen” bastelst, zeigt, dass du Grundlagen nicht verinnerlicht hast.
Die offiziellen Grenzwerte bestätigen: 128 TB User‑Mode, 128 TB Kernel‑Mode, erst beim Commit fällt physischer Verbrauch an. Wenn du echte Performance‑Engpässe hast, schaust du auf Working Set, Commit Charge und Pagefile Usage – nicht auf reservierten Adressraum.
Und mal ganz ehrlich: Dein großes “Wer” – sei es Microsoft‑Experte oder Superspezialist – beeindruckt hier niemanden, wenn die Fachkenntnis fehlt. Bevor du mit Titeln protzt, solltest du dich erst informieren, statt dich an rein virtuellen Zahlen festzubeißen.
offenbar reden wir hier aneinander vorbei – fast wie mit einem Wunderheiler, der bewährte medizinische Methoden ablehnt, obwohl sie nachweislich wirken.
Ist leider so, war auch bei der Thematik hier Windows Server 2025 - Xeon Gold 6144 - Installationsdesaster nicht anders. Plattform wird offiziell nicht unterstützt aber es muss ja irgendwie gehen und Microsoft und Intel sind Schuld...
Ich bin dann hier auch raus.
Gruß,
Avoton
Ist leider so, war auch bei der Thematik hier Windows Server 2025 - Xeon Gold 6144 - Installationsdesaster nicht anders. Plattform wird offiziell nicht unterstützt aber es muss ja irgendwie gehen und Microsoft und Intel sind Schuld...
Zeit ohne Ende. Diese hätte ich auch gerne. Gut zu wissen für die Zukunft.
LG
René
dass ich mich z.B. hier bei administrator.de, mehrfacht am Tag neu anmelden musste
OT: Das Problem gab es mit Safari auch!Vermutlich aber @Frank und seiner Foren "Optimierung" geschuldet, denn das 2 gänzlich unterschiedliche Browser das gleiche Verhalten zeigen wäre etwas zuviel Zufall.
MysticFoxDE 23.04.2025 um 16:45:34 Uhr
Moin @Spirit-of-Eli,
Wäre da nicht das Problem mit diesen ganzen Chrome optimierten Webseiten.
ich habe damit bisher nur positive Erfahrungen gemacht und bisher auch noch keine Seite gehabt, die nicht so funktioniert hat wie sie sollte
Moin @Spirit-of-Eli,
Wäre da nicht das Problem mit diesen ganzen Chrome optimierten Webseiten.
ich habe damit bisher nur positive Erfahrungen gemacht und bisher auch noch keine Seite gehabt, die nicht so funktioniert hat wie sie sollte
Das Problem tritt z.B. bei YouTube auf. Höhere Qualität gibt es nur mit einem Chrome Browser. Gleiches gilt für Netflix.
Google Dienste sind auf einem Firefox langsamer als unter Chrome.
was meinst du mit gab, wann war das genau?
Das waren ca. 2 Wochen vor Ostern. In der Zeitspanne ist das alle naslang passiert. Eingeloggt, irgendwas geschrieben und beim Absenden die Fehlermeldung das die Session ungültig ist sprich man plötzlich von Geisterhand ausgeloggt war. Teils 2-3mal am Tag. Safari und Mac OS 15.3.2. Hier ist MS und Google freie Zone! 😉Während und nach Ostern ist das nicht mehr passiert.
was meinst du mit gab, wann war das genau?
Das waren ca. 2 Wochen vor Ostern. In der Zeitspanne ist das alle naslang passiert. Eingeloggt, irgendwas geschrieben und beim Absenden die Fehlermeldung das die Session ungültig ist sprich man plötzlich von Geisterhand ausgeloggt war. Teils 2-3mal am Tag. Safari und Mac OS 15.3.2. Hier ist MS und Google freie Zone! 😉Während und nach Ostern ist das nicht mehr passiert.
Kann ich so bestätigen für Firefox auf Windows und Android und ungefähr diesen Zeitraum. Sprich: nicht Client-, sondern Server-getriggert ....
Ähm, kann mir das bitte jemand mal erklären, danke!
Es ist unwichtig, es hat keine Auswirkung, du kannst es ignorieren. Wie oft muss das wiederholt werden?
inb4 "Aber nein es hat doch Auswirkungen!!!111elf"
Sorry aber du bist das krasseste Beispiel für den Dunning-Kruger-Effekt, das ich je gesehen habe.
Unglaublich. Du blamierst dich. Du verstehst es einfach nicht.
Ich wollte es erneut versuchen, aber die KI kann es besser gliedern und ich verschwende weniger Zeit:
Ich wollte es erneut versuchen, aber die KI kann es besser gliedern und ich verschwende weniger Zeit:
Quelle: KI
Dass Windows-Programme einen so großen virtuellen Adressraum bekommen, liegt an den Grundlagen der Speicherverwaltung moderner Betriebssysteme in Kombination mit der Architektur moderner Prozessoren. Hier eine ausführliche Erklärung:
---
1. Virtueller Adressraum ≠ Physischer Speicher
Moderne Betriebssysteme wie Windows nutzen ein sogenanntes virtuelles Speichermanagement. Das bedeutet:
Jeder Prozess bekommt seinen eigenen virtuellen Adressraum, unabhängig vom tatsächlich vorhandenen physischen RAM.
Der virtuelle Adressraum ist einfach ein mögliches Adressierungsmodell – nicht jeder Prozess nutzt ihn vollständig, und es wird auch nicht alles gleichzeitig im RAM gehalten.
---
2. 64-Bit-Architektur ermöglicht gigantische Adressräume
Ein wesentlicher Grund für die Größe liegt in der Prozessorarchitektur:
Ein 32-Bit-System kann nur 2³² = 4 GiB adressieren.
Ein 64-Bit-System könnte 2⁶⁴ = 16 EiB (Exbibyte) adressieren – theoretisch.
Tatsächlich wird in aktuellen Implementierungen oft nur ein Teil davon genutzt (z. B. 48 Bit oder 57 Bit), was trotzdem zu riesigen Adressräumen führt:
Windows 64-Bit gibt einem Prozess typischerweise einen virtuellen Adressraum von 128 TiB (256 TiB geteilt durch Kernel- und User-Space).
---
3. Vorteile eines riesigen virtuellen Adressraums
Ein großer virtueller Adressraum hat viele Vorteile:
Adress-Isolation: Jeder Prozess „denkt“, er hätte den ganzen Speicher für sich – das verbessert Sicherheit und Stabilität.
Speicherreservierung: Prozesse (besonders große Anwendungen wie Datenbanken, IDEs oder Browser) können große Adressbereiche reservieren, ohne sie gleich nutzen zu müssen.
Memory-Mapped Files, große Heaps, DLLs und andere Speicherbereiche lassen sich weit auseinander platzieren – das reduziert Kollisionen und Fragmentierung.
ASLR (Address Space Layout Randomization): Die zufällige Platzierung von Code und Daten für Sicherheitszwecke wird erst durch große Adressräume praktikabel.
---
4. Windows: Umsetzung im Detail
In Windows 64-Bit (x64) sieht es ungefähr so aus:
Der User-Space hat einen virtuellen Adressraum von 128 TiB (von 0x0000000000000000 bis 0x00007FFFFFFFFFFF).
Der Kernel-Space belegt ebenfalls 128 TiB (oberer Teil des Adressraums).
Diese Bereiche sind pro Prozess getrennt, das heißt: zwei Prozesse mit derselben virtuellen Adresse greifen auf unterschiedliche Inhalte zu.
---
5. Warum das keinen Speicher verschwendet
Virtueller Speicher ist nur eine Adressierung – es wird nur tatsächlich physischer Speicher (RAM oder Auslagerungsdatei) verbraucht, wenn:
Eine virtuelle Seite allokiert und benutzt wird.
Eine Datei in den Speicher gemappt wird (z. B. bei .NET-Anwendungen die Assemblies).
Der Prozess gezielt mit APIs wie VirtualAlloc Speicherbereiche reserviert und committed.
---
Fazit
Windows weist Programmen so große Adressräume zu, weil:
Die 64-Bit-Architektur es erlaubt.
Virtueller Speicher eine flexible und sichere Trennung und Verwaltung von Speicher ermöglicht.
Es zahlreiche Vorteile für Leistung, Sicherheit und Architektur bietet – ohne tatsächlich mehr RAM zu verbrauchen.
---
1. Virtueller Adressraum ≠ Physischer Speicher
Moderne Betriebssysteme wie Windows nutzen ein sogenanntes virtuelles Speichermanagement. Das bedeutet:
Jeder Prozess bekommt seinen eigenen virtuellen Adressraum, unabhängig vom tatsächlich vorhandenen physischen RAM.
Der virtuelle Adressraum ist einfach ein mögliches Adressierungsmodell – nicht jeder Prozess nutzt ihn vollständig, und es wird auch nicht alles gleichzeitig im RAM gehalten.
---
2. 64-Bit-Architektur ermöglicht gigantische Adressräume
Ein wesentlicher Grund für die Größe liegt in der Prozessorarchitektur:
Ein 32-Bit-System kann nur 2³² = 4 GiB adressieren.
Ein 64-Bit-System könnte 2⁶⁴ = 16 EiB (Exbibyte) adressieren – theoretisch.
Tatsächlich wird in aktuellen Implementierungen oft nur ein Teil davon genutzt (z. B. 48 Bit oder 57 Bit), was trotzdem zu riesigen Adressräumen führt:
Windows 64-Bit gibt einem Prozess typischerweise einen virtuellen Adressraum von 128 TiB (256 TiB geteilt durch Kernel- und User-Space).
---
3. Vorteile eines riesigen virtuellen Adressraums
Ein großer virtueller Adressraum hat viele Vorteile:
Adress-Isolation: Jeder Prozess „denkt“, er hätte den ganzen Speicher für sich – das verbessert Sicherheit und Stabilität.
Speicherreservierung: Prozesse (besonders große Anwendungen wie Datenbanken, IDEs oder Browser) können große Adressbereiche reservieren, ohne sie gleich nutzen zu müssen.
Memory-Mapped Files, große Heaps, DLLs und andere Speicherbereiche lassen sich weit auseinander platzieren – das reduziert Kollisionen und Fragmentierung.
ASLR (Address Space Layout Randomization): Die zufällige Platzierung von Code und Daten für Sicherheitszwecke wird erst durch große Adressräume praktikabel.
---
4. Windows: Umsetzung im Detail
In Windows 64-Bit (x64) sieht es ungefähr so aus:
Der User-Space hat einen virtuellen Adressraum von 128 TiB (von 0x0000000000000000 bis 0x00007FFFFFFFFFFF).
Der Kernel-Space belegt ebenfalls 128 TiB (oberer Teil des Adressraums).
Diese Bereiche sind pro Prozess getrennt, das heißt: zwei Prozesse mit derselben virtuellen Adresse greifen auf unterschiedliche Inhalte zu.
---
5. Warum das keinen Speicher verschwendet
Virtueller Speicher ist nur eine Adressierung – es wird nur tatsächlich physischer Speicher (RAM oder Auslagerungsdatei) verbraucht, wenn:
Eine virtuelle Seite allokiert und benutzt wird.
Eine Datei in den Speicher gemappt wird (z. B. bei .NET-Anwendungen die Assemblies).
Der Prozess gezielt mit APIs wie VirtualAlloc Speicherbereiche reserviert und committed.
---
Fazit
Windows weist Programmen so große Adressräume zu, weil:
Die 64-Bit-Architektur es erlaubt.
Virtueller Speicher eine flexible und sichere Trennung und Verwaltung von Speicher ermöglicht.
Es zahlreiche Vorteile für Leistung, Sicherheit und Architektur bietet – ohne tatsächlich mehr RAM zu verbrauchen.
Aber, ich habe bisher noch kein einziges Dokument seitens Intel oder Microsoft (Kernel oder MM Team) gefunden, das diese Aussage auch so bestätigt.
Vielmehr habe ich das Gefühl, dass sich mit diesem Thema noch nie jemand wirklich auseinandergesetzt hat.
Vielmehr habe ich das Gefühl, dass sich mit diesem Thema noch nie jemand wirklich auseinandergesetzt hat.
Gefühl haben, ist nicht wissen. Das Thema ist uralt. Das begann bereits mit den VAX-Architekturen und UNIX-Versionen ab ca. 1980, insbesondere mit 4.2BSD (1983). Also ein alter Käse. Warum muss man das heute noch durchkauen?
Wie erkläre ich einen Ureinwohner aus einem gerade entdeckten Amazonas-Volk, welches bis dato keinen Kontakt mit der "zivilisierten" Welt hatte, was GPS ist und wie es funktioniert?
Schau dir das bitte selber nochmals genauer an …
Du hast dir entweder Malware eingefangen, was weiß ich was im Hintergrund laufen, oder irgendwas kaputtkonfiguriert. Ich tippe auf letzteres. Wobei der 9820x ja auch schon ein paar Jahre auf dem Buckel hat. Im direkten Benchmark liegt er 20 - 30% hinter dem 13400
https://streamable.com/ev7cuj
Ich war schon draußen und ließ mich dummerweise zu weiteren Kommentaren hinreißen.
Mann, hast du Zeit ohne Ende. Was glaubst du eigentlich, damit beweisen zu müssen?
Ich bleibe dabei, denn ich weiß es einfach besser: Das habe ich unter anderem in meinem Studium gelernt und setze es seit vielen Jahren in meiner Arbeit erfolgreich ein.
LG
René
Mann, hast du Zeit ohne Ende. Was glaubst du eigentlich, damit beweisen zu müssen?
Ich bleibe dabei, denn ich weiß es einfach besser: Das habe ich unter anderem in meinem Studium gelernt und setze es seit vielen Jahren in meiner Arbeit erfolgreich ein.
LG
René
geht mir genau so...
https://de.m.wikipedia.org/wiki/John-Frum-Bewegung
Das kommt davon, wenn man das nicht besser weiß...
Kleiner Spoiler, es geht fürchte ich in diese ...
Und wieder nicht richtig gelesen:
OEMs may use the following CPUs for new Windows 11 devices.
Bist du ein OEM? Ist deine Workstation neu?
Beides nein, also ist die Liste nicht relevant für dich und sagt nichts darüber aus, ob dein i7 Windows 11 24H2 supported (was er tut).
Ich war schon draußen und ließ mich dummerweise zu weiteren Kommentaren hinreißen.
Dito
Gruß,
Avoton
Zitat von @MysticFoxDE:
@temuco
Während du noch in einer Realschule oder gar einem Gymnasium gessesen bist, sprich, noch lange vor deinem Studium, habe ich im selben Alter, sprich mit 15 Jahren, bereits schon für ein mittlerweile sehr grosses Software-Unternehmen gearbeitet, sprich, schon einige Jahre bevor ich meine ITler-Ausbildung dort angefangen habe. 😉
@temuco
Das habe ich unter anderem in meinem Studium gelernt und setze es seit vielen Jahren in meiner Arbeit erfolgreich ein.
Während du noch in einer Realschule oder gar einem Gymnasium gessesen bist, sprich, noch lange vor deinem Studium, habe ich im selben Alter, sprich mit 15 Jahren, bereits schon für ein mittlerweile sehr grosses Software-Unternehmen gearbeitet, sprich, schon einige Jahre bevor ich meine ITler-Ausbildung dort angefangen habe. 😉
Sorry, aber diese Aussage katapultiert dich bei mir endgültig in die Spinnerecke. Du brauchst eine Bestätigung im Leben? Dann verdiene sie dir, aber höre auf a) Unsinn durch KI belegen zu wollen und b) über andere zu mutmaßen, die du nicht kennst. Es tut mir Leid, dir das schreiben zu müssen, aber du outest dich nur noch als peinlicher Sprücheklopfer.
@MysticFoxDE
Es hat nicht jeder so viel Zeit wie du, um irgendwelchen Leistungsphantomen nachzujagen. Unsere Rechner scheinen ja leistungsmäßig nicht unbefriedigend zu sein, sonst wären wir sicher schon selbst auf Spurensuche gegangen.
Wer im Glashaus sitzt...
Gruß,
Avoton
Es hat nicht jeder so viel Zeit wie du, um irgendwelchen Leistungsphantomen nachzujagen. Unsere Rechner scheinen ja leistungsmäßig nicht unbefriedigend zu sein, sonst wären wir sicher schon selbst auf Spurensuche gegangen.
anstelle hier ständig nur blöde Sprüche zu klopfen, solltest du dir selber mal den folgenden Gefallen machen.
Wer im Glashaus sitzt...
Gruß,
Avoton
Ich möchte alle Beteiligten hiermit höflich bitten sachlich zu bleiben und Beleidigungen oder Anfeindungen zu unterlassen. Merci.
@colinardo (Moderator)
@colinardo (Moderator)
Warum tue ich mir das an? 
MysticFoxDE, ich kann deinen Frust teilweise nachvollziehen – wenn man sieht, wie Edge scheinbar gigabyteweise RAM frisst, kann das schon mal für Schnappatmung sorgen. Aber lass uns da mal genauer hinschauen, denn ich glaube, da werden ein paar Dinge falsch interpretiert - ich versuche es erneut...
Zum einen ist die „Virtual Size“, die du im Task Manager oder Process Explorer siehst, nicht gleichzusetzen mit dem tatsächlich belegten physischen RAM. Das ist eher wie ein Mietvertrag für ein riesiges Lagerhaus – nur weil du 10.000 m² gemietet hast, heißt das nicht, dass du auch alles vollgestellt hast. Edge reserviert sich Adressraum, aber der physische Verbrauch ist eine ganz andere Geschichte.
Dann vergleichst du den alten Edge (nicht Chromium-basiert) auf Windows 10 mit dem neuen Chromium-Edge auf Windows 11. Das ist, als würdest du einen Diesel-Laster mit einem E-Auto vergleichen und dich wundern, warum der Stromer mehr „Tankstellen“-Aufwand hat. Unterschiedliche Browser-Versionen haben unterschiedliche Anforderungen und Verhaltensweisen.
Außerdem bringt Windows 11 viele neue Funktionen und Sicherheitsmechanismen mit sich, wie z. B. HVCI, Kernel-Isolation und Verbesserungen im Speichermanagement. Diese Features können zusätzlichen Ressourcenverbrauch verursachen, bieten jedoch auch erhöhte Sicherheit und Stabilität. Der höhere Ressourcenverbrauch ist also nicht zwangsläufig ineffizient, sondern oft das Ergebnis verbesserter Funktionalitäten und Sicherheitsmaßnahmen.
Was den Anstieg der CPU-Zyklen und Kontextwechsel betrifft, können diese durch verschiedene Faktoren verursacht werden, einschließlich Hintergrundprozesse und Sicherheitsprüfungen. Ohne eine detaillierte Analyse ist es schwierig, den Anstieg ausschließlich auf ineffizientes Ressourcenmanagement zurückzuführen.
Abschließend möchte ich betonen, dass moderne Betriebssysteme komplexe Speicherverwaltungsstrategien implementieren, die nicht immer intuitiv erscheinen. Ein tieferes Verständnis dieser Mechanismen ist entscheidend, um fundierte Aussagen über die Effizienz von Windows 11 treffen zu können. Deshalb gibt es auch Ingenieurstudiengänge, die sich mit solchen Themen befassen – Dinge, die für Otto Normalverbraucher nicht immer leicht verständlich sind.
Wenn du tiefer in die Materie einsteigen möchtest, empfehle ich dir das Buch „Moderne Betriebssysteme“ von Andrew S. Tanenbaum, das einen umfassenden Überblick über die Speicherverwaltung und andere Aspekte moderner Betriebssysteme bietet.
MysticFoxDE, ich kann deinen Frust teilweise nachvollziehen – wenn man sieht, wie Edge scheinbar gigabyteweise RAM frisst, kann das schon mal für Schnappatmung sorgen. Aber lass uns da mal genauer hinschauen, denn ich glaube, da werden ein paar Dinge falsch interpretiert - ich versuche es erneut...
Zum einen ist die „Virtual Size“, die du im Task Manager oder Process Explorer siehst, nicht gleichzusetzen mit dem tatsächlich belegten physischen RAM. Das ist eher wie ein Mietvertrag für ein riesiges Lagerhaus – nur weil du 10.000 m² gemietet hast, heißt das nicht, dass du auch alles vollgestellt hast. Edge reserviert sich Adressraum, aber der physische Verbrauch ist eine ganz andere Geschichte.
Dann vergleichst du den alten Edge (nicht Chromium-basiert) auf Windows 10 mit dem neuen Chromium-Edge auf Windows 11. Das ist, als würdest du einen Diesel-Laster mit einem E-Auto vergleichen und dich wundern, warum der Stromer mehr „Tankstellen“-Aufwand hat. Unterschiedliche Browser-Versionen haben unterschiedliche Anforderungen und Verhaltensweisen.
Außerdem bringt Windows 11 viele neue Funktionen und Sicherheitsmechanismen mit sich, wie z. B. HVCI, Kernel-Isolation und Verbesserungen im Speichermanagement. Diese Features können zusätzlichen Ressourcenverbrauch verursachen, bieten jedoch auch erhöhte Sicherheit und Stabilität. Der höhere Ressourcenverbrauch ist also nicht zwangsläufig ineffizient, sondern oft das Ergebnis verbesserter Funktionalitäten und Sicherheitsmaßnahmen.
Was den Anstieg der CPU-Zyklen und Kontextwechsel betrifft, können diese durch verschiedene Faktoren verursacht werden, einschließlich Hintergrundprozesse und Sicherheitsprüfungen. Ohne eine detaillierte Analyse ist es schwierig, den Anstieg ausschließlich auf ineffizientes Ressourcenmanagement zurückzuführen.
Abschließend möchte ich betonen, dass moderne Betriebssysteme komplexe Speicherverwaltungsstrategien implementieren, die nicht immer intuitiv erscheinen. Ein tieferes Verständnis dieser Mechanismen ist entscheidend, um fundierte Aussagen über die Effizienz von Windows 11 treffen zu können. Deshalb gibt es auch Ingenieurstudiengänge, die sich mit solchen Themen befassen – Dinge, die für Otto Normalverbraucher nicht immer leicht verständlich sind.
Wenn du tiefer in die Materie einsteigen möchtest, empfehle ich dir das Buch „Moderne Betriebssysteme“ von Andrew S. Tanenbaum, das einen umfassenden Überblick über die Speicherverwaltung und andere Aspekte moderner Betriebssysteme bietet.
@temuco Wie kannst du nur?
Er hat doch schon lange bevor du studiert hast bei einem Software Entwickler gearbeitet! Das kann ja nicht stimmen was du sagst...
Gruß,
Avoton
Er hat doch schon lange bevor du studiert hast bei einem Software Entwickler gearbeitet! Das kann ja nicht stimmen was du sagst...
Gruß,
Avoton
Bei uns in der Firma ist es zu Recht verboten, Notebooks ohne Bitlocker zu nutzen. Selbiges in vielen anderen Firmen. Warum denn?
Die Speicherisolierung ist ebenfalls ein Gewinn und alles andere als fragwürdig.
Vielleicht über den eigenen Tellerrand hinaus schauen und aus der Matrix ausbrechen.
Wenn Windows so Kacke und verschwenderisch ist, dann steht dir u. a. Linux in unterschiedlichen Ausprägungen kostenfrei zur Verfügung.
Die Speicherisolierung ist ebenfalls ein Gewinn und alles andere als fragwürdig.
Vielleicht über den eigenen Tellerrand hinaus schauen und aus der Matrix ausbrechen.
Wenn Windows so Kacke und verschwenderisch ist, dann steht dir u. a. Linux in unterschiedlichen Ausprägungen kostenfrei zur Verfügung.
Wenn ein Notebook verloren geht oder gestohlen wird, schützt Bitlocker deine Daten. Allein das macht ihn wertvoll.
Im Übrigen ich nutze auch Linux parallel zu Windows. Ich programmieren auch für Linux und kenne das System sehr gut.
Ich schlage vor, du programmierst dir dein eigenes OS, wenn alles so kackig ist.
Im Übrigen ich nutze auch Linux parallel zu Windows. Ich programmieren auch für Linux und kenne das System sehr gut.
Ich schlage vor, du programmierst dir dein eigenes OS, wenn alles so kackig ist.
Also MysticFoxDE, um's mal gleich vorwegzunehmen: Wenn du denkst, BitLocker würde deinem schicken Windows-11-Rechner die Performance aus den Adern saugen, dann kann ich dich beruhigen – das Ding ist harmloser als ein Taschenrechner im Ruhezustand.
Heutzutage, mit halbwegs moderner Hardware – wir reden hier von allem, was ab Intel Core i5/i7 der 10. Generation oder einem Ryzen 3000 aufwärts kommt, natürlich gepaart mit einer ordentlichen SSD – ist BitLocker so effizient, dass du es im Alltag schlicht nicht bemerkst. Die CPU-Auslastung dümpelt irgendwo unterhalb der Wahrnehmungsschwelle herum, weil die Verschlüsselung über Hardware (AES-NI lässt grüßen) läuft und nicht per Software-Murks. Das RAM wird auch nicht nennenswert beansprucht – wir reden hier von einem mickrigen Megabyte, also weniger als der Task-Manager selbst verbraucht, wenn du ihn nur anschaust.
Und ja, die SSD-Performance – großer Mythos – bleibt praktisch unangetastet. Bei NVMe-Laufwerken liegt der Leistungsverlust irgendwo zwischen 0 und „war da was?“, vielleicht maximal 2–5 %, wenn du Benchmarks liebst. Im echten Leben? Keine Chance, dass du das merkst. Ein bisschen was merkt man höchstens bei alten SATA-Platten oder klassischen HDDs, aber wer so was 2025 noch einsetzt, hat vermutlich auch noch ICQ installiert.
Auch beim Systemstart: Klar, ein bis zwei Sekunden länger, weil TPM und Secure Boot erstmal ein bisschen Kaffee trinken müssen, bevor sie loslegen. Aber das war’s dann auch schon. Und nein, dein Akku leert sich nicht schneller, BitLocker schürft keine Coins und hört dich auch nicht heimlich ab – der Dienst pennt brav im Kernel und hält sich raus.
Kurz: Wer heutzutage bei BitLocker Angst um die Performance hat, ist entweder in der Windows-XP-Zeit stehen geblieben oder schaut zu viele YouTube-Videos von Leuten mit Alufolie auf dem WLAN-Router.
Und bevor du jetzt wieder mit „Aber man muss doch ’ne PIN beim Booten eingeben!“ um die Ecke kommst – nein, muss man nicht. Das ist optional. Nur wer sich extra Arbeit machen will, schaltet das ein. Standardmäßig reicht das TPM, macht seinen Job im Hintergrund und lässt dich in Ruhe booten.
Und ja, BIOS-Updates mit aktivem BitLocker? Ein echter Spaß. Erst deaktivieren, vorher den Wiederherstellungsschlüssel sichern (ohne den geht nämlich nix), dann flashen, hoffen, dass TPM keinen Anfall bekommt, und danach alles wieder aktivieren. Das eigentliche Update dauert fünf Minuten – der BitLocker-Zirkus drumherum gern das Doppelte.
Aber gut: BIOS-Flash macht man nicht jeden Morgen zum Kaffee. Genau deshalb nervt’s, wenn’s dann passiert – weil BitLocker plötzlich ein Fass aufmacht, als wär’s der digitale Türsteher mit Kontrollzwang. Und trotzdem gilt: Sicherheit gibt’s nicht für lau. Wer seine Daten ordentlich abschließen will, muss halt manchmal den Schlüssel rauskramen.
Aber klar – während ich noch Windeln vollgemacht hab, hatte MysticFoxDE mit 15 schon 20 Jahre Erfahrung bei IBM, Siemens und dem BND. Man merkt’s – an jedem einzelnen IT-Fass, das er aufmacht. Für den Aluhut reicht da keine Rolle Folie, da braucht’s Großhandel.
Heutzutage, mit halbwegs moderner Hardware – wir reden hier von allem, was ab Intel Core i5/i7 der 10. Generation oder einem Ryzen 3000 aufwärts kommt, natürlich gepaart mit einer ordentlichen SSD – ist BitLocker so effizient, dass du es im Alltag schlicht nicht bemerkst. Die CPU-Auslastung dümpelt irgendwo unterhalb der Wahrnehmungsschwelle herum, weil die Verschlüsselung über Hardware (AES-NI lässt grüßen) läuft und nicht per Software-Murks. Das RAM wird auch nicht nennenswert beansprucht – wir reden hier von einem mickrigen Megabyte, also weniger als der Task-Manager selbst verbraucht, wenn du ihn nur anschaust.
Und ja, die SSD-Performance – großer Mythos – bleibt praktisch unangetastet. Bei NVMe-Laufwerken liegt der Leistungsverlust irgendwo zwischen 0 und „war da was?“, vielleicht maximal 2–5 %, wenn du Benchmarks liebst. Im echten Leben? Keine Chance, dass du das merkst. Ein bisschen was merkt man höchstens bei alten SATA-Platten oder klassischen HDDs, aber wer so was 2025 noch einsetzt, hat vermutlich auch noch ICQ installiert.
Auch beim Systemstart: Klar, ein bis zwei Sekunden länger, weil TPM und Secure Boot erstmal ein bisschen Kaffee trinken müssen, bevor sie loslegen. Aber das war’s dann auch schon. Und nein, dein Akku leert sich nicht schneller, BitLocker schürft keine Coins und hört dich auch nicht heimlich ab – der Dienst pennt brav im Kernel und hält sich raus.
Kurz: Wer heutzutage bei BitLocker Angst um die Performance hat, ist entweder in der Windows-XP-Zeit stehen geblieben oder schaut zu viele YouTube-Videos von Leuten mit Alufolie auf dem WLAN-Router.
Und bevor du jetzt wieder mit „Aber man muss doch ’ne PIN beim Booten eingeben!“ um die Ecke kommst – nein, muss man nicht. Das ist optional. Nur wer sich extra Arbeit machen will, schaltet das ein. Standardmäßig reicht das TPM, macht seinen Job im Hintergrund und lässt dich in Ruhe booten.
Und ja, BIOS-Updates mit aktivem BitLocker? Ein echter Spaß. Erst deaktivieren, vorher den Wiederherstellungsschlüssel sichern (ohne den geht nämlich nix), dann flashen, hoffen, dass TPM keinen Anfall bekommt, und danach alles wieder aktivieren. Das eigentliche Update dauert fünf Minuten – der BitLocker-Zirkus drumherum gern das Doppelte.
Aber gut: BIOS-Flash macht man nicht jeden Morgen zum Kaffee. Genau deshalb nervt’s, wenn’s dann passiert – weil BitLocker plötzlich ein Fass aufmacht, als wär’s der digitale Türsteher mit Kontrollzwang. Und trotzdem gilt: Sicherheit gibt’s nicht für lau. Wer seine Daten ordentlich abschließen will, muss halt manchmal den Schlüssel rauskramen.
Aber klar – während ich noch Windeln vollgemacht hab, hatte MysticFoxDE mit 15 schon 20 Jahre Erfahrung bei IBM, Siemens und dem BND. Man merkt’s – an jedem einzelnen IT-Fass, das er aufmacht. Für den Aluhut reicht da keine Rolle Folie, da braucht’s Großhandel.
Im geschäftlichen Umfeld kommst du an BitLocker eh nicht vorbei – Compliance und DSGVO winken schon von weitem. Aber: Wer halbwegs sauber deployed (TPM-only, keine PIN, GPOs nutzen) und bei der Hardware nicht die billigste SSD aus dem Wühltisch nimmt, hat kaum was zu befürchten.
Softwareverschlüsselung kostet Leistung, klar – aber Sicherheit gibt’s halt nicht zum Nulltarif. Und wer BitLocker richtig einsetzt, merkt im Alltag nix davon. Außer er flasht täglich BIOS – aber dann ist eh was anderes schiefgelaufen.
Softwareverschlüsselung kostet Leistung, klar – aber Sicherheit gibt’s halt nicht zum Nulltarif. Und wer BitLocker richtig einsetzt, merkt im Alltag nix davon. Außer er flasht täglich BIOS – aber dann ist eh was anderes schiefgelaufen.
Grundsätzlich: Bitlocker schützt nur bei Diebstahl und / oder Verlust des Gerätes im ausgeschalteten Zustand.
Da kann man auch gleich den Hardwareschutz der Datenträger des Gerätes nehmen.
Meines Wissens nach bietet nur EFS (Encrypted File System) einen Schutz im laufenden Betrieb.
Aber auch da, gibt es Fallstricke.
Gruss Penny.
Da kann man auch gleich den Hardwareschutz der Datenträger des Gerätes nehmen.
Meines Wissens nach bietet nur EFS (Encrypted File System) einen Schutz im laufenden Betrieb.
Aber auch da, gibt es Fallstricke.
Gruss Penny.
Denn so ist vielen Anwendern und auch Admins, überhaupt nicht bewusst, dass auf dem entsprechenden Rechner der Bitlocker aktiviert wurde und spätestens beim nächsten BIOS-Update, stehen diese dann vor einem zerschossenen Rechner.
Dann muss der Super-Admin neu geschult werden oder er verkauft lieber Bio-Kartoffeln auf dem Wochenmarkt. Was für Argumente!
Windows 11 24H2 - Der neue Defender Horror
... könnte ich so richtig 🤮.
Kann ich nachvollziehen, aber das hat mit dem Ursprungsthema wahrlich nichts zu tun.
Microsoft Defender in Windows 11 24H2 hat sich in der Tat zu einem wahren Dauerbrenner entwickelt. Selbst wenn du eine Drittanbieter-Antivirensoftware installierst, bleibt Defender im Hintergrund aktiv. Die bekannten Versuche, ihn über Gruppenrichtlinien oder Registrierungseinträge zu deaktivieren, sind wirkungslos, da Microsoft diese Optionen bereits als veraltet betrachtet. Der Manipulationsschutz sorgt dafür, dass Defender nach einem Neustart wieder aktiviert wird, selbst wenn du ihn zuvor deaktiviert hast. Dies kann zu erhöhter CPU- und Festplattenauslastung führen, selbst wenn Defender im Hintergrund läuft.
Wenn dir das nicht gefällt, kannst du ja zu Linux wechseln – viel Spaß beim Kompilieren deiner eigenen Treiber (Spaß, ich selbst verwende Linux parallel zu Windows). Oder vielleicht zu Apple – wo du für die Freiheit bezahlst, nur das zu tun, was Apple erlaubt. Oder wie wäre es mit Huaweis neuem HarmonyOS?
Kurz gesagt, Microsoft gibt dir die Freiheit, das zu tun, was sie für richtig halten. Wenn dir das nicht passt, stehen dir Alternativen offen – jede mit ihren eigenen "Freiheiten".
Zitat von @kreuzberger:
Ein ganz zentraler, wichtiger Satz, den hier viele mal beherzigen sollten:
Kreuzberger
Stimme ich vollkommen zu. Muss man auch mal den Arbeitgebern mitteilen!Ein ganz zentraler, wichtiger Satz, den hier viele mal beherzigen sollten:
Und nein, nicht jeder von uns kann/muss alles wissen!
>Kreuzberger
Weil, die wollen doch immer eierlegende Wollmilchsau - Allwissende!
Das regt mich immer auf, wenn es heißt: "Das musst Du wissen!"
Da bekomme ich jedes Mal das große 🤮
Gruss Penny.
@Penny.Cilin
Ok, auch Arbeitgeber haben da schon mal bemerkenswerte vorstzellungn, was man als IT Mensch so alles wissen soll, sollte, und muss. (Nebenher muss man dann auch noch Rechtsanwalt sein und das Arbeitsrecht kennen, Datenschutz perfekt können, die DSGVO zur nor auswendig plappern und die gesamten gesetzlichen regeln zum Arbeitsschutz an Bildschirmarbeitsplätzen kennen. Achja, BSI Grundschutz nicht vergessen!)
Nein, ich meinte das auch einige tolle Leute hier und die Platform bezogen, die allzu sehr darauf bedacht sind, fragenden hier ganz schnell jegliche Kompetenz und die Daseinsberechtigung als Admin abzusprechen, weil man was fragt.
Kreuzberger
Ok, auch Arbeitgeber haben da schon mal bemerkenswerte vorstzellungn, was man als IT Mensch so alles wissen soll, sollte, und muss. (Nebenher muss man dann auch noch Rechtsanwalt sein und das Arbeitsrecht kennen, Datenschutz perfekt können, die DSGVO zur nor auswendig plappern und die gesamten gesetzlichen regeln zum Arbeitsschutz an Bildschirmarbeitsplätzen kennen. Achja, BSI Grundschutz nicht vergessen!)
Nein, ich meinte das auch einige tolle Leute hier und die Platform bezogen, die allzu sehr darauf bedacht sind, fragenden hier ganz schnell jegliche Kompetenz und die Daseinsberechtigung als Admin abzusprechen, weil man was fragt.
Kreuzberger
Serie: Windows 11 - Ressourcenverschwendung
Windows 11 24H2 - Der neue Defender Horror20Windows 11 - Unerträgliche Ressourcenverschwendung - grotesker RAM und CPU Verbrauch60Windows 11 - Unerträgliche Ressourcenverschwendung - groteske RAM Reservierungen129Windows 11 - Unerträgliche Ressourcenverschwendung32