Leistung und Kapazität

„Der Server ist langsam“ kommt fast immer mit einer mitgelieferten Erklärung, und auf einem Server gibt es immer irgendeinen Wert, der hoch aussieht. Dieses Modul ordnet Zahlen wieder den Fragen zu, die sie beantworten: warum eine niedrige Prozessorlast zu einem Engpass passt statt ihn auszuschließen, warum die Faustregel für die Auslagerungsdatei in der Dokumentation ausdrücklich abgelehnt wird, und warum eine Kapazitätswarnung ohne Vorlaufzeit im Nenner zuverlässig zu spät meldet.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Messen, bevor man erklärt

„Der Server ist langsam“ kommt fast immer mit einer mitgelieferten Erklärung — zu wenig Arbeitsspeicher, die Platte, das Netz. Die Erklärung stammt aus der letzten Erfahrung des Meldenden und ist ungefähr so oft richtig wie ein Münzwurf.

Der Unterschied zwischen einer Vermutung und einer Diagnose ist nicht die Menge der Messwerte, sondern die Reihenfolge: erst das Zeitfenster festlegen, in dem das Problem auftrat, dann messen, dann erklären. Wer umgekehrt vorgeht, findet für jede Erklärung eine Zahl, die zu ihr passt — auf einem Server gibt es immer irgendeinen Wert, der hoch aussieht.

Der teuerste FehlerEine Maßnahme, die auf einer falschen Erklärung beruht — mehr Arbeitsspeicher für ein Datenträgerproblem —, kostet Geld, ändert nichts und erzeugt den Eindruck, das Problem sei unlösbar. Danach ist die nächste, richtige Maßnahme schwerer durchzusetzen als die erste es war.

Ein Zähler misst genau eine Sache

Leistungsindikator — Ein benannter Messwert, den eine Komponente des Betriebssystems oder eine Anwendung bereitstellt — aufgebaut aus Objekt, Instanz und Indikator, etwa Prozessor, Instanz _Total, Indikator Prozessorzeit.

Ein Zähler beantwortet die Frage, für die er gebaut wurde, und keine andere. Die meisten Fehldiagnosen entstehen nicht durch falsche Messung, sondern dadurch, dass ein Wert eine Frage beantworten soll, die er nicht kennt.

Get-Counter -ListSet *: Welche Indikatorensätze gibt es auf diesem Server?
Get-Counter -Counter '\Prozessor(_Total)\Prozessorzeit (%)': Ein Wert, sofort. Für einen schnellen Blick.
Get-Counter … -SampleInterval 5 -MaxSamples 720: Eine Stunde messen, im Fünf-Sekunden-Takt.
logman create counter …: Eine dauerhafte Sammlung, die einen Neustart überlebt.

Warum die Namen lokalisiert sindAuf einem deutschsprachigen Windows heißen die Indikatoren deutsch, und ein Skript mit englischen Namen findet sie nicht. Wer Skripte über eine gemischte Flotte laufen lässt, arbeitet deshalb mit den sprachunabhängigen Nummern oder liest die lokalen Namen zur Laufzeit aus. Das ist der Grund, warum ein Sammelskript auf dem einen Server Werte liefert und auf dem nächsten leere Listen.

Auslastung ist keine Sättigung

Die Prozessorzeit ist der bekannteste Wert und der am häufigsten überinterpretierte. Sie sagt, welcher Anteil eines Zeitraums nicht im Leerlauf verbracht wurde — nicht, ob jemand warten musste.

Prozessorzeit hoch, keine Warteschlange: Der Server arbeitet. Das ist der gewünschte Zustand, kein Befund.
Prozessorzeit hoch, Warteschlange lang: Arbeit wartet auf Rechenzeit. Jetzt ist es ein Engpass.
Prozessorzeit niedrig, Anwendung langsam: Der Engpass liegt woanders — die Anwendung wartet, statt zu rechnen.

Der dritte Fall ist der häufigsteEine langsame Anwendung mit 20 Prozent Prozessorauslastung ist der Normalfall bei einem Datenträger- oder Netzproblem: Der Prozessor hat nichts zu tun, weil er auf etwas wartet. Wer nur die Prozessorzeit misst, sieht einen entspannten Server und meldet, es liege nicht am Server. Die Aussage stimmt sogar — nur nicht für die Komponente, die gemessen wurde.

