# 7.8 Server ist langsam

**Ziel dieser Seite**

Diese Seite beschreibt die systematische Fehleranalyse, wenn ein Server oder ein darauf bereitgestellter Dienst ungewöhnlich langsam reagiert.

Dabei muss zwischen verschiedenen Ursachen unterschieden werden:

- CPU-Auslastung,
- Arbeitsspeichermangel,
- Paging oder Swapping,
- langsamer Datenträger,
- hohe Datenträgerlatenz,
- Netzwerkprobleme,
- überlastete Anwendung,
- Datenbanksperren,
- Hintergrundjobs,
- Hypervisor-Engpässe,
- externe Abhängigkeiten.

> „Der Server ist langsam“ ist lediglich eine Symptombeschreibung. Erst durch Messwerte lässt sich bestimmen, welche Ressource oder Abhängigkeit den Engpass verursacht.

---

**1. Problem exakt beschreiben**

Vor der technischen Analyse müssen Soll- und Istzustand dokumentiert werden.

| Angabe | Beispiel |
|---|---|
| betroffener Server | `SRV-APP01` |
| betroffener Dienst | interne Webanwendung |
| Symptom | Seitenaufbau dauert 15 Sekunden |
| Normalzustand | unter 2 Sekunden |
| Beginn | 02.08.2026, etwa 09:15 Uhr |
| Umfang | alle Benutzer |
| Häufigkeit | zeitweise |
| letzter funktionierender Zustand | vor dem nächtlichen Backup |
| letzte Änderung | Anwendungsupdate |
| Vergleichssystem | `SRV-APP02` reagiert normal |

Zu klären ist:

- Ist der gesamte Server langsam oder nur eine Anwendung?
- Sind alle Benutzer betroffen?
- Tritt das Problem lokal und über das Netzwerk auf?
- Sind nur bestimmte Funktionen betroffen?
- Besteht das Problem dauerhaft oder nur zu bestimmten Zeiten?
- Trat das Problem nach einer Änderung auf?
- Sind weitere Server betroffen?
- Gibt es ein funktionierendes Vergleichssystem?
- Wie wird die Verzögerung gemessen?
- Welche Antwortzeit gilt als normal?

Die Aussage „der Server ist langsam“ reicht für eine gezielte Fehleranalyse nicht aus.

---

**2. Server-, Anwendungs- und Netzwerkproblem unterscheiden**

Ein langsamer Dienst beweist nicht automatisch, dass der Server selbst überlastet ist.

```text
Client
  ↓
DNS
  ↓
Netzwerk
  ↓
Firewall oder Proxy
  ↓
Webserver
  ↓
Anwendung
  ↓
Datenbank
  ↓
Storage
```

Jede dieser Komponenten kann die beobachtete Verzögerung verursachen.

| Beobachtung | Wahrscheinlicher Prüfbereich |
|---|---|
| lokale Bedienung ebenfalls langsam | Serverressourcen oder Betriebssystem |
| nur entfernte Zugriffe langsam | Netzwerk, VPN, Firewall oder Proxy |
| nur eine Anwendung langsam | Anwendung, Datenbank oder Abhängigkeit |
| alle Dienste langsam | CPU, RAM, Storage, Hypervisor oder Netzwerk |
| nur bestimmte Abfragen langsam | Datenbank, Sperren oder fehlende Indizes |
| nur zu festen Uhrzeiten langsam | Backup, Scan, Wartung oder geplanter Job |
| nur eine VM betroffen | VM-Konfiguration oder Gastbetriebssystem |
| mehrere VMs auf demselben Host betroffen | Hypervisor oder gemeinsames Storage |
| Ping normal, Anwendung langsam | Dienst, TLS, Authentifizierung oder Backend |
| Ping langsam oder instabil | Netzwerkpfad oder Serverüberlastung |
| Zugriff per IP schnell, per Name langsam | DNS-Auflösung |
| Anmeldung langsam, Dienste danach normal | Authentifizierung, GPO, Profil oder DNS |

---

**3. Auswirkungen und Priorität bestimmen**

Vor der tieferen Analyse muss die betriebliche Auswirkung bewertet werden.

Zu klären ist:

- Ist ein geschäftskritischer Dienst betroffen?
- Können Benutzer noch eingeschränkt arbeiten?
- Sind Datenverlust oder Folgefehler möglich?
- Betrifft das Problem einen oder mehrere Standorte?
- Verschlechtert sich der Zustand weiter?
- Gibt es ein funktionierendes Ersatzsystem?
- Besteht eine vereinbarte Reaktions- oder Wiederherstellungszeit?

Beispiel:

| Kriterium | Bewertung |
|---|---|
| Auswirkung | alle Mitarbeiter können nur verzögert arbeiten |
| Dringlichkeit | hoch |
| Priorität | hoch |
| Ersatzlösung | zweiter Anwendungsserver vorhanden |
| Datenverlust | derzeit nicht erkennbar |
| Eskalation | Anwendungs- und Infrastrukturteam informieren |

Eine hohe Auslastung ist nicht automatisch ein kritischer Vorfall. Entscheidend ist, ob der vereinbarte Dienst beeinträchtigt wird.

---

**4. Ausgangszustand sichern**

Vor einem Neustart oder einer Konfigurationsänderung sollten flüchtige Informationen gesichert werden:

- genaue Uhrzeit mit Zeitzone,
- CPU-Auslastung,
- CPU-Auslastung pro Prozess,
- Arbeitsspeicherbelegung,
- Paging- oder Swap-Aktivität,
- Datenträgerauslastung,
- Datenträgerlatenz,
- Warteschlangen,
- Netzwerkfehler,
- aktive Verbindungen,
- Prozess- und Dienststatus,
- Eventlogs oder Journal,
- Anwendungslogs,
- Datenbankstatus,
- Hypervisorwerte,
- laufende Jobs,
- letzte Änderungen.

Ein Neustart kann das Symptom vorübergehend beseitigen, vernichtet aber möglicherweise den für die Ursachenanalyse benötigten Zustand.

Vor einer Maßnahme sollte daher mindestens dokumentiert werden:

