Performance-Monitoring auf dem vServer

Bei dediziertem Server willst Du wissen, wie’s läuft — CPU-Last, RAM-Verbrauch, Disk-IO, Netzwerk. Plesk hat eingebautes Monitoring, plus wir machen Server-Monitoring im Hintergrund. Hier was Du selbst sehen kannst und wann Skalierung sinnvoll wird.

Was Plesk an Stats zeigt

In Plesk → Statistiken:

Server-Resource-Übersicht

• CPU-Auslastung: aktuell und Verlauf
• RAM-Verbrauch: belegt vs. verfügbar
• Swap-Nutzung: hoffentlich nahe Null (wenn nicht: RAM zu klein)
• Disk-Usage: pro Volume, gesamt
• Disk-IO: Reads/Writes pro Sekunde
• Netzwerk: eingehend/ausgehend in Mbit/s

Werte sind sekundengenau aktualisiert.

Pro-Endkunde-Statistiken

Wenn Du Endkunden hostest:

• Disk-Verbrauch pro Endkunde
• Traffic pro Endkunde
• Mailbox-Größen
• DB-Größen

Hilft beim Identifizieren der größten Verbraucher.

Pro-Domain-Statistiken

• HTTP-Traffic (eingehend/ausgehend)
• Anzahl Requests
• AWStats / Webalizer für Besucher-Analyse

Server-Performance-Tab

In Plesk → Werkzeuge & Einstellungen → Server-Performance:

• Response-Zeit für Standard-Plesk-Aktionen
• Aktive Verbindungen
• Worker-Pool-Status (PHP-FPM)
• Datenbank-Verbindungen

Wenn was langsam ist, hier Indizien.

Kommando-Line-Tools (per SSH)

Über Reseller-SSH (chrooted) hast Du Standard-Tools:

top              # Process-Liste mit CPU-Last
htop             # bessere Variante
iostat -x 2      # Disk-IO live (per Ticket installierbar)
vmstat 2         # System-Stats
free -h          # RAM-Verbrauch
df -h            # Disk-Usage

Wenn htop oder iostat nicht installiert: Ticket bei uns, installieren wir.

Vom Reseller-SSH aus siehst Du nur Deine Reseller-Prozesse + öffentliche Server-Stats. Tieferer Zugriff geht nur über uns.

Erweitertes Monitoring (Add-on)

Standard ist Plesks eigenes Monitoring. Wenn Du mehr willst:

Plesk-Monitoring-Erweiterung

• E-Mail-Alarme bei hoher Last
• Webhook-Notifications
• Detaillierte Metriken über Zeit

In Plesk-Erweiterungen aktivierbar.

Custom-Stack mit Grafana / Prometheus

Per Docker installieren:

# docker-compose.yml
services:
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prom-config:/etc/prometheus
    ports:
      - "9090:9090"

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana-data:/var/lib/grafana

volumes:
  grafana-data:

Mit Plesk-Reverse-Proxy auf Subdomain → eigenes Monitoring-Dashboard.

Mehr in Docker im Plesk.

Externer Monitoring-Service

UptimeRobot, Pingdom, BetterStack:

• Externe Pings auf Deine Domains
• Alarmierung bei Ausfall
• Performance-Metriken aus Außensicht

Empfehlung: zusätzlich zu Server-internem Monitoring. Externe Sicht zeigt Probleme, die intern unsichtbar sind (DNS-Probleme, ISP-Routing-Issues).

Was wir im Hintergrund monitoren

Auf jedem unserer vServer läuft:

• Hardware-Health (Temperatur, Disk-S.M.A.R.T., RAID-Status)
• VM-Health (CPU-Steal-Time, Memory-Pressure)
• Server-OS-Logs (Syslog, dmesg)
• Plesk-Service-Status (Webserver, Mail, DB, Plesk-Daemon)
• Backup-Status

Bei kritischen Events: wir bekommen sofort Alarm. Bei Hardware-Problemen agieren wir, bevor Du’s mitbekommst.

Du siehst diese Logs nicht direkt — bei Bedarf können wir gezielt nachsehen, sag uns Bescheid.

Wann skalierst Du

Indikatoren für CPU-Engpass

• CPU-Auslastung dauerhaft >80%
• Plesk-Aktionen sind träge
• Webseiten-TTFB (Time-to-First-Byte) deutlich erhöht

→ Tarif-Upgrade auf nächste Stufe (mehr vCPU). Wir vergrößern die VM live.

Indikatoren für RAM-Engpass

• RAM-Verbrauch >90%
• Swap aktiv (sollte selten sein)
• OOM-Kills (Out-Of-Memory) in Logs

→ Tarif-Upgrade.

Indikatoren für Disk-Engpass

• Disk-Usage >90%
• Backups schlagen fehl wegen Platzmangel
• DB-Performance bricht ein