Für virtuelle Server kommt eine weitere Unschärfe dazu: Die Prozessorzeit im Gast bezieht sich auf die Rechenzeit, die der Gast bekommen hat. Wartet er auf Zuteilung durch den Host, sieht er davon nichts — für ihn steht die Uhr einfach still. Ein Gast mit 40 Prozent Prozessorzeit auf einem überbuchten Host ist deshalb kein entspannter Server, sondern einer, dessen wahre Auslastung nur der Host kennt. Die Zahl aus dem Gast ist damit für Kapazitätsaussagen unbrauchbar, solange die Hostseite nicht danebensteht.

Arbeitsspeicher: vier Zahlen, vier Fragen

Verfügbare MB: Wie viel Speicher steht sofort zur Verfügung? Die erste Zahl bei Speicherdruck.
Zugesicherte Bytes (Commit Charge): Wie viel Speicher haben Prozesse angefordert — unabhängig davon, wie viel davon im RAM liegt.
Arbeitsseiten eines Prozesses (Working Set): Wie viel des Prozesses liegt gerade im physischen Speicher.
Private Bytes eines Prozesses: Wie viel der Prozess allein angefordert hat, ohne geteilte Anteile. Die Zahl für die Suche nach einem Leck.

Warum Arbeitsseiten kein Leck zeigenDie Arbeitsseiten eines Prozesses schrumpfen, wenn das Betriebssystem Speicherdruck ausgleicht — sie sind ein Ergebnis der Gesamtlage, nicht des Prozessverhaltens. Ein Prozess mit einem echten Leck kann deshalb konstante Arbeitsseiten und stetig wachsende private Bytes zeigen. Wer auf die falsche Zahl schaut, sieht ein Leck erst, wenn es den ganzen Server trifft.

Get-Counter '\Arbeitsspeicher\Verfügbare MB' — der schnelle Blick auf den Speicherdruck.
Get-Process | Sort-Object PrivateMemorySize64 -Descending | Select-Object -First 10 — wer hat wie viel privat angefordert?
Get-CimInstance Win32_OperatingSystem | Select-Object TotalVisibleMemorySize, FreePhysicalMemory — die Gesamtlage in einer Zeile.
Denselben Prozess über Tage vergleichen — ein Leck erkennt man an der Steigung, nicht am Wert.

Die Grenze, die niemand einbaut

Zusicherungsgrenze — Die Summe aus physischem Arbeitsspeicher und allen Auslagerungsdateien zusammen. Die zugesicherte Speichermenge des Systems kann diese Grenze laut Dokumentation nicht überschreiten.

Diese Definition hat eine Folge, die viele überrascht: Ohne Auslagerungsdatei ist die Zusicherungsgrenze etwas kleiner als der installierte Arbeitsspeicher. Ein Server ohne Auslagerungsdatei kann also weniger Speicher zusichern, als er physisch hat — und Anwendungen scheitern mit Speicherfehlern, obwohl der Taskmanager freien Speicher zeigt.

Was die Fehlermeldung nicht sagtEin erreichtes Zusicherungslimit erscheint in Anwendungen als Speicherfehler, in Diensten als gescheiterter Start und im Ereignisprotokoll als etwas Unspezifisches. Die verfügbaren Megabyte können dabei komfortabel aussehen. Die beiden Zahlen messen verschiedene Dinge: verfügbar heißt sofort nutzbar, zugesichert heißt versprochen. Ein System kann viel Verfügbares haben und trotzdem nichts mehr versprechen dürfen.

Zu messen ist das mit dem Indikator für zugesicherte Bytes im Verhältnis zur Zusicherungsgrenze. Beide stehen im Arbeitsspeicher-Indikatorensatz nebeneinander, und ihr Verhältnis ist eine der wenigen Zahlen, die man ohne Vergleichswert deuten kann: Nähert es sich der Eins, ist eine Grenze in Sicht, unabhängig davon, wie viel physischer Speicher gerade frei aussieht. In einer Baseline-Sammlung gehört dieses Verhältnis deshalb dazu, auch wenn es im Normalbetrieb unauffällig bleibt.