```text
Zeitpunkt:
betroffener Dienst:
gemessene Antwortzeit:
CPU:
RAM:
Datenträger:
Netzwerk:
auffälliger Prozess:
auffälliges Ereignis:
laufender Hintergrundjob:
letzte Änderung:
```

---

**5. Sichere Schnellprüfung**

Die erste Prüfung sollte möglichst nur lesend erfolgen.

1. Zeitpunkt und Umfang der Störung bestimmen.
2. CPU, RAM, Datenträger und Netzwerk gleichzeitig betrachten.
3. Prozesse mit ungewöhnlicher Ressourcennutzung ermitteln.
4. Backups, Virenscans, Snapshots und Wartungsjobs prüfen.
5. Betriebssystem-, Anwendungs- und Hypervisorlogs zeitlich vergleichen.
6. Antwortzeit vom Client und direkt auf dem Server messen.
7. Mit einem funktionierenden Vergleichssystem vergleichen.
8. Erst danach eine kontrollierte Maßnahme auswählen.

Windows:

```powershell
Get-Date

Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 10 Name, Id, CPU, WorkingSet64
```

Linux:

```bash
date
uptime
top
```

Diese Momentaufnahmen reichen noch nicht für eine vollständige Bewertung. Kurze Spitzen oder zeitweise auftretende Fehler können dabei unentdeckt bleiben.

---

**6. CPU-Auslastung untersuchen**

Eine hohe CPU-Auslastung kann durch einen einzelnen Prozess, mehrere konkurrierende Prozesse oder eine zu geringe bereitgestellte Rechenleistung verursacht werden.

Zu prüfen sind:

- gesamte CPU-Auslastung,
- Auslastung einzelner Kerne,
- Auslastung pro Prozess und Thread,
- Dauer der Auslastung,
- System- und Benutzerzeit,
- Interrupts,
- virtuelle CPU-Bereitstellung,
- CPU-Wartezeiten des Hypervisors,
- CPU-Limits oder Drosselung.

Windows:

```powershell
Get-Counter '\Processor(_Total)\% Processor Time'
```

Prozesse nach gesamter CPU-Zeit sortieren:

```powershell
Get-Process |
    Sort-Object CPU -Descending |
    Select-Object -First 15 Name, Id, CPU, Threads
```

Aktuelle Prozessorauslastung über CIM:

```powershell
Get-CimInstance Win32_Processor |
    Select-Object Name, LoadPercentage
```

Linux:

```bash
top
```

Mit installiertem Paket `sysstat`:

```bash
pidstat 1
```

Auslastung pro logischer CPU:

```bash
mpstat -P ALL 1
```

| Befund | Mögliche Bedeutung |
|---|---|
| ein Prozess belegt dauerhaft einen Kern | Single-Thread-Engpass oder Endlosschleife |
| alle Kerne dauerhaft stark ausgelastet | CPU-Sättigung |
| hohe Systemzeit | Kernel, Treiber, Netzwerk oder I/O prüfen |
| viele Interrupts | Netzwerk- oder Hardwareproblem möglich |
| CPU im Gast niedrig, Anwendung trotzdem langsam | Storage, Netzwerk, Sperren oder Hypervisor prüfen |
| mehrere VMs gleichzeitig langsam | Hostüberlastung oder CPU-Scheduling prüfen |
| kurze regelmäßige Spitzen | geplanter Job, Scan oder Monitoring |
| Prozess-CPU steigt ständig | fehlerhafte Anwendung oder unpassende Last |

Eine Gesamtauslastung von beispielsweise 25 Prozent schließt einen CPU-Engpass nicht aus. Auf einem System mit vier logischen Prozessoren kann ein einzelner vollständig ausgelasteter Thread ungefähr 25 Prozent Gesamtauslastung verursachen.

---

**7. Arbeitsspeicher untersuchen**

Ein hoher belegter Arbeitsspeicher ist nicht automatisch ein Fehler. Betriebssysteme verwenden verfügbaren Speicher beispielsweise für Caches.

Entscheidend sind:

- verfügbarer Arbeitsspeicher,
- Auslagerungsaktivität,
- Speicherdruck,
- Arbeitsspeicher pro Prozess,
- Page Faults,
- Kernel- oder Pool-Speicher,
- zeitliche Entwicklung,
- Speicherlimits einer VM oder eines Containers.

Windows:

```powershell
Get-CimInstance Win32_OperatingSystem |
    Select-Object TotalVisibleMemorySize,
                  FreePhysicalMemory
```

Prozesse nach Arbeitsspeicher sortieren:

```powershell
Get-Process |
    Sort-Object WorkingSet64 -Descending |
    Select-Object -First 15 Name,
                            Id,
                            WorkingSet64,
                            PagedMemorySize64
```

Leistungsindikatoren abfragen:

```powershell
Get-Counter `
    '\Memory\Available MBytes',
    '\Memory\Pages/sec'
```

Linux:

```bash
free -h
```

Ausführlichere Anzeige:

```bash
vmstat 1
```

Prozesse nach Speichernutzung sortieren:

```bash
ps aux --sort=-%mem | head
```

| Befund | Mögliche Bedeutung |
|---|---|
| wenig freier Speicher, aber keine Auslagerung | nicht zwingend problematisch |
| dauerhaft starke Paging- oder Swap-Aktivität | Arbeitsspeicherengpass |
| ein Prozess wächst kontinuierlich | mögliches Speicherleck |
| Anwendung erreicht festgelegtes Limit | Container-, VM- oder Prozesslimit prüfen |
| Server wird nach längerer Laufzeit langsamer | Speicherleck oder zunehmender Cache möglich |
| OOM-Ereignis unter Linux | Speicher war erschöpft |
| hoher Commit-Wert unter Windows | zugesicherter virtueller Speicher prüfen |

Nur den belegten Arbeitsspeicher zu betrachten, reicht nicht aus. Besonders Paging, Swap und die zeitliche Entwicklung sind entscheidend.

---

**8. Datenträger und Storage untersuchen**

Ein langsamer Datenträger kann den gesamten Server ausbremsen, obwohl CPU und Arbeitsspeicher unauffällig erscheinen.

Zu prüfen sind:

- Datenträgerlatenz,
- Lese- und Schreibraten,
- Warteschlangenlänge,
- IOPS,
- freier Speicherplatz,
- Dateisystemfehler,
- RAID-Zustand,
- SAN- oder NAS-Verbindung,
- Snapshot-Aktivität,
- Backup-Aktivität,
- Storage-Überbelegung,
- Zustand physischer Datenträger.

Windows-Leistungsindikatoren:

```powershell
Get-Counter `
    '\PhysicalDisk(_Total)\Avg. Disk sec/Read',
    '\PhysicalDisk(_Total)\Avg. Disk sec/Write',
    '\PhysicalDisk(_Total)\Current Disk Queue Length',
    '\PhysicalDisk(_Total)\Disk Reads/sec',
    '\PhysicalDisk(_Total)\Disk Writes/sec'
```

