4.10 Ressourcenengpässe erkennen

Beispiel:

CPU-Auslastung: 95 %
Antwortzeit:     normal
Warteschlange:   niedrig
Fehler:          keine

Das ist hohe Auslastung, aber noch kein bewiesener Engpass.

CPU-Auslastung: 95 %
Antwortzeit:     stark erhöht
Warteschlange:   wächst
Timeouts:        vorhanden

Hier besteht ein belastbarer Hinweis auf CPU-Sättigung.

Eine Momentaufnahme kann zufällig während einer kurzen Lastspitze entstehen.

Empfohlene Messstruktur:

Zeitpunkt
CPU gesamt
CPU des Dienstprozesses
verfügbarer Arbeitsspeicher
Swap- beziehungsweise Paging-Aktivität
Datenträger-I/O und Wartezeit
Anzahl aktiver Anfragen
Anwendungsantwortzeit
Fehlerrate

Sinnvolle Vergleichszeiträume:

• unmittelbar vor der Störung,
• während der Störung,
• unmittelbar danach,
• normaler Vergleichszeitraum,
• gleiche Uhrzeit an einem störungsfreien Tag,
• Zustand vor und nach einer Maßnahme.

Ein Messwerkzeug erzeugt selbst Last. Abtastrate, Anzahl der Messwerte und Detailgrad müssen zum System passen.

Anzahl logischer Prozessoren anzeigen:

[RO] Get-CimInstance Win32_ComputerSystem |
    Select-Object NumberOfProcessors,
                  NumberOfLogicalProcessors

Gesamte CPU-Auslastung als Momentaufnahme:

[RO] Get-CimInstance `
    Win32_PerfFormattedData_PerfOS_Processor `
    -Filter "Name='_Total'" |
    Select-Object Name,
                  PercentProcessorTime,
                  PercentUserTime,
                  PercentPrivilegedTime,
                  PercentIdleTime

Mehrere Messpunkte mit Get-Counter erfassen:

[RO] Get-Counter `
    -Counter '\Processor(_Total)\% Processor Time' `
    -SampleInterval 2 `
    -MaxSamples 5

Die Namen klassischer Windows-Leistungsindikatoren können auf lokalisierten Windows-Systemen übersetzt sein. Falls ein Counterpfad nicht gefunden wird, müssen die auf diesem System vorhandenen Zählersätze ermittelt werden.

Verfügbare Zählersätze suchen:

[RO] Get-Counter -ListSet * |
    Select-Object CounterSetName |
    Sort-Object CounterSetName

Prozesse nach kumulierter CPU-Zeit sortieren:

[RO] Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Id,
                           ProcessName,
                           CPU,
                           StartTime

Die Eigenschaft CPU enthält die gesamte bisher verbrauchte Prozessorzeit des Prozesses in Sekunden. Sie ist kein momentaner Prozentwert.

Momentane Prozessauslastung über formatierte Leistungsdaten:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfProc_Process |
    Where-Object Name -NotIn "_Total", "Idle" |
    Sort-Object PercentProcessorTime -Descending |
    Select-Object -First 15 Name,
                           IDProcess,
                           PercentProcessorTime,
                           ThreadCount,
                           WorkingSetPrivate

Bestimmte PID untersuchen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  StartTime,
                  CPU,
                  Threads,
                  HandleCount

Die Prozess-CPU-Ausgabe kann bei mehreren logischen Prozessoren anders skaliert wirken als die gesamte Systemauslastung. Werte müssen im Kontext des verwendeten Messwerkzeugs interpretiert werden.

Gesamten und freien physischen Speicher anzeigen:

[RO] Get-CimInstance Win32_OperatingSystem |
    Select-Object @{
        Name="TotalRAM_GiB"
        Expression={[math]::Round($_.TotalVisibleMemorySize / 1MB, 2)}
    }, @{
        Name="FreeRAM_GiB"
        Expression={[math]::Round($_.FreePhysicalMemory / 1MB, 2)}
    }, @{
        Name="FreeVirtualMemory_GiB"
        Expression={[math]::Round($_.FreeVirtualMemory / 1MB, 2)}
    }

Die CIM-Werte werden hier von KiB in GiB umgerechnet.

Speicherindikatoren als Momentaufnahme:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory |
    Select-Object AvailableMBytes,
                  PercentCommittedBytesInUse,
                  PagesPerSec,
                  PageReadsPerSec,
                  PageWritesPerSec,
                  PoolPagedBytes,
                  PoolNonpagedBytes

Mehrere Messpunkte des verfügbaren Speichers:

[RO] Get-Counter `
    -Counter '\Memory\Available MBytes' `
    -SampleInterval 2 `
    -MaxSamples 5