Die Auslagerungsdatei lässt sich nicht pauschal dimensionieren

Die verbreitete Faustregel — das Anderthalbfache des Arbeitsspeichers — hat in der Dokumentation keine Grundlage. Dort steht das Gegenteil: Die Größe hängt vom Absturzabbild und von der Spitze der zugesicherten Speichermenge ab, beides ist je System einzigartig, und deshalb lässt sich die Größe nicht verallgemeinern — selbst für baugleiche Systeme nicht.

Für das Absturzabbild: Ein vollständiges Abbild braucht mindestens Arbeitsspeicher plus 257 MB. Ohne ausreichende Auslagerungsdatei oder eigene Abbilddatei entsteht kein Abbild.
Für die Zusicherung: Groß genug für die gemessene Spitze der zugesicherten Speichermenge dieses Servers.
Systemverwaltet: Wird beim Start passend zur Absturzabbild-Einstellung bemessen, sofern genug Plattenplatz frei ist.
Eigene Abbilddatei: Eine Alternative zur Auslagerungsdatei, wenn diese nicht groß genug sein soll.

Das automatische Abbild ändert seine MeinungDie Voreinstellung ist das automatische Speicherabbild, und sie ist dynamisch: Sie beginnt mit einer kleinen Auslagerungsdatei. Stürzt das System innerhalb von vier Wochen erneut ab, setzt sie die Größe auf den Arbeitsspeicher oder 32 GB, je nachdem, was kleiner ist. Stürzt es danach wieder innerhalb von vier Wochen ab, wird beim Neustart ein vollständiges Abbild gewählt. Ein Server, der zweimal abgestürzt ist, hat also eine andere Auslagerungsdatei als vorher — und braucht plötzlich Plattenplatz, den niemand eingeplant hat.

Datenträger: zwei Fragen, zwei Zahlen

Bei Datenträgern werden Durchsatz und Latenz regelmäßig vermischt. Sie beantworten verschiedene Fragen, und für eine langsame Anwendung ist fast immer die zweite die richtige.

Durchsatz: Wie viele Bytes pro Sekunde bewegt das System? Beantwortet Kapazitätsfragen.
Ein-/Ausgabevorgänge pro Sekunde: Wie viele Zugriffe? Für viele kleine Zugriffe die relevantere Mengenangabe.
Latenz je Zugriff: Wie lange dauert ein einzelner Zugriff? Das ist die Zahl, die der Nutzer spürt.
Warteschlangenlänge: Wie viele Zugriffe warten? Nur zusammen mit der Zahl der Datenträger interpretierbar.

Warum prozentuale Auslastung hier täuschtBei einem Speichersystem, das mehrere Zugriffe gleichzeitig bedient, bildet eine prozentuale Auslastung die Leistungsgrenze nicht ab: Der Wert kann bei 100 Prozent stehen, während das System noch Reserven hat, und er kann harmlos aussehen, während einzelne Zugriffe lange dauern. Die Latenz je Zugriff ist die Zahl, die man einer Anwendungsbeschwerde gegenüberstellen kann — sie hat dieselbe Einheit wie die Wahrnehmung des Nutzers.

Die Werkzeuge dafür sind vorhanden und werden selten benutzt. Get-Counter '\PhysicalDisk(*)\Mittlere Sek./Lesevorgänge' liefert die Latenz je Datenträger, Get-StorageReliabilityCounter die Sicht des Datenträgers auf sich selbst, und Get-PhysicalDisk beantwortet die Frage, wie viele Datenträger hinter dem gemessenen Volume überhaupt stehen. Die letzte Zahl braucht man, bevor man eine Warteschlangenlänge bewertet: Eine Warteschlange von acht ist auf einem Datenträger ein Problem und auf zwölf Datenträgern eine Randnotiz.

Mittelwerte verstecken das Problem

Ein Stundenmittelwert glättet genau das weg, was gemeldet wurde. Wenn eine Anwendung an zwei Minuten pro Stunde nicht antwortet, ist der Stundenmittelwert unauffällig — und die Beschwerde bleibt trotzdem berechtigt.

Kurzcheck