Freien Speicherplatz prüfen:

```powershell
Get-Volume |
    Select-Object DriveLetter,
                  FileSystemLabel,
                  FileSystem,
                  Size,
                  SizeRemaining
```

Linux:

```bash
df -h
```

Blockgeräte anzeigen:

```bash
lsblk
```

I/O-Auslastung mit installiertem `sysstat`:

```bash
iostat -xz 1
```

Prozesse mit I/O-Aktivität:

```bash
pidstat -d 1
```

| Befund | Mögliche Bedeutung |
|---|---|
| hohe Latenz bei geringer Datenrate | langsames oder blockiertes Storage |
| Warteschlange wächst dauerhaft | Datenträger kann Anfragen nicht schnell genug verarbeiten |
| freier Speicherplatz nahezu erschöpft | Dateisystem, Datenbank oder Anwendung beeinträchtigt |
| mehrere VMs gleichzeitig betroffen | gemeinsames Storage prüfen |
| Problem während eines Backups | konkurrierende I/O-Last |
| hohe I/O-Wartezeit unter Linux | Prozesse warten auf Storage |
| RAID degradiert | Leistung und Ausfallsicherheit reduziert |
| Snapshot wächst stark | zusätzliche Storage-Belastung möglich |

Allgemeine Grenzwerte dürfen nur als Orientierung verwendet werden. Ob eine Latenz problematisch ist, hängt vom Speichermedium, der Anwendung und den vereinbarten Leistungswerten ab.

---

**9. Netzwerk untersuchen**

Ein Netzwerkproblem kann aus Benutzersicht wie ein langsamer Server wirken.

Zu prüfen sind:

- Paketverlust,
- Latenz,
- Schwankungen der Latenz,
- DNS-Auflösung,
- Duplex- oder Geschwindigkeitsfehler,
- Interfacefehler,
- Überlastung,
- VPN,
- Firewall,
- Proxy,
- Load Balancer,
- Routing,
- MTU-Probleme,
- viele oder erschöpfte Verbindungen.

Windows:

```powershell
Test-Connection SRV-APP01 -Count 10
```

TCP-Port prüfen:

```powershell
Test-NetConnection SRV-APP01 -Port 443
```

Netzwerkadapter anzeigen:

```powershell
Get-NetAdapter |
    Select-Object Name,
                  Status,
                  LinkSpeed,
                  MacAddress
```

Adapterstatistiken:

```powershell
Get-NetAdapterStatistics
```

Aktive TCP-Verbindungen:

```powershell
Get-NetTCPConnection |
    Group-Object State |
    Sort-Object Count -Descending
```

Linux:

```bash
ping -c 10 srv-app01
```

Route untersuchen:

```bash
traceroute srv-app01
```

Socketübersicht:

```bash
ss -s
```

Interfaceinformationen:

```bash
ip -s link
```

DNS-Auflösung prüfen:

```bash
dig srv-app01.example.local
```

| Befund | Mögliche Bedeutung |
|---|---|
| Paketverlust | Überlastung, fehlerhafter Link oder Routingproblem |
| schwankende Latenz | Überlastung oder instabiler Netzwerkpfad |
| Zugriff per IP schnell, per Name langsam | DNS prüfen |
| nur VPN-Benutzer betroffen | VPN-Gateway, Tunnel oder Internetverbindung |
| Fehlerzähler steigen | Kabel, Port, Treiber oder Netzwerkkarte |
| Anwendung lokal schnell, entfernt langsam | Netzwerkpfad, Proxy oder Firewall |
| nur große Übertragungen problematisch | MTU, Bandbreite oder Paketverlust prüfen |
| viele Verbindungen im Wartezustand | Anwendung, Netzwerk oder Porterschöpfung |

Ein erfolgreicher Ping beweist nur eingeschränkt die Funktionsfähigkeit. Er prüft nicht automatisch den eigentlichen Anwendungsport oder die Antwortzeit des Dienstes.

---

**10. DNS untersuchen**

Langsame oder fehlerhafte Namensauflösung kann viele Serverdienste beeinträchtigen.

Typische Auswirkungen:

- langsame Anmeldung,
- verzögerte Verbindungen,
- Authentifizierungsprobleme,
- lange Wartezeiten beim Zugriff auf andere Server,
- langsame Datenbankverbindungen,
- Verzögerungen bei Reverse-Lookups.

Windows:

```powershell
Resolve-DnsName SRV-DB01
```

Konfigurierte DNS-Server:

```powershell
Get-DnsClientServerAddress
```

DNS-Zwischenspeicher:

```powershell
Get-DnsClientCache
```

Linux:

```bash
resolvectl status
```

Namensauflösung messen:

```bash
time getent hosts srv-db01.example.local
```

Mit `dig`:

```bash
dig srv-db01.example.local
```

Zu prüfen sind:

- korrekte DNS-Server,
- Antwortzeit,
- Forward- und Reverse-Auflösung,
- fehlerhafte oder veraltete Einträge,
- Suchdomänen,
- Erreichbarkeit der DNS-Server,
- unnötige Abfragen an externe DNS-Server.

---

**11. Prozesse und Dienste untersuchen**

Nicht jede hohe Ressourcennutzung ist die Ursache. Der auffällige Prozess kann selbst nur auf eine andere Komponente warten.

Windows-Dienste:

```powershell
Get-Service |
    Where-Object Status -eq 'Running'
```

Automatisch startende, aber nicht laufende Dienste:

```powershell
Get-CimInstance Win32_Service |
    Where-Object {
        $_.StartMode -eq 'Auto' -and
        $_.State -ne 'Running'
    } |
    Select-Object Name, DisplayName, State, StartMode
```

Linux-Dienste:

```bash
systemctl --failed
```

Status eines Dienstes:

```bash
systemctl status nginx
```

Zu prüfen sind:

- ungewöhnlich hohe CPU- oder Speichernutzung,
- häufige Dienstneustarts,
- Prozesse im Warte- oder Blockierungszustand,
- sehr viele Threads,
- sehr viele offene Dateien,
- abgestürzte Unterprozesse,
- lange Warteschlangen,
- Ressourcenlimits,
- fehlerhafte Abhängigkeiten.

Ein Dienstneustart sollte erst erfolgen, nachdem relevante Messwerte und Protokolle gesichert wurden.

---

**12. Anwendung untersuchen**

Wenn nur eine Anwendung langsam ist, muss deren interner Ablauf betrachtet werden.

Mögliche Ursachen:

- fehlerhafte Konfiguration,
- zu wenige Worker oder Threads,
- zu kleine Verbindungspools,
- blockierte Warteschlangen,
- langsame Datenbankabfragen,
- nicht erreichbare externe Dienste,
- Authentifizierungsprobleme,
- Cachefehler,
- unzureichende Ressourcenlimits,
- fehlerhaftes Update,
- wachsendes Log- oder temporäres Verzeichnis.

Zu prüfen sind:

- Antwortzeit einzelner Funktionen,
- Anwendungslogs,
- Fehler- und Zeitüberschreitungen,
- Anzahl aktiver Sitzungen,
- Thread- oder Worker-Auslastung,
- Warteschlangenlänge,
- Cachetreffer,
- Verbindungspools,
- interne Gesundheitsprüfungen,
- Abhängigkeiten.

Beispielhafte Abgrenzung:

```text
Startseite schnell
Suchfunktion langsam
        ↓
Suchfunktion getrennt untersuchen
        ↓
Anwendungslog und Datenbankabfrage vergleichen
```

Nicht sofort den gesamten Server neu starten, wenn nur ein einzelner Anwendungsbereich betroffen ist.

---

**13. Datenbank untersuchen**

Datenbanken können trotz geringer CPU-Auslastung langsam reagieren.

Mögliche Ursachen:

- blockierende Transaktionen,
- Deadlocks,
- fehlende oder ungeeignete Indizes,
- langsame Abfragen,
- überlastetes Storage,
- zu wenig Arbeitsspeicher,
- zu viele Verbindungen,
- fehlerhafte Ausführungspläne,
- veraltete Statistiken,
- lange offene Transaktionen,
- Replikationsprobleme.

Zu prüfen sind:

- Abfragelaufzeiten,
- aktive Verbindungen,
- blockierte Sitzungen,
- Locks und Deadlocks,
- langsame Abfrageprotokolle,
- Cache- und Speichernutzung,
- Storage-Latenz,
- Replikationsverzögerung,
- Anzahl wartender Transaktionen.

Beispielhafte Ursache-Wirkungs-Kette:

```text
lange Datenbankabfrage
        ↓
Anwendungs-Worker wartet
        ↓
Verbindungspool wird belegt
        ↓
weitere Benutzer müssen warten
        ↓
Anwendung erscheint vollständig langsam
```

Änderungen an Indizes, Abfragen oder Datenbankparametern sollten nur nach Sicherung und Abstimmung mit der verantwortlichen Stelle erfolgen.

---

**14. Hintergrundjobs prüfen**

Regelmäßig auftretende Leistungseinbrüche sprechen häufig für geplante Prozesse.

Typische Verursacher:

- Datensicherung,
- Virenscan,
- Patchinstallation,
- Datenbankwartung,
- Protokollrotation,
- Indexerstellung,
- Synchronisation,
- Replikation,
- Berichtserstellung,
- Snapshot,
- Datenimport oder Datenexport.

Windows – geplante Aufgaben:

```powershell
Get-ScheduledTask |
    Where-Object State -eq 'Running'
```

Linux – systemd-Timer:

```bash
systemctl list-timers
```

Cron-Konfiguration prüfen:

```bash
crontab -l
```

Zu vergleichen sind:

- Startzeit des Jobs,
- Beginn der Verlangsamung,
- CPU-Auslastung,
- I/O-Auslastung,
- Netzwerkverkehr,
- Ende des Jobs,
- Rückkehr zum Normalzustand.

Eine zeitliche Übereinstimmung ist ein Hinweis, aber noch kein vollständiger Ursachennachweis.

---

**15. Protokolle zeitlich vergleichen**

Protokolle müssen mit dem dokumentierten Störungszeitpunkt abgeglichen werden.

Windows-Systemereignisse:

```powershell
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message
```

Windows-Anwendungsereignisse:

```powershell
Get-WinEvent -FilterHashtable @{
    LogName   = 'Application'
    StartTime = (Get-Date).AddHours(-2)
} |
    Select-Object TimeCreated,
                  Id,
                  LevelDisplayName,
                  ProviderName,
                  Message
```

Linux:

```bash
journalctl --since "2 hours ago"
```

Fehler mit hoher Priorität:

```bash
journalctl -p err --since "2 hours ago"
```

Kernelmeldungen:

```bash
journalctl -k --since "2 hours ago"
```

Zu suchen sind:

- Datenträgerfehler,
- Netzwerkfehler,
- Treiberprobleme,
- Dienstabbrüche,
- Zeitüberschreitungen,
- Speicherfehler,
- OOM-Ereignisse,
- Authentifizierungsfehler,
- Datenbankfehler,
- wiederholte Neustarts,
- Hardwarewarnungen.

Ein einzelner protokollierter Fehler beweist nicht automatisch die Ursache. Zeitliche Übereinstimmung, technische Wirkung und Reproduzierbarkeit müssen zusammenpassen.

---

**16. Virtuelle Maschinen untersuchen**

Bei einer virtuellen Maschine müssen Gast und Hypervisor getrennt betrachtet werden.

Im Gast zu prüfen:

- vCPU-Auslastung,
- Arbeitsspeicher,
- Paging oder Swapping,
- virtuelle Datenträger,
- Netzwerkschnittstelle,
- Betriebssystemlogs,
- installierte Integrationstreiber.