→ Tarif-Upgrade oder Daten-Bereinigung (alte Backups löschen, Cache aufräumen).

Indikatoren für Disk-IO-Engpass

• Webseiten langsam trotz niedriger CPU
• DB-Queries dauern lange
• IO-Wait in top hoch

→ Storage-Optimierung (DB-Indizes, Query-Tuning) oder Tarif mit NVMe (Agentur-Tarif statt SSD-RAID10).

Indikatoren für Netzwerk-Engpass

• 1 GBit-Anbindung dauerhaft am Limit
• Hohe Latenz für Endkunden

→ Selten — meistens nicht das Bottleneck. Bei Bedarf: Multi-IP-Setup oder Custom-Bandbreite (Ticket).

Skalierung in der Praxis

Tarif-Upgrade live

Wir können in der Regel ohne Downtime:

• vCPU erhöhen
• RAM erhöhen

Storage-Vergrößerung braucht meist kurze Downtime (5-15 Min).

Tarif-Wechsel: Ticket bei uns, wir machen’s. Aufwand für Dich: keiner.

Vertikal vs. horizontal skalieren

Vertikal (mehr Resourcen pro Server): einfach, immer erste Wahl.

Horizontal (mehr Server): komplex, bei sehr großen Setups. Plesk unterstützt das nicht trivial — Workarounds:

• Mehrere vServer mit jeweils eigenem Plesk
• DB-Cluster (auf Anfrage einrichtbar)
• CDN davorschalten (Cloudflare, BunnyCDN)

Für die meisten Setups reicht vertikal.

Bottleneck-Diagnose

Klassischer Workflow:

1. Wo ist das Problem? — User-Report konkretisieren („alles langsam” reicht nicht)
2. Wann? — Korrelation mit Lastspitzen, Cron-Jobs, externen Events
3. Welche Resource? — CPU, RAM, Disk, Netzwerk
4. Wer Verursacht es? — pro Domain, pro Container, pro Endkunde

Plesk-Statistiken decken Schritt 3 und 4 ab. Schritt 1-2 brauchst Du Reports von Endkunden.

Performance-Tipps für hohe Last

WordPress-Caching

• Plugin WP Rocket oder W3 Total Cache
• nginx-FastCGI-Cache (per Ticket einrichtbar)
• Object-Cache mit Redis

DB-Optimierung

• DB-Indizes prüfen (Tools wie Query Monitor in WordPress)
• Lange Queries identifizieren
• Read-Heavy-Workloads mit Cache (Redis) entlasten

Static-Asset-CDN

• Cloudflare vor Domains schalten (kostenlos)
• Statische Assets aus CDN ausliefern
• Reduziert Server-Last massiv

PHP-OPcache

• Default an
• Bei größeren Sites: realpath_cache_size erhöhen
• Wir tunen Default-Werte mit unserer Initialkonfig

Häufige Fragen

Sehe ich CPU-Last pro Domain? Eingeschränkt. Plesk zeigt aggregiert. Pro-Domain-CPU-Tracking braucht externe Tools (Grafana mit per-vhost Metriken, manuell aufzusetzen).

Wie früh warnt mich Plesk vor Disk-Voll? Default 80% und 95%. Anpassbar in Plesk-Notification-Settings.

OOM-Kills sehen — wie? Server-Log nötig. Per Ticket bei uns, wir liefern Auszug.

Wie groß darf eine Domain werden, bevor Performance leidet? Hängt von Workload ab. WordPress mit Caching: 100 GB+ kein Problem. Viele kleine Files (Image-Galerie): wird ab 1 Mio Files träge.

Wie viele Plesk-Domains kann ein Studio-vServer (8 vCPU, 16 GB)? 50–80 typisch. Bei vielen High-Traffic-Sites weniger. Limit oft RAM (jeder PHP-Pool reserviert ein paar MB), nicht CPU.

Plesk-Backup blockiert Server während Lauf? Backup macht Disk-IO-Last. Bei kleinen Setups merkst Du’s nicht, bei großen schon. Default läuft nachts. Bei Bedarf in andere Uhrzeit verschieben.

vCPU vs. Echte Kerne — was ist der Unterschied? Bei uns: vCPU = dedizierter physischer Kern. Keine Über­buchung. Wenn Du 8 vCPU hast, sind 8 Kerne reserviert.

Mein Server ist plötzlich langsam — was zuerst checken?

1. CPU-Last (top) — was läuft
2. Disk-Usage — voll?
3. Mail-Queue (Spam-Welle?)
4. WordPress-Login-Versuche (Brute-Force?)
5. Bei Unklarheit: Ticket bei uns mit Zeitfenster, wir prüfen Logs

Weiter geht’s

• Anpassungen per Ticket
• Docker im Plesk
• Backup-Strategie