Nutzer melden, die Anwendung hänge mehrmals täglich für kurze Zeit. Der Kapazitätsbericht zeigt über den Tag gemittelt 40 Prozent Prozessorauslastung. Was folgt daraus?

Nichts — das Mittel kann kurze Spitzen nicht abbilden, es braucht ein feineres Intervall
Die Meldung ist unbegründet, 40 Prozent sind unauffällig
Der Engpass liegt sicher beim Datenträger, weil die CPU frei ist

Treffer. Richtig. Ein Mittelwert über Stunden glättet Minuten weg. Die Frage lässt sich nur mit einem Messintervall beantworten, das kürzer ist als das gemeldete Symptom.

Perzentile statt MittelwertFür eine Aussage über Nutzerwahrnehmung ist das 95. oder 99. Perzentil der brauchbarere Wert: Es sagt, wie schlecht es für die schlechtesten Anfragen war. Ein Dienstvertrag, der auf einem Mittelwert beruht, kann eingehalten sein, während ein Teil der Nutzer regelmäßig wartet — und beide Seiten haben recht.

Dasselbe gilt in die andere Richtung: Ein einzelner Spitzenwert ist noch kein Befund. Ein Server, der einmal am Tag für zehn Sekunden bei hundert Prozent steht, tut nichts Auffälliges — irgendein geplanter Vorgang läuft. Erst die Kombination aus Häufigkeit, Dauer und einer betroffenen Nutzerwahrnehmung macht daraus etwas, das behandelt werden muss. Wer auf einzelne Spitzen alarmiert, erzeugt Meldungen, die nach drei Wochen niemand mehr liest — und übersieht darin die eine, die zählt.

Messen kostet

Eine Messung ist kein passiver Vorgang. Jedes Intervall erzeugt Last und Daten, und beides skaliert mit der Zahl der Indikatoren, der Zahl der Instanzen und der Zahl der Server.

Das Intervall muss kürzer sein als das Symptom, das man erfassen will — sonst misst man an ihm vorbei.
Es darf nicht so kurz sein, dass die Messung selbst zur Last wird, die man untersucht.
Die Aufbewahrung entscheidet, ob man einen Vergleich zum Normalzustand hat — ohne den ist jeder Wert nur eine Zahl.
Indikatoren mit vielen Instanzen — je Prozess, je Datenträger, je Netzwerkkarte — vervielfachen beides.

Praktisch heißt das zwei verschiedene Sammlungen: eine dauerhafte mit wenigen Indikatoren und grobem Intervall als Baseline, und eine gezielte mit feinem Intervall, die nur im Verdachtsfall läuft. Wer nur die zweite hat, misst im Vorfall ohne Vergleichswert; wer nur die erste hat, misst am Symptom vorbei.

logman create counter <Name> -c <Indikatoren> -si 00:00:15: Legt eine Sammlung mit 15-Sekunden-Intervall an.
logman start <Name> / logman stop <Name>: Startet und beendet sie.
logman query <Name> -ets: Zeigt Konfiguration und Zustand.
-max <MB> und -cnf: Begrenzen die Dateigröße und erzwingen einen Dateiwechsel — ohne beides läuft die Platte voll.

Geteilte Engpässe

Wenn mehrere Anwendungen gleichzeitig langsam werden, liegt die Ursache selten in einer von ihnen. Die aussagekräftigste Frage lautet dann nicht „was ist mit dieser Anwendung“, sondern: Was teilen sie sich?

Derselbe Host: Prozessor, Arbeitsspeicher, lokale Datenträger, Netzwerkkarte.
Derselbe Virtualisierungshost: Alle Ressourcen des Hosts — sichtbar nur von dort, nicht aus dem Gast.
Dasselbe Speichersystem: Ein Volume, ein Pfad, ein Verbund.
Dieselbe Abhängigkeit: Ein Verzeichnisdienst, ein Namensdienst, ein Datenbankserver, ein Proxy.

Warum die Messung im Gast nicht reichtEin virtueller Server, dessen Host überbucht ist, misst in sich unauffällige Werte: Er bekommt weniger Rechenzeit, aber er sieht nur, was er bekommt. Die Wartezeit auf dem Host taucht in seinen Zählern nicht auf. Bei mehreren gleichzeitig langsamen Gästen ist der Blick auf den Host deshalb nicht der letzte Schritt, sondern einer der ersten.