Auf dem Hypervisor zu prüfen:

- CPU-Auslastung des Hosts,
- CPU-Wartezeit,
- Speicherüberbelegung,
- Ballooning oder Swapping,
- Storage-Latenz,
- Netzwerküberlastung,
- Limits und Reservierungen,
- Snapshots,
- Zustand anderer VMs.

Typische Konstellation:

```text
VM zeigt geringe CPU-Auslastung
        ↓
Anwendung ist trotzdem langsam
        ↓
Hypervisor prüfen
        ↓
VM erhält CPU-Zeit verzögert
```

Mehr virtuelle CPUs verbessern die Leistung nicht automatisch. Zu viele vCPUs können das Scheduling erschweren und die Wartezeit erhöhen.

---

**17. Container untersuchen**

Bei Containern müssen zusätzlich Limits und der Hostzustand berücksichtigt werden.

Zu prüfen sind:

- CPU-Limit,
- Arbeitsspeicherlimit,
- Neustartzähler,
- Containerlogs,
- Dateisystem,
- Storage-Treiber,
- Netzwerk,
- Zustand des Containerhosts,
- gemeinsam genutzte Ressourcen.

Docker:

```bash
docker stats
```

Laufende Container:

```bash
docker ps
```

Containerzustand:

```bash
docker inspect CONTAINERNAME
```

Protokollausgabe:

```bash
docker logs --since 2h CONTAINERNAME
```

Ressourcenlimits anzeigen:

```bash
docker inspect CONTAINERNAME \
    --format 'Memory={{.HostConfig.Memory}} NanoCPUs={{.HostConfig.NanoCpus}}'
```

Ein Container kann langsam sein, obwohl der Host noch freie Ressourcen besitzt, wenn für den Container selbst ein niedriges Limit festgelegt wurde.

---

**18. Externe Abhängigkeiten prüfen**

Eine Anwendung kann auf andere Systeme warten, obwohl der eigene Server unauffällig ist.

Mögliche Abhängigkeiten:

- Datenbankserver,
- DNS-Server,
- Active Directory,
- Dateiserver,
- API,
- Cloud-Dienst,
- Authentifizierungsdienst,
- Mailserver,
- Proxy,
- Lizenzserver,
- Netzwerkspeicher.

Zu prüfen sind:

- Erreichbarkeit,
- Namensauflösung,
- Portverbindung,
- Antwortzeit,
- Zertifikate,
- Authentifizierung,
- Zeitüberschreitungen,
- Rate Limits,
- Statusmeldungen des Dienstanbieters.

Beispiel:

```text
Webserver reagiert lokal schnell
        ↓
Anmeldung dauert 20 Sekunden
        ↓
Anwendung wartet auf Verzeichnisdienst
        ↓
DNS- oder LDAP-Verbindung untersuchen
```

---

**19. Hardwarezustand prüfen**

Bei physischen Servern müssen auch Hardwareprobleme berücksichtigt werden.

Mögliche Ursachen:

- überhitzte CPU,
- thermische Drosselung,
- fehlerhafter Arbeitsspeicher,
- degradierter RAID-Verbund,
- defekter Datenträger,
- fehlerhafte Netzwerkkarte,
- instabiles Netzteil,
- Firmware- oder Treiberproblem.

Zu prüfen sind:

- Hardwaremanagement wie iLO, iDRAC oder vergleichbare Systeme,
- Temperaturwerte,
- Lüfterstatus,
- RAID-Controller,
- SMART-Werte,
- Hardwareereignisse,
- Firmwarestand,
- Treiberstand,
- Herstellerdiagnose.

Linux – vorhandene Hardwarewarnungen:

```bash
dmesg --level=err,warn
```

SMART-Werte dürfen nur mit passenden Werkzeugen und unter Berücksichtigung des verwendeten Controllers geprüft werden.

---

**20. Letzte Änderungen untersuchen**

Leistungsprobleme treten häufig nach einer Veränderung auf.

Mögliche Änderungen:

- Betriebssystemupdate,
- Anwendungsupdate,
- Treiberupdate,
- neue Sicherheitssoftware,
- geänderte Richtlinie,
- zusätzliche Benutzer,
- Datenwachstum,
- neue VM,
- geändertes Backupfenster,
- neue Datenbankabfrage,
- geänderte Ressourcenlimits,
- Netzwerkanpassung.

Zu dokumentieren sind:

| Änderung | Zeitpunkt | Verantwortlich | Mögliche Auswirkung |
|---|---|---|---|
| Anwendungsupdate | 08:30 Uhr | Anwendungsteam | neue Abfrage oder Fehler |
| Backupzeit geändert | 09:00 Uhr | Betriebsteam | höhere Storage-Last |
| neue VM gestartet | 09:10 Uhr | Virtualisierungsteam | Hostressourcen |
| GPO geändert | Vortag | Administration | Dienst- oder Sicherheitseinstellung |

Die zeitliche Nähe einer Änderung zum Fehler ist ein wichtiges Indiz, aber kein alleiniger Beweis.

---

**21. Baseline und Vergleichswerte verwenden**

Ohne Vergleichswerte lässt sich schwer beurteilen, ob ein Messwert ungewöhnlich ist.

Eine Baseline kann enthalten:

- typische CPU-Auslastung,
- typischer Arbeitsspeicherbedarf,
- normale Datenträgerlatenz,
- normale Netzwerklatenz,
- typische Benutzeranzahl,
- typische Antwortzeit,
- übliche Anzahl von Verbindungen,
- normale Auslastung zu bestimmten Tageszeiten.

Beispiel:

| Messwert | Normalzustand | Störungszeitpunkt |
|---|---:|---:|
| Antwortzeit | 1,5 s | 15 s |
| CPU | 35 % | 42 % |
| verfügbarer RAM | 8 GB | 7,5 GB |
| Storage-Latenz | 4 ms | 85 ms |
| aktive Benutzer | 120 | 125 |

In diesem Beispiel spricht der Vergleich stärker für ein Storage-Problem als für CPU-, RAM- oder Benutzerlast.

---

**22. Korrelation und Ursache unterscheiden**