Ein niedriger Wert bei „freiem“ Speicher ist nicht automatisch ein Fehler, weil Betriebssysteme ungenutzten Speicher als Cache verwenden. Verfügbarer Speicher, Paging-Aktivität und Anwendungsfunktion müssen gemeinsam betrachtet werden.

Nach Working Set sortieren:

[RO] Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Id,
                           ProcessName,
                           @{
                               Name="WorkingSet_MiB"
                               Expression={[math]::Round($_.WorkingSet64 / 1MB, 2)}
                           },
                           @{
                               Name="PrivateMemory_MiB"
                               Expression={[math]::Round($_.PrivateMemorySize64 / 1MB, 2)}
                           }

Bestimmten Prozess untersuchen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  WorkingSet64,
                  PrivateMemorySize64,
                  VirtualMemorySize64,
                  PagedMemorySize64,
                  PeakWorkingSet64

Virtueller Speicher darf nicht direkt mit physisch belegtem RAM gleichgesetzt werden.

Nutzung der Auslagerungsdatei anzeigen:

[RO] Get-CimInstance Win32_PageFileUsage |
    Select-Object Name,
                  AllocatedBaseSize,
                  CurrentUsage,
                  PeakUsage

Die Größen werden üblicherweise in MiB angegeben.

Konfiguration der Auslagerungsdatei anzeigen:

[RO] Get-CimInstance Win32_PageFileSetting |
    Select-Object Name,
                  InitialSize,
                  MaximumSize

Mögliche Hinweise auf Speicherdruck:

• PercentCommittedBytesInUse bleibt sehr hoch,
• verfügbarer Speicher bleibt niedrig,
• Page Reads steigen dauerhaft,
• Anwendungen melden fehlenden virtuellen Speicher,
• Prozesse werden beendet,
• Antwortzeiten verschlechtern sich parallel zur Paging-Aktivität.

Das Vorhandensein einer verwendeten Auslagerungsdatei ist nicht automatisch ein Fehler. Entscheidend ist eine dauerhaft hohe Paging-Aktivität zusammen mit Leistungsproblemen.

Formatierte Datenträgerleistungsdaten anzeigen:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfDisk_PhysicalDisk |
    Where-Object Name -ne "_Total" |
    Select-Object Name,
                  DiskReadsPerSec,
                  DiskWritesPerSec,
                  DiskReadBytesPerSec,
                  DiskWriteBytesPerSec,
                  AvgDiskQueueLength,
                  CurrentDiskQueueLength,
                  PercentDiskTime

Mehrere Messpunkte mit Get-Counter:

[RO] Get-Counter `
    -Counter '\PhysicalDisk(*)\Avg. Disk sec/Read',
             '\PhysicalDisk(*)\Avg. Disk sec/Write',
             '\PhysicalDisk(*)\Current Disk Queue Length' `
    -SampleInterval 2 `
    -MaxSamples 5

Auch hier können lokalisierte Leistungsindikatornamen abweichen.

Zu prüfen:

• steigt die Warteschlange dauerhaft?
• sind Lese- oder Schreiblatenzen erhöht?
• ist nur ein Datenträger betroffen?
• korreliert die I/O-Last mit dem Dienstfehler?
• erzeugt Sicherung, Virenscan oder Update gleichzeitig Last?
• ist das Volume lokal, virtuell oder netzwerkbasiert?
• meldet das System zusätzlich Datenträgerfehler?

Gesamtanzahl von Prozessen, Threads und Handles:

[RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_System |
    Select-Object Processes, Threads

[RO] Get-CimInstance Win32_PerfFormattedData_PerfOS_Objects |
    Select-Object Processes,
                  Threads,
                  Events,
                  Mutexes,
                  Sections,
                  Semaphores

Prozesse nach Handleanzahl sortieren:

[RO] Get-Process |
    Sort-Object HandleCount -Descending |
    Select-Object -First 15 Id,
                           ProcessName,
                           HandleCount,
                           @{
                               Name="ThreadCount"
                               Expression={$_.Threads.Count}
                           }

Bestimmten Prozess prüfen:

[RO] Get-Process -Id <PID> |
    Select-Object Id,
                  ProcessName,
                  HandleCount,
                  @{
                      Name="ThreadCount"
                      Expression={$_.Threads.Count}
                  }

Ein mögliches Ressourcenleck zeigt sich eher durch kontinuierliches Wachstum als durch einen einzelnen hohen Wert.

Systemereignisse der letzten zwei Stunden:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System"
    StartTime = (Get-Date).AddHours(-2)
    Level     = 1, 2, 3
} |
    Select-Object TimeCreated,
                  ProviderName,
                  Id,
                  LevelDisplayName,
                  Message

System- und Anwendungsereignisse gemeinsam:

[RO][SENS] Get-WinEvent -FilterHashtable @{
    LogName   = "System", "Application"
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object Message -Match "memory|resource|disk|paging|quota|handle|thread" |
    Sort-Object TimeCreated |
    Select-Object TimeCreated,
                  LogName,
                  ProviderName,
                  Id,
                  Message

Textfilter hängen von Sprache und Formulierung der Ereignismeldung ab. Anbieter, Ereignis-ID und Zeitfenster sind zuverlässigere zusätzliche Filter.

Systemlaufzeit und Load Average anzeigen:

[RO] uptime

Nur Load Average anzeigen:

[RO][FILE] cat /proc/loadavg

Anzahl verfügbarer Verarbeitungseinheiten anzeigen:

[RO] nproc

Interaktive Prozessübersicht:

[RO] top

Nach CPU-Verbrauch sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm \
  --sort=-%cpu |
  head -n 16

Falls sysstat installiert ist – CPU je Prozessor messen:

[RO] mpstat -P ALL 2 5

mpstat, pidstat und iostat gehören häufig zum Paket sysstat, sind aber nicht auf jeder Installation vorhanden.

Die drei Load-Average-Werte beziehen sich üblicherweise auf ungefähr:

1 Minute
5 Minuten
15 Minuten

Load Average ist nicht dasselbe wie CPU-Prozent. Unter Linux werden dabei auch bestimmte Prozesse in nicht unterbrechbarem Wartezustand berücksichtigt.

Grobe Einordnung:

Load Average
geteilt durch
Anzahl verfügbarer CPUs

Dies ist nur eine Orientierung.

Ein Load-Wert von 4 ist auf einem System mit zwei CPUs anders zu bewerten als auf einem System mit 32 CPUs.

Systemweite Messreihe mit vmstat:

[RO] vmstat 2 5

Wichtige Spalten:

Die erste Zeile von vmstat kann Durchschnittswerte seit dem Systemstart darstellen. Für eine aktuelle Bewertung sind die folgenden Intervallzeilen wichtiger.

Bestimmten Prozess mit installiertem pidstat beobachten:

[RO] pidstat -p <PID> 2 5

Alle Prozesse mit hoher CPU-Aktivität beobachten:

[RO] pidstat -u 2 5

Lesbare Speicherübersicht:

[RO] free -h

Kernel-Speicherinformationen:

[RO][FILE] cat /proc/meminfo

Wichtige Werte:

Für die praktische Bewertung ist MemAvailable meist aussagekräftiger als MemFree, weil Linux freien RAM bewusst als Cache nutzt.

Nach residentem Speicher sortieren:

[RO] ps -eo pid,ppid,user,stat,%cpu,%mem,rss,vsz,etime,comm \
  --sort=-rss |
  head -n 16

Bestimmten Prozess anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,stat,%cpu,%mem,rss,vsz,etime,cmd

Detaillierte Prozessspeicherwerte:

[RO][FILE][SENS] cat "/proc/<PID>/status"

Relevant sind unter anderem:

VmPeak
VmSize
VmHWM
VmRSS
RssAnon
RssFile
VmSwap
Threads

Aktive Swap-Bereiche anzeigen:

[RO] swapon --show

Gesamtnutzung anzeigen:

[RO] free -h

Swap-Aktivität über mehrere Messpunkte:

[RO] vmstat 2 5

Relevant:

Bewertung:

• verwendeter Swap allein beweist keinen aktuellen Engpass,
• dauerhaft hohe Werte bei si und so weisen auf aktiven Speicherdruck hin,
• gleichzeitige hohe I/O-Wartezeit kann die Anwendung stark verlangsamen,
• einzelne Prozesse können einen großen Teil des Speichers belegen,
• ein Container kann sein eigenes Speicherlimit erreichen, obwohl der Host noch freien RAM besitzt.

Grundlegende Datenträgerstatistik:

[RO] iostat

Falls sysstat installiert ist – erweiterte Messreihe:

[RO] iostat -xz 2 5

Wichtige Felder können je nach Version enthalten:

Prozessbezogene I/O-Aktivität mit pidstat:

[RO] pidstat -d 2 5

%util und Warteschlangenwerte müssen zur Datenträgerart und Speicherarchitektur passend bewertet werden. RAID, SSD, SAN und virtuelle Datenträger verhalten sich unterschiedlich.

Auf unterstützten Linux-Kernels stehen Druckinformationen unter /proc/pressure bereit.

CPU-Druck:

[RO][FILE] cat /proc/pressure/cpu

Speicherdruck:

[RO][FILE] cat /proc/pressure/memory

I/O-Druck:

[RO][FILE] cat /proc/pressure/io

Mögliche Zeilen:

some
full

Fehlen die Dateien, unterstützt oder aktiviert das System diese Schnittstelle möglicherweise nicht.

Grenzwerte eines laufenden Prozesses:

[RO][FILE] cat "/proc/<PID>/limits"

Besonders relevant:

Max open files
Max processes
Max locked memory
Max address space
Max core file size

Anzahl geöffneter Dateideskriptoren:

[RO][PRIV] sudo find "/proc/<PID>/fd" \
  -mindepth 1 \
  -maxdepth 1 \
  -printf '.' |
    wc -c

systemd-Grenzwerte anzeigen:

[RO] systemctl show "<DIENST>" \
  --property=LimitNOFILE,LimitNPROC,TasksCurrent,TasksMax,MemoryCurrent,MemoryMax,CPUQuotaPerSecUSec

Aktuelle Shell-Grenzen anzeigen:

[RO] ulimit -a

ulimit -a zeigt die Grenzen der aktuellen Shell und nicht automatisch die Grenzen eines bereits laufenden Dienstes.

Warnungen und Fehler des aktuellen Systemstarts:

[RO][SENS][PRIV] sudo journalctl \
  -b \
  -p warning \
  --no-pager

Kernelmeldungen nach Speicherproblemen durchsuchen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  --no-pager |
    grep -i -E -- "out of memory|oom|killed process|memory cgroup"

Nach I/O- und Dateisystemproblemen suchen:

[RO][SENS][PRIV] sudo journalctl \
  -k \
  -b \
  --no-pager |
    grep -i -E -- "i/o error|filesystem|read-only|blocked for more than"

Dienstprotokoll im Störungszeitraum:

[RO][SENS][PRIV] sudo journalctl \
  -u "<DIENST>" \
  --since "2026-07-31 09:10:00" \
  --until "2026-07-31 09:20:00" \
  --no-pager

Systemlaufzeit und Load Average:

[RO] uptime

Logische und physische CPUs:

[RO] sysctl -n hw.logicalcpu

[RO] sysctl -n hw.physicalcpu

Interaktive Übersicht nach CPU-Nutzung:

[RO] top -o cpu

Fünf Messungen im Abstand von zwei Sekunden:

[RO] top \
  -l 5 \
  -s 2 \
  -o cpu \
  -stats pid,command,cpu,mem,threads,state,time

Bestimmten Prozess beobachten:

[RO] top \
  -l 5 \
  -s 2 \
  -pid <PID> \
  -stats pid,command,cpu,mem,threads,state,time

Bei top -l kann die erste CPU-Messung ungeeignet sein, weil zur Prozentberechnung noch kein vollständiges vorheriges Intervall vorliegt.

Speicherdruck anzeigen:

[RO] memory_pressure

Virtuelle Speicherstatistik:

[RO] vm_stat

Gesamten physischen Speicher anzeigen:

[RO] sysctl -n hw.memsize

Swap-Nutzung anzeigen:

[RO] sysctl vm.swapusage

Prozesse nach Speicherverbrauch sortieren:

[RO] ps -Amcwwxo pid,ppid,user,state,%cpu,%mem,rss,vsz,etime,command

Bestimmten Prozess anzeigen:

[RO][SENS] ps -p <PID> \
  -o user,pid,ppid,state,%cpu,%mem,rss,vsz,etime,command

macOS verwaltet Arbeitsspeicher unter anderem durch Cache, Kompression und Swap. „Freier Speicher“ allein ist deshalb weniger aussagekräftig als Speicherdruck, Swap-Aktivität und Anwendungsreaktion.

vm_stat zeigt Speicherwerte in Seiten an. Die Seitengröße wird in der ersten Ausgabezeile genannt.

Wichtige Werte können sein:

Viele Werte sind kumuliert seit dem Systemstart. Für aktuelle Aktivität müssen Messungen über einen definierten Zeitraum verglichen werden.

Datenträgerübersicht:

[RO] iostat

Fünf Messungen im Abstand von zwei Sekunden:

[RO] iostat -w 2 -c 5

CPU- und Datenträgerstatistik ausführlicher anzeigen:

[RO] iostat -d -c 5 -w 2

Prozessbezogene Beobachtung mit top:

[RO] top \
  -l 5 \
  -s 2 \
  -o cpu \
  -stats pid,command,cpu,mem,purg,cmprs,pageins,faults

Zu prüfen:

• steigt Datenträgeraktivität während der Störung?
• tritt gleichzeitig Speicherdruck auf?
• verursacht ein anderer Prozess hohe I/O-Last?
• ist das Ziel ein internes, externes oder Netzwerkvolume?
• gibt es Dateisystem- oder Hardwaremeldungen?
• wird gleichzeitig gesichert, indiziert oder aktualisiert?

Grenzwerte von launchd anzeigen:

[RO] launchctl limit

Grenzwerte der aktuellen Shell anzeigen:

[RO] ulimit -a

Offene Ressourcen eines Prozesses anzeigen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID>

Anzahl der ausgegebenen offenen Ressourcen grob zählen:

[RO][SENS][PRIV] sudo lsof -nP -p <PID> |
    wc -l

Die Kopfzeile von lsof wird dabei mitgezählt.

Threadanzahl anzeigen:

[RO] ps -M -p <PID>

Die Grenzwerte einer Shell sind nicht automatisch mit denen eines launchd-Dienstes identisch. Für den Dienst müssen launchd-Konfiguration, Prozesskontext und tatsächlicher Verbrauch berücksichtigt werden.

Fehler und Faults der letzten Stunde:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'messageType == error OR messageType == fault' \
  --style compact \
  --no-pager

Dienstprozess filtern:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'process == "<PROZESS>"' \
  --style compact \
  --no-pager

Nach ressourcenbezogenen Meldungstexten suchen:

[RO][SENS][PRIV] sudo log show \
  --last 1h \
  --predicate 'eventMessage CONTAINS[c] "memory" OR eventMessage CONTAINS[c] "resource" OR eventMessage CONTAINS[c] "disk"' \
  --style compact \
  --no-pager

Textfilter sind nur eine Ergänzung. Prozess, Zeitfenster, Subsystem und konkrete Fehlermeldung müssen ebenfalls berücksichtigt werden.

Belastbare Hinweise:

• CPU-Auslastung bleibt über längere Zeit hoch,
• ausführungsbereite Prozesse warten,
• Antwortzeiten steigen gleichzeitig,
• Anwendungswarteschlange wächst,
• Timeouts treten auf,
• ein bestimmter Prozess oder Thread verursacht den Großteil der Last,
• virtueller Host meldet hohe CPU-Steal- oder Ready-Zeit,
• CPU-Limit eines Containers wird erreicht.

Mögliche Ursachen:

• regulär hohe Benutzerlast,
• Endlosschleife,
• fehlerhafte Abfrage,
• Kompression oder Verschlüsselung,
• Virenscan,
• Sicherung,
• Softwareupdate,
• zu viele Prozesse oder Threads,
• zu niedriges Containerlimit,
• fehlende Hardwarebeschleunigung.

Nicht ausreichend als Beweis:

Ein einzelner Messwert von 100 %

Belastbare Hinweise:

• verfügbarer Speicher bleibt dauerhaft niedrig,
• Paging oder Swapping ist kontinuierlich aktiv,
• Speicherdruck steigt,
• Antwortzeiten steigen parallel,
• Prozesse werden durch Speichermangel beendet,
• Anwendung meldet Allokationsfehler,
• Prozessspeicher wächst kontinuierlich,
• Container erreicht MemoryMax oder sein Plattformlimit,
• Cache kann nicht ausreichend zurückgewonnen werden.

Mögliche Ursachen:

• Speicherleck,
• zu großer Cache,
• unerwartet viele Sitzungen,
• zu große Datenmenge,
• mehrere speicherintensive Dienste,
• zu kleines VM- oder Containerlimit,
• fehlerhafte Heap-Konfiguration,
• fehlende Begrenzung von Workerprozessen.

Ein Dienstneustart kann den Speicherverbrauch kurzfristig reduzieren, beweist aber nicht, dass die Ursache beseitigt wurde.

Belastbare Hinweise:

• I/O-Wartezeiten steigen,
• Warteschlange bleibt gefüllt,
• Prozesse verbleiben im Wartezustand,
• Datenbankabfragen werden langsam,
• Schreibvorgänge blockieren,
• gleichzeitig erscheinen I/O- oder Dateisystemfehler,
• Netzwerkstorage zeigt hohe Latenz,
• Sicherung oder Indizierung erzeugt konkurrierende Last.

Mögliche Ursachen:

• langsamer oder fehlerhafter Datenträger,
• RAID-Rebuild,
• defekter Datenträger,
• überlastetes SAN oder NAS,
• hoher Speicherdruck und Paging,
• ungeeignete Datenbankabfrage,
• fehlender Cache,
• Sicherung oder Virenscan,
• zu viele parallele Schreibvorgänge,
• Volume- oder IOPS-Limit einer Cloudplattform.

Hoher Datendurchsatz kann normal sein. Ein Engpass zeigt sich durch Wartezeit, Warteschlange und beeinträchtigte Anwendung.

Ein Ressourcenleck wird durch eine Zeitreihe sichtbar.

Mögliche Lecks:

• Arbeitsspeicher,
• Handles,
• Dateideskriptoren,
• Threads,
• Netzwerkverbindungen,
• temporäre Dateien,
• Datenbankverbindungen,
• Warteschlangeneinträge.

Typisches Muster:

Dienststart          niedriger Verbrauch
nach 1 Stunde        höherer Verbrauch
nach 6 Stunden       weiter gestiegen
nach 24 Stunden      Grenzwert erreicht
nach Dienstneustart  wieder niedriger Verbrauch

Nachweisstrategie:

1. gleiche Messgröße verwenden,
2. regelmäßige Zeitpunkte erfassen,
3. Last und Benutzerzahl mit dokumentieren,
4. Prozessneustarts berücksichtigen,
5. Grenzwert und Fehlereintritt bestimmen,
6. Herstellerdiagnose oder Profiler kontrolliert einsetzen.

Wachstum kann durch einen vorgesehenen Cache entstehen. Ein Leck ist erst wahrscheinlich, wenn Ressourcen trotz abgeschlossener Arbeit nicht angemessen freigegeben werden und der Verbrauch problematisch weiter steigt.

Ein Gastbetriebssystem kann normale Hostwerte anzeigen, obwohl die Virtualisierungsplattform Ressourcen begrenzt.

Zu prüfen:

• zugewiesene virtuelle CPUs,
• CPU-Limit oder CPU-Anteile,
• CPU-Steal- beziehungsweise Ready-Zeit,
• zugesicherter und maximaler RAM,
• Memory Ballooning,
• Host-Swapping,
• IOPS- und Durchsatzlimits,
• Container-CPU-Quota,
• Container-Speicherlimit,
• Prozess- beziehungsweise PID-Limit,
• gemeinsam verwendete Hostressourcen,
• konkurrierende virtuelle Maschinen oder Container.

Typische Fehlinterpretation:

„Der Host hat noch freien RAM, deshalb kann der Container keinen Speichermangel haben.“

Ein Container kann sein eigenes Limit erreichen, obwohl der Host noch freie Ressourcen besitzt.

Diese Matrix ist eine Eingrenzungshilfe und kein automatischer Ursachenbeweis.

Störung:
Server:
Dienst:
Prozess und PID:
Betriebssystem:
Virtualisiert beziehungsweise containerisiert:
Messzeitraum:
Abtastintervall:
CPU gesamt:
CPU des Prozesses:
Load Average:
Verfügbarer Arbeitsspeicher:
Speicher des Prozesses:
Swap- beziehungsweise Paging-Aktivität:
Datenträgerlatenz:
Datenträgerwarteschlange:
Dateideskriptor- beziehungsweise Handleanzahl:
Threadanzahl:
Konfigurierte Limits:
Anwendungsantwortzeit:
Fehlerrate:
Gleichzeitige Benutzer oder Aufgaben:
Relevante Protokollmeldung:
Vergleichswert:
Bewertung:
Nächster Prüfschritt:

[ ] Störungszeitraum genau bestimmt
[ ] System- und Prozesswerte getrennt erfasst
[ ] Mehrere Messpunkte aufgenommen
[ ] Normalen Vergleichszeitraum bestimmt
[ ] Anzahl logischer CPUs berücksichtigt
[ ] CPU-Auslastung und Warteschlange geprüft
[ ] Load Average richtig eingeordnet
[ ] Verfügbaren Arbeitsspeicher geprüft
[ ] Prozessspeicher geprüft
[ ] Paging beziehungsweise Swapping geprüft
[ ] Speicherdruck berücksichtigt
[ ] Datenträgerdurchsatz geprüft
[ ] I/O-Wartezeit und Warteschlange geprüft
[ ] Speicherplatz und Dateisystem grob geprüft
[ ] Handle- beziehungsweise Dateideskriptoranzahl geprüft
[ ] Thread- und Prozessgrenzen geprüft
[ ] Ressourcenlecks über Zeitreihe geprüft
[ ] Betriebssystemprotokolle geprüft
[ ] Anwendungsprotokolle geprüft
[ ] VM- und Containerlimits berücksichtigt
[ ] Gleichzeitige Sicherungen und Updates berücksichtigt
[ ] Messwerte mit Antwortzeit und Fehlerrate korreliert
[ ] Noch keine ungeprüfte Limitänderung durchgeführt
[ ] Ursache und nächster Schritt dokumentiert