Von der Messung zur Kapazitätsaussage

Kapazitätsplanung ist eine Aussage über die Zukunft und braucht drei Größen, die getrennt zu ermitteln sind. Fehlt eine davon, ist das Ergebnis eine Zahl ohne Aussagewert.

Wachstum — wie hat sich der Bedarf über einen ausreichend langen Zeitraum entwickelt?
Spitze — nicht der Mittelwert, sondern der Wert, den das System tragen können muss.
Vorlauf — wie lange dauert es von der Entscheidung bis zur verfügbaren Kapazität?

Die dritte Größe wird am häufigsten vergessen und entscheidet über den Zeitpunkt: Wer sechs Wochen Beschaffungszeit hat, muss sechs Wochen vor dem Engpass entscheiden — nicht bei Erreichen einer Schwelle. Eine Kapazitätswarnung ohne Vorlaufzeit im Nenner meldet zuverlässig zu spät.

Und der Reservebedarf für den AusfallEine oft übersehene vierte Größe: Wenn ein Knoten ausfällt und seine Last die übrigen übernehmen sollen, muss diese Reserve eingeplant sein. Eine Umgebung, die im Normalbetrieb bei 80 Prozent läuft, hat für den Ausfall eines von vier Knoten keine Reserve — sie läuft danach bei über 100 Prozent. Kapazität für den Normalbetrieb und Kapazität für den Ausfall sind zwei Rechnungen, und nur eine davon wird üblicherweise gemacht.

Wann muss entschieden werden

Szenario

Ein Dateiserververbund liegt bei 72 Prozent Belegung und wächst seit zwölf Monaten um rund zwei Prozentpunkte im Monat. Die Beschaffung neuer Datenträger dauert erfahrungsgemäß acht Wochen, der Einbau ein Wartungsfenster.

Anforderungen

Es soll nicht knapp werden.
Die Entscheidung soll begründet und nicht aus dem Bauch getroffen sein.

Schritte

Aus zwölf Monaten die monatliche Wachstumsrate bestimmen: rund zwei Prozentpunkte.
Die Zielschwelle festlegen, ab der es unangenehm wird — hier 85 Prozent.
Verbleibende Zeit rechnen: 13 Punkte geteilt durch 2 Punkte je Monat, also etwa sechseinhalb Monate.
Vorlauf abziehen: acht Wochen Beschaffung plus ein Wartungsfenster, zusammen gut zwei Monate.
Ergebnis: Die Entscheidung muss in gut vier Monaten fallen — nicht beim Erreichen einer Schwelle.

Merksatz: Eine Kapazitätswarnung bei 85 Prozent hätte hier zwei Monate zu spät gemeldet. Die Schwelle für den Alarm ergibt sich aus Wachstum und Vorlaufzeit, nicht aus einer runden Zahl.

Die Reihenfolge einer Leistungsdiagnose

Das Zeitfenster aus der Meldung bestimmen — wann genau, wie lange, wie oft?→Den Umfang bestimmen: eine Anwendung, ein Server, mehrere Server?→Messen mit einem Intervall, das kürzer ist als das Symptom.→Gegen den Normalzustand halten — ohne Vergleich ist ein Wert keine Aussage.→Die Schicht benennen, bevor eine Maßnahme gewählt wird.→Nach der Änderung im selben Zeitfenster und mit demselben Intervall nachmessen.

Schritt 6 fehlt fast immer. Eine Maßnahme ohne Nachmessung ist eine Vermutung mit Rechnung.

Was diese Sorgfalt kostetSie dauert länger als der Griff zu mehr Arbeitsspeicher, und bei einem akuten Ausfall ist der schnelle Griff manchmal richtig. Der Unterschied ist, ob man ihn als Sofortmaßnahme benennt und die Diagnose nachholt — oder ob man ihn für die Lösung hält. Im zweiten Fall wiederholt sich derselbe Vorgang beim nächsten Mal, nur mit mehr Hardware.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität9 Primärquellen · zuletzt geprüft: 2026-09-04