Zwei gleichzeitig auftretende Ereignisse müssen nicht ursächlich zusammenhängen.

Beispiel:

```text
CPU-Auslastung steigt
Anwendung wird langsam
```

Mögliche Interpretationen:

1. Die hohe CPU-Auslastung verursacht die Verzögerung.
2. Die langsame externe Abhängigkeit führt zu zusätzlichen Wiederholungen und erhöht dadurch die CPU-Auslastung.
3. Ein dritter Prozess verursacht gleichzeitig beide Effekte.
4. Die CPU-Auslastung ist normal und nicht relevant.

Ein Ursachennachweis wird stärker, wenn:

- der Zeitpunkt übereinstimmt,
- die technische Wirkung plausibel ist,
- das Verhalten reproduzierbar ist,
- eine gezielte Maßnahme den Messwert und das Symptom verändert,
- alternative Ursachen ausgeschlossen wurden.

---

**23. Kontrollierte Maßnahmen durchführen**

Nach der Analyse sollte genau eine passende Maßnahme durchgeführt werden.

Mögliche Maßnahmen:

- störenden Hintergrundjob pausieren,
- fehlerhaften Prozess kontrolliert neu starten,
- Anwendung auf einen zweiten Knoten umleiten,
- Ressourcenlimit korrigieren,
- fehlerhafte Änderung zurücknehmen,
- freien Speicherplatz schaffen,
- Storage- oder Netzwerkproblem eskalieren,
- Datenbankblockierung durch die zuständige Stelle auflösen.

Vor jeder Maßnahme:

- Ausgangszustand sichern,
- Auswirkung bestimmen,
- Freigabe prüfen,
- Rückweg festlegen,
- betroffene Benutzer informieren,
- Messkriterien bestimmen.

Danach:

- dieselben Messwerte erneut erfassen,
- Antwortzeit erneut messen,
- Protokolle prüfen,
- Nebenwirkungen ausschließen,
- Ergebnis dokumentieren.

---

**24. Warum ein Neustart nicht die erste Maßnahme sein sollte**

Ein Neustart kann:

- blockierte Prozesse beenden,
- Arbeitsspeicher freigeben,
- Warteschlangen zurücksetzen,
- Verbindungen neu aufbauen,
- ein Symptom vorübergehend beseitigen.

Er kann aber auch:

- wichtige Fehlerzustände vernichten,
- Protokollzusammenhänge erschweren,
- eine eigentliche Ursache verbergen,
- ungeplante Ausfallzeit verursachen,
- Daten oder Transaktionen gefährden,
- das Problem später erneut auftreten lassen.

Ein Neustart ist daher keine vollständige Ursachenanalyse.

Falls ein Neustart erforderlich ist, sollten vorher mindestens folgende Informationen gesichert werden:

- Prozessliste,
- Ressourcenauslastung,
- aktive Verbindungen,
- relevante Protokolle,
- laufende Aufgaben,
- Zeitpunkt und Symptom,
- Wiederanlaufplan,
- Rückfalloption.

---

**25. Nachkontrolle**

Nach einer Maßnahme muss nicht nur die Ressourcenauslastung, sondern auch die eigentliche Funktion geprüft werden.

Zu kontrollieren sind:

- Antwortzeit des betroffenen Dienstes,
- CPU-Auslastung,
- Arbeitsspeicher,
- Paging oder Swap,
- Datenträgerlatenz,
- Netzwerkfehler,
- Dienststatus,
- Anwendungslogs,
- Datenbankstatus,
- Benutzerfunktion,
- Zustand abhängiger Systeme.

Beispiel:

```text
Vorher:
Antwortzeit 15 Sekunden
Storage-Latenz 85 ms

Maßnahme:
konkurrierenden Backupjob beendet

Nachher:
Antwortzeit 1,7 Sekunden
Storage-Latenz 5 ms
```

Erst der Vergleich vor und nach der Maßnahme zeigt, ob die vermutete Ursache tatsächlich zum Problem beigetragen hat.

---

**26. Dokumentation**

Die Abschlussdokumentation sollte enthalten:

- betroffener Server,
- betroffener Dienst,
- Beginn und Ende,
- Sollzustand,
- Istzustand,
- betroffene Benutzer,
- gemessene Werte,
- relevante Protokolle,
- identifizierte Ursache,
- durchgeführte Maßnahme,
- Rückweg,
- Ergebnis der Nachkontrolle,
- Nebenwirkungen,
- vorbeugende Maßnahme,
- verantwortliche Stelle.

Beispiel:

```text
Symptom:
Webanwendung benötigte statt 1–2 Sekunden etwa 15 Sekunden.

Ursache:
Der gleichzeitig laufende Backupjob verursachte eine hohe
Latenz auf dem gemeinsam genutzten Storage.

Maßnahme:
Backupjob kontrolliert beendet und Zeitplan angepasst.

Ergebnis:
Antwortzeit wieder unter 2 Sekunden.
Storage-Latenz wieder im üblichen Bereich.

Vorbeugung:
Monitoring für Storage-Latenz eingerichtet und Backupfenster geändert.
```

---

**27. Entscheidungsbaum**

```text
Server oder Dienst langsam
        ↓
Ist der gesamte Server betroffen?
        ├── Ja
        │   ↓
        │   CPU, RAM, Storage, Netzwerk und Hypervisor prüfen
        │
        └── Nein
            ↓
        Nur eine Anwendung betroffen?
                ├── Ja
                │   ↓
                │   Anwendung, Datenbank und Abhängigkeiten prüfen
                │
                └── Nein
                    ↓
                Gemeinsame Komponente der betroffenen Dienste suchen
```

Erweiterte Eingrenzung:

```text
Problem nur aus der Ferne?
        ├── Ja → Netzwerk, DNS, VPN, Firewall oder Proxy
        └── Nein
             ↓
Problem nur zu festen Zeiten?
        ├── Ja → Backup, Scan, Wartung oder geplanter Job
        └── Nein
             ↓
Mehrere VMs auf einem Host betroffen?
        ├── Ja → Hypervisor und gemeinsames Storage
        └── Nein → Gastbetriebssystem und Anwendung
```

---

**28. Häufige Fehlerbilder**

