Überwachung der Serverressourcen und Leistungsoptimierung

Was „Leistung“ bei einem dedizierten Server wirklich bedeutet

Auf einem VPS bist du durch Soft Limits eingeschränkt, die vom Hypervisor festgelegt werden. Dedizierte Server laufen direkt auf der Hardware, sodass deine Leistungsgrenze echt ist. Das entspricht dem physischen RAM, den tatsächlichen CPU-Kernen und dem E/A-Durchsatz deiner NVMe . Das ist ein großer Vorteil, bedeutet aber auch, dass du, wenn du an eine Grenze stößt, auf die tatsächliche Hardware stößt und nicht auf einen künstlichen Regler.

Dieser Unterschied ist wichtig für die Überwachungsstrategie. Auf einer gemeinsam genutzten oder virtualisierten Infrastruktur kann ein Anstieg der CPU-Auslastung bedeuten, dass ein Nachbar Ressourcen klaut. Auf einem dedizierten Server heißt ein Anstieg, dass deine Arbeitslast wirklich mehr verlangt als vorher. Beides muss man im Auge behalten, aber aus unterschiedlichen Gründen.

Wichtige Kennzahlen, die du im Auge behalten solltest

CPU-Auslastung und durchschnittliche Auslastung

Die CPU-Auslastung allein gibt kein vollständiges Bild. Ein 8-Kern-Server mit einer CPU-Auslastung von 90 % kann gut laufen, wenn alle Kerne tatsächlich arbeiten. Die folgenden Anzeichen deuten auf ein Problem hin:

• Durchschnittliche Auslastung deutlich über der Kernanzahl: Ein AMD EPYC 4545P-Server mit 16 Kernen und einer durchschnittlichen Auslastung von über 40 in einer Minute bedeutet, dass Prozesse auf CPU-Zeit warten und diese nicht einfach nutzen. Überprüfe das mit uptime oder cat /proc/loadavg.
• CPU-Wartezeit (wa) in der Top-Ausgabe: Ein hoher iowait-Prozentsatz heißt, dass Prozesse blockiert sind und auf Lese- oder Schreibvorgänge auf der Festplatte warten. Die CPU ist eigentlich im Leerlauf, aber es passiert nichts Sinnvolles.
• Steal Time auf virtualisierten Gästen: Auf Bare-Metal-Systemen nicht relevant; wenn du Steal Time auf einem „dedizierten” Server siehst, bist du eigentlich auf einer virtualisierten Infrastruktur.

Speicherbelastung

RAM-Erschöpfung ist der Grund, warum Server meistens ohne Vorwarnung abstürzen. Die Metriken, die man im Auge behalten sollte:

• Verfügbarer Speicher (nicht freier Speicher): Linux speichert Festplattendaten aggressiv im RAM-Cache. free -m zeigt den „freien“ Speicher auf funktionierenden Servern als sehr gering an. Wichtig ist die Spalte „Verfügbar“, die angibt, wie viel RAM der Kernel bei Bedarf zurückgewinnen kann.
• Swap-Nutzung: Swap-Nutzung ist nicht unbedingt ein Problem, aber wenn die Swap-Auslastung bei normaler Belastung steigt, ist das ein Warnsignal. Sobald Anwendungen anfangen, Swap zu lesen/schreiben, steigt die Latenz dramatisch an.
• OOM-Killer-Ereignisse: Schau mal in /var/log/kern.log oder dmesg | grep -i oom nach. Wenn der Kernel Prozesse beendet, um Speicher freizugeben, hast du ein Kapazitätsproblem.

Der Extreme-Dedizierte Server von InMotion kommt mit 192 GB DDR5 ECC-RAM. Das ist genug Spielraum, sodass die meisten Workloads selbst bei aggressivem Caching nicht an ihre Grenzen stoßen. Auch die ECC-Komponente ist wichtig: Speicherfehler, die auf Consumer-Hardware unbemerkt Daten beschädigen würden, werden automatisch erkannt und korrigiert.

Festplatten-E/A

NVMe haben die Festplattenleistung echt verändert, aber selbst NVMe bei vielen Schreibvorgängen zum Engpass werden. Wichtige Kennzahlen:

• iowait: Bei iostat -x 1 zeigt die Spalte „%await“ die durchschnittliche Zeit pro E/A-Anforderung in Millisekunden an. Unter 5 ms ist für NVMe okay. Über 20 ms bei normaler Auslastung kann auf eine Sättigung oder ein defektes Laufwerk hindeuten.
• Warteschlangentiefe: iostat -x 1 zeigt auch avgqu-sz an. Wenn die Werte auf einem NVMe dauerhaft über 1-2 liegen, heißt das meistens, dass die Festplatte mit der E/A-Rate nicht mithalten kann.
• Verhältnis von Lese- zu Schreibvorgängen: Wenn du viel schreibst, nutzen sich SSDs schneller ab und der Schreibpuffer kann voll werden. Wenn du weißt, wie oft du liest und schreibst, kannst du besser entscheiden, wie du den Cache nutzen und den Speicher einrichten solltest.

Netzwerkdurchsatz und Paketverlust

• Bandbreitennutzung: Mit iftop oder nethogs kannst du die Bandbreitennutzung pro Verbindung und pro Prozess in Echtzeit checken.
• TCP-Neuübertragungen: netstat -s | grep retransmit, steigende Zahlen deuten auf Paketverluste zwischen Server und Clients oder der Upstream-Infrastruktur hin.
• Verbindungsstatus: Mit dem Befehl „ss -s“ kannst du die Anzahl der Verbindungen nach Status anzeigen. Viele CLOSE_WAIT-Verbindungen deuten darauf hin, dass der Anwendungscode die Verbindungen nicht richtig schließt.

Überwachungsstapel-Optionen

Netdata

Netdata ist der schnellste Weg, um Echtzeit-Metriken pro Sekunde auf einem Linux-Server mit minimalem Konfigurationsaufwand zu bekommen. Die Standard-Agenteninstallation ruft sofort CPU-, Speicher-, Festplatten- und Netzwerkmetriken ab, und die Granularität pro Sekunde fängt Spitzenwerte ab, die von Überwachungssystemen mit Minutenmittelwerten komplett übersehen werden. Es läuft problemlos auf Produktionsservern mit weniger als 1 % CPU-Overhead in den meisten Konfigurationen.

Für dedizierte Server, die von Technik-Teams verwaltet werden, macht es der Prometheus-Metrik-Export von Netdata einfach, Daten in vorhandene Grafana-Dashboards einzuspielen.

Prometheus + Grafana

Der Standard-Stack für Open-Source-Observability. Prometheus sammelt Metriken von Exportern (node_exporter für Linux-Systemmetriken, mysqld_exporter für MySQL usw.) in einem einstellbaren Intervall, normalerweise alle 15 oder 30 Sekunden. Grafana kümmert sich um das Dashboarding und die Alarmierung.

Diese Kombination braucht mehr anfängliche Konfiguration als Netdata, bietet aber viel mehr Flexibilität für benutzerdefinierte Metriken, langfristige Speicherung und Sichtbarkeit über mehrere Server hinweg. Die meisten Produktionsteams, die mehr als 3–4 dedizierte Server betreiben, standardisieren auf diesem Stack.

Der Ressourcenmonitor cPanel

Wenn dein dedizierter Server mit cPanel läuft, zeigt der eingebaute Ressourcenmonitor ohne extra Einstellungen die CPU- und Speicherauslastung auf Kontoebene an. Er ist zwar nicht so detailliert wie Prometheus, aber sofort einsetzbar und besonders nützlich, um herauszufinden, welche cPanel in Reseller- oder Multi-Tenant-Konfigurationen unverhältnismäßig viele Ressourcen verbrauchen.

Das Premier Care-Paket von InMotion beinhaltet eine proaktive Überwachung durch das APS-Team, was besonders während der Geschäftszeiten nützlich ist, wenn ungewöhnliche Ressourcenmuster eine Koordination zwischen Diagnosen auf Serverebene und Untersuchungen auf Anwendungsebene erfordern können.

Leistungsoptimierung basierend auf deinen Erkenntnissen

CPU-gebundene Workloads

Wenn die CPU wirklich das Problem ist, hier die Optionen nach ihrer Wirkung:

1. Profile the application: Tools like perf top or strace -c -p <pid> identify which system calls or functions consume the most CPU. Optimization at the application level almost always outperforms hardware changes.
2. Such nach ineffizienten Cron-Jobs: Mit „crontab -l“ und einem Blick in „/etc/cron.d/“ findest du oft Skripte, die nie optimiert wurden, weil sie „nur ab und zu laufen“. Auf modernen Servern kann „ab und zu“ bedeuten, dass alle 15 Minuten 10 Sekunden lang 100 % der CPU-Leistung verbraucht werden.
3. Größe des PHP-FPM-Worker-Pools: Falsch konfigurierte PHP-FPM-Pools auf Webservern starten oft mehr Worker als verfügbare CPUs, was zu einem hohen Kontextwechsel-Overhead führt. Passe pm.max_children an die Anzahl deiner CPU-Kerne an, multipliziert mit einem vernünftigen Parallelitätsfaktor (normalerweise 2-4x für I/O-gebundene PHP-Anwendungen).

Speichergebundene Workloads

4. Redis oder Memcached für Objekt-Caching: Wenn deine App immer wieder dieselben Daten aus der Datenbank abfragt, kann ein In-Memory-Cache die Speicherbelastung der Datenbank und die CPU-Auslastung echt runterbringen. Mit den Persistenzoptionen von Redis kannst du aggressiv cachen, ohne dass beim Neustart Daten verloren gehen.
5. MySQL innodb_buffer_pool_size anpassen: Standardmäßig ist der InnoDB-Pufferpool von MySQL auf 128 MB eingestellt – das ist auf einem Server mit 64 GB+ RAM nicht wirklich brauchbar. Stell ihn für datenbankintensive Workloads auf 70–80 % des verfügbaren RAM ein. Die MySQL-Dokumentation enthält die Formel und Konfigurationsoptionen.
6. Transparent Huge Pages: Bei manchen Workloads kann das Deaktivieren von THP (echo never > /sys/kernel/mm/transparent_hugepage/enabled) die Latenz bei der Speicherverwaltung verringern. Bei anderen kann das Aktivieren den Durchsatz verbessern. Probier's einfach mit deiner spezifischen Workload aus.

I/O-gebundene Workloads

7. Wechsel zu NVMe noch nicht geschehen: Der Sprung von SSD NVMe sorgt NVMe für einen 3- bis 5-mal höheren sequenziellen Durchsatz und deutlich geringere Latenzzeiten. Die aktuellen dedizierten Server von InMotion kommen NVMe mit NVMe .
8. RAID-Konfiguration: RAID-1 (Spiegelung) bietet Redundanz ohne Einbußen bei der Schreibleistung, aber ohne Verbesserung der Leseleistung bei zufälligen E/A-Vorgängen. RAID-10 verdoppelt sowohl die Leseleistung als auch die Redundanzkosten. Wähle den RAID-Level entsprechend deinen Anforderungen aus: brauchst du Lesebeschleunigung, Schreibschutz oder beides?
9. Wahl des Dateisystems: XFS kann besser mit großen Dateien und hohen Durchsatz-Workloads umgehen als ext4. Bei Datenbankservern macht ext4 mit den Mount-Optionen noatime und data=writeback den Unterschied fast wett.

Wichtige Alarmschwellen festlegen

Das Ziel ist nicht, jedes Mal eine Warnung zu bekommen, wenn die CPU-Auslastung über 80 % geht. Das Ziel ist, eine Warnung zu bekommen, bevor die Nutzer ein Problem merken.

Praktische Schwellenwerte für Warnmeldungen bei dedizierten Servern:

• Die durchschnittliche CPU-Auslastung ist seit mehr als 5 Minuten über 2x so hoch wie die Anzahl der Kerne.
• Der verfügbare Speicher ist seit mehr als 10 Minuten unter 10 % des Gesamtvolumens.
• Die Wartezeit für Festplatten-E/A geht über 20 ms hinaus und dauert mehr als 5 Minuten.
• Swap-Nutzung steigt über 15 Minuten lang ständig an (dauerhaft, kein kurzer Anstieg)
• Jede Festplatte, die SMART-Warnungen vor einem Ausfall anzeigt

InMotion HostingPremier Care-ServiceInMotion Hosting umfasst die Serverüberwachung als Teil der Managed-Service-Ebene. Für Teams, die ihre eigene Überwachungsinfrastruktur betreiben, erfassen die oben genannten Schwellenwerte echte Probleme und halten gleichzeitig die Anzahl der Fehlalarme so gering, dass sie leicht zu handhaben sind.Weiterführende Literatur: Optimierung der Netzwerklatenz für dedizierte Server | Best Practices für die Serverhärtung