| Fehlerbild | Wahrscheinlicher Prüfbereich |
|---|---|
| Server reagiert nach Neustart wieder schnell | Speicherleck, blockierter Prozess oder wartende Ressource |
| Problem kehrt regelmäßig zurück | Ursache wurde nicht behoben oder geplanter Job |
| CPU dauerhaft hoch | Prozess, Thread, Malware, Scan oder zu geringe Leistung |
| CPU niedrig, Server trotzdem langsam | Storage, Netzwerk, Locks oder externe Abhängigkeit |
| RAM nahezu vollständig belegt | Paging und Speicherdruck prüfen |
| Swap-Nutzung steigt dauerhaft | Arbeitsspeicherengpass |
| Datenträger dauerhaft ausgelastet | Backup, Datenbank, Scan oder langsames Storage |
| nur Datenbankfunktionen langsam | Abfragen, Locks, Indizes oder Storage |
| nur Anmeldung langsam | DNS, Verzeichnisdienst, GPO oder Benutzerprofil |
| nur Webzugriff langsam | Webserver, TLS, Proxy, Anwendung oder Datenbank |
| nur bestimmte Uhrzeit betroffen | geplanter Job oder Lastspitze |
| mehrere VMs betroffen | Host, Netzwerk oder gemeinsames Storage |
| nur eine VM betroffen | Gastbetriebssystem, Limits oder VM-Konfiguration |
| Zugriff per IP schnell | DNS-Auflösung prüfen |
| lokal schnell, entfernt langsam | Netzwerkpfad prüfen |
| Anwendung wartet auf Timeout | externe Abhängigkeit untersuchen |
| Leistung nimmt über Tage ab | Speicherleck, Datenwachstum oder Warteschlange |

---

**29. Typische Prüfungsfragen**

**Warum ist die Aussage „der Server ist langsam“ für die Fehleranalyse nicht ausreichend?**

<details>
<summary>Antwort anzeigen</summary>

Die Aussage beschreibt nur ein allgemeines Symptom. Es fehlen unter anderem der betroffene Dienst, die gemessene Antwortzeit, der Normalzustand, der Zeitpunkt, der Umfang und mögliche Änderungen.

</details>

**Warum beweist eine hohe CPU-Auslastung noch nicht die Fehlerursache?**

<details>
<summary>Antwort anzeigen</summary>

Die Auslastung kann für die vorhandene Arbeitslast normal sein oder erst als Folge eines anderen Problems entstehen. Für einen Ursachennachweis müssen zeitlicher Zusammenhang, technische Wirkung und das Ergebnis einer kontrollierten Maßnahme geprüft werden.

</details>

**Warum kann ein Server trotz niedriger CPU-Auslastung langsam sein?**

<details>
<summary>Antwort anzeigen</summary>

Prozesse können auf Storage, Netzwerk, Datenbanksperren, externe Dienste oder andere Ressourcen warten. Während dieser Wartezeit wird nur wenig CPU-Leistung benötigt.

</details>

**Warum ist vollständig belegter Arbeitsspeicher nicht automatisch ein Fehler?**

<details>
<summary>Antwort anzeigen</summary>

Betriebssysteme verwenden freien Arbeitsspeicher unter anderem für Caches. Entscheidend sind Speicherdruck, Paging beziehungsweise Swapping und die zeitliche Entwicklung.

</details>

**Warum sollten vor einem Neustart Messwerte gesichert werden?**

<details>
<summary>Antwort anzeigen</summary>

Ein Neustart beendet Prozesse, leert Warteschlangen und verändert den Systemzustand. Dadurch können wichtige Hinweise auf die eigentliche Ursache verloren gehen.

</details>

**Was bedeutet eine hohe Datenträgerlatenz?**

<details>
<summary>Antwort anzeigen</summary>

Lese- oder Schreibanforderungen benötigen ungewöhnlich lange. Anwendungen können dadurch warten, obwohl CPU und Arbeitsspeicher unauffällig sind.

</details>

**Warum reicht ein erfolgreicher Ping nicht als Nachweis für einen funktionierenden Dienst?**

<details>
<summary>Antwort anzeigen</summary>

Ping prüft ICMP-Erreichbarkeit. Der eigentliche Anwendungsport, die Authentifizierung, die Verarbeitung im Dienst und dessen Backend werden dadurch nicht geprüft.

</details>

**Warum müssen bei einer VM auch Hypervisorwerte geprüft werden?**

<details>
<summary>Antwort anzeigen</summary>

Der Gast kann nur die ihm bereitgestellten Ressourcen sehen. Wartezeiten, Überbelegung oder Storage-Probleme auf dem Host sind im Gast möglicherweise nicht eindeutig erkennbar.

</details>

**Warum sollte nach einer Maßnahme erneut gemessen werden?**

<details>
<summary>Antwort anzeigen</summary>

Nur der Vergleich von Sollwert, Ausgangswert und neuem Messwert zeigt, ob die Maßnahme das eigentliche Problem behoben hat.

</details>

---

**30. Prüfungsfallen**

- „Server langsam“ nicht genauer eingrenzen.
- einen einzelnen hohen Messwert sofort als Ursache bewerten.
- nur CPU und Arbeitsspeicher prüfen.
- Datenträgerlatenz nicht berücksichtigen.
- belegten Arbeitsspeicher automatisch mit Speichermangel gleichsetzen.
- Ping als vollständigen Diensttest ansehen.
- DNS nicht prüfen.
- Anwendung und Server nicht voneinander trennen.
- externe Abhängigkeiten übersehen.
- nur den Gast und nicht den Hypervisor untersuchen.
- Containerlimits nicht berücksichtigen.
- Hintergrundjobs nicht mit dem Störungszeitpunkt vergleichen.
- Protokolle ohne genaue Uhrzeit untersuchen.
- mehrere Maßnahmen gleichzeitig durchführen.
- sofort neu starten.
- Zustand vor der Maßnahme nicht sichern.
- nach der Maßnahme nicht erneut messen.
- technische Messwerte prüfen, aber die Benutzerfunktion nicht testen.
- zeitliche Korrelation automatisch als Ursache bewerten.
- das funktionierende Vergleichssystem nicht nutzen.
- keine vorbeugende Maßnahme dokumentieren.

---

**31. Checkliste „Server ist langsam“**

- [ ] betroffener Server wurde eindeutig bestimmt.
- [ ] betroffener Dienst wurde bestimmt.
- [ ] Sollzustand wurde dokumentiert.
- [ ] Istzustand wurde gemessen.
- [ ] Beginn und Häufigkeit wurden dokumentiert.
- [ ] betroffene Benutzer und Standorte wurden bestimmt.
- [ ] lokaler und entfernter Zugriff wurden verglichen.
- [ ] funktionierendes Vergleichssystem wurde geprüft.
- [ ] letzte Änderungen wurden ermittelt.
- [ ] Ausgangszustand wurde gesichert.
- [ ] CPU-Gesamtauslastung wurde geprüft.
- [ ] einzelne CPU-Kerne wurden berücksichtigt.
- [ ] CPU-Auslastung pro Prozess wurde geprüft.
- [ ] Arbeitsspeicher wurde geprüft.
- [ ] Paging oder Swapping wurde geprüft.
- [ ] Prozesse mit hoher Speichernutzung wurden ermittelt.
- [ ] freier Speicherplatz wurde geprüft.
- [ ] Datenträgerlatenz wurde geprüft.
- [ ] Datenträgerwarteschlange wurde geprüft.
- [ ] RAID- oder Storage-Zustand wurde berücksichtigt.
- [ ] Netzwerkverbindung wurde geprüft.
- [ ] Paketverlust und Latenz wurden geprüft.
- [ ] Netzwerkfehlerzähler wurden geprüft.
- [ ] DNS-Auflösung wurde geprüft.
- [ ] Anwendungsport wurde geprüft.
- [ ] aktive Verbindungen wurden geprüft.
- [ ] Dienste und Prozesse wurden geprüft.
- [ ] Anwendungslogs wurden geprüft.
- [ ] Betriebssystemlogs wurden geprüft.
- [ ] Datenbankzustand wurde geprüft.
- [ ] Datenbanksperren wurden berücksichtigt.
- [ ] externe Abhängigkeiten wurden geprüft.
- [ ] Backups und Wartungsjobs wurden geprüft.
- [ ] Virenscans wurden berücksichtigt.
- [ ] Hypervisorwerte wurden geprüft.
- [ ] VM- oder Containerlimits wurden geprüft.
- [ ] Hardwarezustand wurde berücksichtigt.
- [ ] Messwerte wurden zeitlich korreliert.
- [ ] genau eine kontrollierte Maßnahme wurde durchgeführt.
- [ ] Rückweg wurde festgelegt.
- [ ] dieselben Messwerte wurden anschließend erneut erfasst.
- [ ] fachliche Funktion wurde praktisch getestet.
- [ ] Nebenwirkungen wurden ausgeschlossen.
- [ ] Ursache, Maßnahme und Ergebnis wurden dokumentiert.
- [ ] vorbeugende Maßnahme wurde festgelegt.

---

**32. Schnellreferenz**

| Beobachtung | Nächster Prüfbereich |
|---|---|
| gesamte Maschine langsam | CPU, RAM, Storage, Hypervisor |
| nur eine Anwendung langsam | Anwendung, Datenbank, Abhängigkeiten |
| CPU dauerhaft hoch | Prozess- und Threadauslastung |
| nur ein Kern ausgelastet | Single-Thread-Engpass |
| CPU niedrig, Antwortzeit hoch | Storage, Netzwerk, Locks |
| starke Paging-Aktivität | Arbeitsspeicher |
| hohe I/O-Wartezeit | Datenträger oder Storage |
| wenig freier Speicherplatz | Dateisystem und Datenwachstum |
| lokale Nutzung schnell | Netzwerk, DNS, Proxy oder Firewall |
| Zugriff per IP schnell | DNS |
| Paketverlust vorhanden | Netzwerkpfad |
| nur bestimmte Uhrzeit betroffen | geplante Aufgaben |
| Problem während Backup | Storage- und Netzwerkbelastung |
| mehrere VMs betroffen | Hypervisor und gemeinsames Storage |
| nur eine VM betroffen | Gast, Limits und virtuelle Hardware |
| Container wird gedrosselt | CPU- und Speicherlimit |
| bestimmte Datenbankabfrage langsam | Locks, Indizes und Ausführungsplan |
| Anmeldung langsam | DNS, AD, GPO oder Profil |
| Anwendung wartet auf Timeout | externe Abhängigkeit |
| nach Neustart vorübergehend schnell | Speicherleck, Warteschlange oder blockierter Prozess |
| Hardwarewarnung vorhanden | Herstellerdiagnose und Austauschplanung |

---

**Merksatz**

> Ein langsamer Server wird nicht durch Vermutungen, sondern durch Eingrenzung und Messwerte untersucht. Entscheidend ist, ob CPU, Arbeitsspeicher, Storage, Netzwerk, Anwendung, Datenbank, Hypervisor oder eine externe Abhängigkeit den tatsächlichen Engpass verursacht. Vor einer Änderung wird der Ausgangszustand gesichert, anschließend wird genau eine kontrollierte Maßnahme durchgeführt und ihre Wirkung erneut gemessen.

---

**Quellen und weiterführende Dokumentation**

- [Microsoft Learn – Windows Performance Monitor](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/perfmon)
- [Microsoft Learn – Get-Counter](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-counter)
- [Microsoft Learn – Get-Process](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-process)
- [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent)
- [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection)
- [Microsoft Learn – Resolve-DnsName](https://learn.microsoft.com/en-us/powershell/module/dnsclient/resolve-dnsname)
- [Microsoft Learn – Get-NetAdapterStatistics](https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterstatistics)
- [Red Hat – Viewing system processes](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/managing_monitoring_and_updating_the_kernel/viewing-system-processes_managing-monitoring-and-updating-the-kernel)
- [Red Hat – Monitoring performance with Performance Co-Pilot](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/monitoring_and_managing_system_status_and_performance/monitoring-performance-with-performance-co-pilot_monitoring-and-managing-system-status-and-performance)
- [Docker Docs – Runtime metrics](https://docs.docker.com/engine/containers/runmetrics/)
- [Docker Docs – Resource constraints](https://docs.docker.com/engine/containers/resource_constraints/)