Wie kann ich Performance-Einschränkungen bei meinem Server prüfen?
Inhalt
- Performance-Probleme im Allgemeinen
- Windows-Server
- Linux-Server
- Wie kann mich der STRATO-Support unterstützen?
1. Performance-Probleme im Allgemeinen
Arbeitet der Server nicht mit der Leistung, die er mitbringen sollte bzw. die erwartet wird, sprechen wir von einer schlechten Performance. Die Ursachen dafür können sehr vielfältig sein und oftmals auch dort liegen, wo wir sie nicht erwarten. Deshalb soll Ihnen dieser Artikel dabei helfen, die Ursachen einzugrenzen und ihnen auf den Grund zu gehen.
Arten von Performance-Problemen
Es gibt verschiede Arten von Performance-Einschränkungen, die sich allerdings in der Bedienung des Servers ähnlich zeigen können. Es ist hier sehr wichtig, den eigentlichen “Flaschenhals” zu finden.
Mögliche Probleme:
- langsame Festplatte / SSD
Ist eine Festplatte sehr langsam zeigt sich das vor allem an einem sehr zähen Verhalten beim Login und / oder dem Start von Programmen. Sind die Programme aber erst einmal gestartet läuft in der Regel alles recht zügig. Probleme tauchen meistens erst wieder auf, wenn die Auslagerungs-Datei oder -Partition genutzt wird oder Daten nachgeladen bzw. gespeichert werden müssen.
- langsame Netzwerk-Anbindung
Wenn die Netzwerk-Anbindung ausgelastet oder zu langsam ist, zeigen sich die verschiedensten Probleme. Dies kann von einer falschen Zeit bis zu einer Fehlermeldung beim Abruf der Webseite reichen. Da, gerade auf Servern, viele Funktionen und Dienste davon abhängen, dass die Netzwerk-Verbindung einwandfrei funktioniert, sind die Arten der Probleme, die sich zeigen, ebenfalls sehr vielfältig.
- Hohe System- oder CPU-Last
Eine hohe Auslastung der CPU bzw. des gesamten Systems ist der wohl bekannteste Fall von Performance-Problemen. Hier kommt es zu einer generellen Verzögerung bei der Darstellung und auch der Antwortzeiten. Der Server ist nicht so “responsiv” wie man es eigentlich erwartet.
Sporadisch oder dauerhaft
Es ist sehr wichtig zu unterscheiden, ob die Probleme, die Sie bei der Nutzung des STRATO-Servers erfahren, dauerhaft vorhanden sind oder ob diese nur zu bestimmten Zeiten auftreten.
Wenn es sich um ein zeitlich beschränktes Verhalten handelt, prüfen Sie bitte auch, ob sich ein Muster (z.B. jeden Donnerstag um 13:00 Uhr) erkennen lässt.
Ist ein Muster erkennbar, prüfen Sie bitte, ob hier eine geplante Aufgabe (z.B. ein Backup) die Ursache sein kann und planen dies um. Ändert sich dann der Zeitpunkt der Performance-Probleme mit, haben Sie den Verursacher bereits gefunden.
Server-Monitoring und Logs
Schon die Logs, die vom System normalerweise erzeugt werden, können erste Hinweise auf die Ursache von Performance-Problemen liefern. Es lohnt sich also immer die System-Logs zu prüfen.
Unter Linux können Sie sich die Kernel-Logs mittels sudo dmesg anzeigen lassen (hier tauchen vor allem Hardware-Fehler, wie z.B. Probleme der Festplatte auf). Weitere Logs bekommen Sie mit dem Befehl journalctl (hier lohnt es sich einen Blick auf die man-Page für die verschiedenen Optionen zu werfen) oder in den Log-Dateien direkt unter /var/log.
Unter Windows ist die Ereignisanzeige in der Computerverwaltung der Anlaufpunkt für die Logs. Hier ist der Einsatz der verschiedenen Filter wichtig, da hier alle Ereignisse gesammelt werden. Auch bei einem gut laufenden System ist es normal, dass hier verschiedene Warnungen oder sogar Fehler angezeigt werden.
Ein Monitoring des Servers ist auf jeden Fall zu empfehlen, damit Sie auch im Nachhinein prüfen können, was auf dem Server vorgefallen ist. Es ist schwierig auf dem Server nachzuschauen, wenn die Performance-Probleme gerade akut sind.
Es gibt sowohl für Linux als auch für Windows eine Vielzahl von Monitoring Lösungen. Diese reichen von einem einfachen Aufzeichnen einiger Eckdaten in einem Logfile bis zu ausgewachsenen Lösungen mit Aufzeichnung und Präsentation der Daten für mehrere Server.
Generell unterscheidet man zwischen einem Echtzeit-Monitoring und einem Langzeit-Monitoring. Beim Echtzeit-Monitoring werden die Daten häufiger abgefragt, allerdings nicht so lange gespeichert. Hier können Sie selten weiter als eine Stunde zurückgehen. Im Gegensatz dazu werden die Daten bei einem Langzeit-Monitoring länger aufbewahrt (je nach Einstellung, Tage, Wochen oder sogar Monate bis Jahre zurück). Allerdings werden die Daten nicht so häufig abgefragt.
Einige Beispiele für Monitoring-Systeme sind Netdata, collectd, Nagios und Prometheus. Grafana selbst ist kein Monitoring, sondern dient der Aufbereitung der gesammelten Daten (auch aus verschiedenen Quellen).
Bei einem unserer neuen dedizierten Server mit Cloud Panel oder bei den Servern in der Server Cloud empfiehlt es sich, ein Monitoring einzurichten. Eine Anleitung dazu finden Sie hier für die dedizierten Server und hier für die Server-Cloud.
Unter Windows steht im Task-Manager auch eine Echtzeit-Überwachung im Tab ”Leistung” zur Verfügung. Für genauere Informationen können Sie von hier aus den Ressourcen-Monitor aufrufen. Hier lässt sich auch der Verursacher z.B. hohe Netzwerkverwendung eingrenzen.
2. Windows Server
Auf einem Windows-Server ist der erste Anlaufpunkt für eine Prüfung des aktuellen Zustandes der Leistungs-Tab des Task-Managers. Der Task-Manager lässt sich entweder über die Tastenkombination “Strg+Shift+Esc” öffnen oder ist über das Kontextmenü via Rechtsklick auf das Windows-Symbol erreichbar.
Wie bei allen Performance-Tests ist es am besten, sie mehrfach und zu unterschiedlichen Tageszeiten durchzuführen. Nur so erhalten Sie einen aussagekräftigen Überblick über die Server-Performance. Ein einzelner Test ist lediglich ein Schnappschuss der aktuellen Situation.
Bei vorübergehend auftretenden Einschränkungen sollten Sie die Tests während des Auftretens der Einschränkung durchführen. Messwerte im Normalzustand, wenn alles funktioniert, helfen hier nicht weiter.
Test der Festplatten / SSD Performance
Die einfachste Methode die Festplatten-Performance unter Windows zu testen ist es, die Leistungsbewertung von Windows zu verwenden. Hierzu gibt es das Tool winsat, das Sie über die Eingabeaufforderung (Windows Server 2016) oder die Powershell (Windows Server 2019) aufrufen können. Beide müssen jeweils mit Administrator-Rechten geöffnet werden.
Um die Lesegeschwindigkeit zu testen, geben Sie ein:winsat disk -seq -read -drive X
Für einen Test der Schreibgeschwindigkeit verwenden Sie:winsat disk -seq -write -drive X
Ersetzen Sie das X durch den jeweiligen Laufwerksbuchstaben (in der Regel C und/oder D). Eine Ausgabe kann beispielsweise so aussehen:
Unter Windows Server 2012 R2 steht winsat nicht zur Verfügung. Auf einem Windows V-Server Vxx steht winsat zwar zur Verfügung, funktioniert aber nicht. In beiden Fällen können Sie andere Tools verwenden, die allerdings separat installiert werden müssen. Hier bieten sich beispielsweise Crystal Disk Mark oder h2bench an.
Test der Netzwerk-Anbindung
Einen Test der Netzwerk-Anbindung können Sie mit verschiedenen Speed-Tests vornehmen, mit denen Sie auch Ihre heimische Internet-Anbindung testen können. Auch hier empfiehlt es sich, diese Tests zu verschiedenen Zeiten und mit verschiedenen Anbietern vorzunehmen.
Folgend ein Beispiel, wie ein solcher Test aussehen kann:
Die CPU- und Systemlast
Für die CPU-Last und generell die Systemlast ist der erste Anlaufpunkt der Leistungs-Tab des Task-Managers und der Ressourcen-Monitor von Windows.
Sie können auch spezielle CPU-Stress-Tests durchführen, wenn Sie vermuten, dass eine hohe Auslastung zu Instabilitäten führt. Dazu gibt es spezielle Programme von anderen Anbietern, die ausdrücklich installiert werden müssen. Bei den V-Servern ist die Aussagekraft aber eingeschränkt, da die Ergebnisse stark vom aktuellen Zustand der Virtualisierung abhängt.
Bei einem Server mit Cloud Panel können Sie das Monitoring aktivieren (und am besten einen Monitoring-Agenten installieren). Dadurch können Sie die Werte direkt im Cloud Panel auslesen:
Sonderfälle
Eine hohe Auslastung des Arbeitsspeichers bei einem V-Server Windows
Die Arbeitsspeichers-Anzeige im Task-Manager Ihres Windows V-Servers bewegt sich am oberen Limit? Wir erklären, woran das liegt. Die Anzeige des verfügbaren Arbeitsspeichers liegt dabei teilweise unterhalb der garantierten Arbeitsspeicher-Größe Ihres Windows V-Servers.
Die Ursache für dieses Verhalten liegt im Speichermanagement der Virtualisierungsplattform, denn die Zuweisung des Arbeitsspeichers erfolgt dynamisch. Ihrem Windows V-Server wird, zuzüglich eines kleinen Puffers, immer so viel Arbeitsspeicher zugewiesen, wie dieser aktuell benötigt. Steigt die Auslastung, steigt auch die Größe des zugewiesenen Arbeitsspeichers an.
Beispiel:
Die Anwendungen Ihres Windows V-Servers benötigen 1,2 Gigabyte Arbeitsspeicher, zugewiesen werden 1,44 Gigabyte Arbeitsspeicher. Der Arbeitsspeicherbedarf Ihres Servers steigt auf 2 Gigabyte, der zugewiesene Arbeitsspeicherbedarf steigt dann auf 2,4 Gigabyte. Eine Steigerung der Arbeitsspeichergröße ist bis mindestens der garantierten Arbeitsspeichers-Größe Ihres V-Servers möglich.3. Linux Server
Um Performance-Problemen bei einem Linux-Server auf den Grund gehen zu können, benötigen wir einige Angaben und die Ergebnisse von verschiedenen Tests.
Wie bei allen Performance-Tests ist es am besten, die Tests mehrfach und zu unterschiedlichen Tageszeiten durchzuführen. Nur so erhalten Sie einen aussagekräftigen Überblick über die Server-Performance. Ein einzelner Test ist lediglich ein Schnappschuss der aktuellen Situation.
Bei vorübergehend auftretenden Einschränkungen sollten Sie die Tests während der Einschränkung durchführen. Messwerte im Normalzustand, wenn alles funktioniert, helfen nicht weiter.
Test der Festplatten / SSD Performance
Für den Test der Festplatten bzw. der SSD verwenden Sie bitte das Programm fio, den “Flexible I/O Tester”. Dieses muss unter Umständen in Ihrer Distribution nachinstalliert werden. Der Vorteil hier ist, dass der Test auch bei einer Speicheranbindung, wie sie bei unseren V-Servern zum Einsatz kommt, realistische Ergebnisse liefert. Ein Test mit dd ist aufgrund der unterschiedlichen Speichertechnologie, die verwendet wird, nicht repräsentativ. Gehen Sie wie folgt vor:
Für einen Test der Schreibgeschwindigkeit:
sudo fio --rw=write --name=FIO --size=1G --filename=testfile
Es wird dabei eine 1 GB große Datei "testfile" erzeugt. Diese kann auch für den nachfolgenden Test verwendet werden.
Für einen Test der Lesegeschwindigkeit:
sudo fio --rw=read --name=FIO --size=1G --filename=testfile
Nach Abschluß der Tests mit fio kann die Datei “testfile” wieder gelöscht werden:
sudo rm testfile
Auch eine stark belegte Partition kann zu Performance-Problemen führen. Prüfen Sie daher die Belegung der Partitionen:
sudo df -h
Auch interessant ist die Belegung der sogenannten iNodes, da es auch bei der Knappheit der inodes zu Performance-Problemen kommen kann:
sudo df -hi
Bei einem dedizierten Server kann auch eine teilweise oder vollständig defekte Festplatte oder SSD als Ursache in Frage kommen. Haben Sie den Verdacht, dass dies der Fall ist, starten Sie bitte den Server im Rettungssystem und prüfen folgendes:
Wurden die Festplatten alle erkannt?
Befehl: lsblk
Hier werden die erkannten Festplatten und deren Partitionen angezeigt. Die Festplatte oder SSD selbst findet sich als sda und/oder sdb und vielleicht sdc wieder. Stimmt die Anzahl und die erkannte Größe mit den Angaben zu Ihrem Server überein?
Die Laufwerke (Festplatte und SSD) haben mittels SMART einige Selbsttestfähigkeiten, über die Sie sich die SMART-Werte ausgeben lassen können. Grundlegende Informationen zur Festplatte erhalten sie mit
smartctl -i /dev/sdX
Eine vollständige Ausgabe erhalten Sie mit
smartctl -a /dev/sdX
(Ersetzen Sie das X durch den jeweiligen Buchstaben entsprechend der Anzeige von lsblk).
Hinweis: die Angaben “pre-fail” oder “old-age” sind bei den Attributen normal. Erst wenn hier etwas anderes, wie z.B. “Failing now” steht, besteht Grund zur Sorge.
Sie können die Ausgaben von lsblk und smartctl auch in eine Datei umlenken und uns diese zur Analyse zukommen lassen. Bitte sprechen Sie dies auf jeden Fall vorher mit unserem Support ab.
Test der Netzwerkanbindung
Um sich die aktuell offenen Netzwerkverbindungen anzeigen zu lassen, verwenden Sie am besten den Befehl:
sudo ss -tpn
Wenn die Verbindungsprobleme nur bestimmte Dienste oder Programme betreffen (z.B. den Webserver), können Sie auf dem Server auch prüfen, welche Prozesse gerade auf Verbindungen von außen warten:
sudo ss -tulpn
Bei den V-Servern Linux ist die Anzahl der gleichzeitigen Verbindungen limitiert. Prüfen Sie bitte in der Datei /proc/user_beancounters die Werte “numtcpsock” (maximale Anzahl der TCP-Verbindungen) und “numothersock” (maximale Anzahl Nicht-TCP-Verbindungen, dazu gehören auch lokale Unix-Sockets).
Um die Netzwerkgeschwindigkeit zu testen, empfehlen wir einen Upload und einen Download einer großen Datei von und zu einem anderen Server oder einem Cloud-Speicher. Hier sollte ein Programm verwendet werden, das die Übertragungsgeschwindigkeit anzeigt (z.B. wget, curl oder scp).
Einen Test mittels “speedtest” oder “speedtest-cli” empfehlen wir nicht, da es je nach eingesetzter Version und Umgebung zu falschen Ergebnissen kommen kann.
Ein Test auf Paketverluste lässt sich mit einem ping testen. Am einfachsten geht das vom Arbeitsplatz aus. Eine Kommandozeile (oder ein Terminal) öffnen und den Server anpingen:
Linux: ping -c <Anzahl> <Server-Adresse>
Windows: ping -n <Anzahl> <Server-Adresse>
Als Anzahl sollte ein Wert gewählt werden, bei dem sich einschätzen lässt, wie viele Pakete verloren gehen. Wir empfehlen mit mindestens 10 bis 20 Paketen zu testen.
Bei Verbindungsproblemen helfen auch Angaben mittels eines Traceroutes. Hier wird der Weg, den ein Paket nimmt nachverfolgt. Auch hier können Sie den Test von Ihrem Arbeitsplatz aus mit einer Kommandozeile bzw. einem Terminal starten:
Linux: traceroute <Server-Adresse>
Windows: tracert <Server-Adresse>
Die CPU- und Systemlast
Einen Überblick über die aktuelle CPU-Auslastung erhalten Sie mit dem Programm top (Anzeige beenden mit der Taste q). Bei der Standard-Sortierung wird der Prozess ganz oben angezeigt, der am meisten CPU-Leistung verbraucht.
Eine bessere Übersicht bekommen Sie mit dem Programm htop, das meist nachinstalliert werden muss.
Eine komplette Liste, welche Prozesse gerade laufen, können Sie mit diesem Befehl erzeugen:
sudo ps -ely
Die Speicherbelegung können Sie sich ebenfalls anzeigen lassen. Hierbei wird auch die Verwendung des Swap-Speichers (Auslagerung) angezeigt:
sudo free -h
Eine Verwendung des Swap-Speichers führt häufig zu deutlichen Performance-Einbrüchen, selbst wenn auf eine SSD ausgelagert wird.
Eine hohe Speicherbelegung kann auch durch ein Programm- oder Konfigurationsfehler vorkommen. Eine andere Ursache ist möglicherweise eine hohe Anzahl an (Webseiten-)Zugriffen und in diesem Fall ein Anzeichen dafür, dass das aktuell verwendete System für die Anforderungen zu klein ist.
Sonderfälle
Linux V-Server Begrenzungen
Die Linux V-Server unterliegen gewissen Beschränkungen. Prüfen Sie hierzu bitte die Datei /proc/user_beancounters auf Überschreitung der Begrenzungen. In der Datei wird in der letzten Spalte angezeigt, wie oft die jeweilige Begrenzung seit dem letzten Systemstart überschritten wurde.
Eine Überschreitung einiger Werte kann dazu führen, dass sich keine neuen Prozesse mehr starten lassen. Einige Programme versuchen dies trotzdem immer wieder und erhöhen dadurch die Systemlast.
Werden die Grenzen durch den normalen Betrieb überschritten, wenden Sie sich bitte an unseren Support. Hier kann festgestellt werden, ob ein Upgrade des Servers hilfreich ist.
Prozesse vs. Threads bei Linux V-Servern
Es können keine neuen Prozesse gestartet werden, obwohl die Begrenzungen oben nicht überschritten wurden? Es kommt zu Meldungen, dass nicht genug Speicher frei sei, obwohl noch genug Speicher verfügbar ist?
In dem Fall handelt es sich um eine Begrenzung durch eine Einstellung in Linux selbst. Der Wert dafür heißt "DefaultTasksMax".
Um den aktuellen Grenzwert zu ermitteln, geben Sie in der Shell bitte folgendes Kommando ein:
systemctl show --property=DefaultTasksMax
Dieser Wert gibt an, wie viele Threads ein Prozess starten darf. Es steht Ihnen frei, den Wert nach Ihren Bedürfnissen in der Datei /etc/systemd/system.conf festzulegen. Bitte starten Sie nach einer Änderung den Server neu, damit die neue Einstellung auch vollständig wirksam wird.
Dieser Wert kann in diesen Dateien eingestellt werden:
/etc/systemd/system.conf
/etc/systemd/system.conf.d/*.conf
/run/systemd/system.conf.d/*.conf
/usr/lib/systemd/system.conf.d/*.conf
/etc/systemd/user.conf
/etc/systemd/user.conf.d/*.conf
/run/systemd/user.conf.d/*.conf
/usr/lib/systemd/user.conf.d/*.conf
Prüfen Sie diese Dateien bitte, wenn Sie eine Änderung des Wertes vorgenommen haben, welche jedoch nicht umgesetzt wird.
Weitere Informationen über konfigurierbare Parameter erhalten Sie mit:
man systemd-system.conf
Hohe Auslastung durch rsyslogd (Ubuntu 12.04 und 14.04)
Bei der Verwendung von Ubuntu 14.04. und Ubuntu 12.04. kommt ein bekannter Bug mit dem rsyslogd zum Tragen. Dieser hat eine erhöhte Systemauslastung zur Folge. Der Fehler tritt bei neueren Ubuntu-Versionen nicht mehr auf.
Ursächlich ist das aktivierte Kernel-Logging im Konfigurationsfile des rsyslogd. Unter der von STRATO verwendeten Virtualisierungsplattform funktioniert dies nicht.
Sie können in wenigen Schritten prüfen, ob dieser Bug für eine erhöhte Auslastung ihres V-Servers ursächlich ist.
Überprüfung des Logfiles
Prüfen Sie bitte, ob im Logfile Ihres V-Servers unter /var/log/syslog die nachfolgenden Zeilen wiederholt ausgegeben werden:Nov 12 18:22:19 h123456 rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor]Nov 12 18:22:25 h123456 rsyslogd-2177: rsyslogd[internal_messages]: 2954152 messages lost due to rate-limiting
Die Auslastung (load) Ihres Servers überprüfen
Die Auslastung Ihres Servers können Sie mittels SSH-Zugriff und dem Befehl top ermitteln. Stellen Sie dazu bitte mit dem Programm putty die Verbindung zu Ihrem Server her und geben den Befehl top ein.
In der folgenden Ausgabe können Sie die Auslastung durch die einzelnen Tasks Ihres Servers einsehen. Kontrollieren Sie bitte den Command rsyslogd und die CPU-Auslastung zu diesem Task.PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND371 syslog 20 0 261940 1500 944 S 100,1 0,0 2:00.82 rsyslogd
Hat dieser Task eine sehr hohe CPU-Auslastung, ist dieser für die Performance-Probleme Ihres V-Servers verantwortlich. In wenigen Schritten können Sie den Bug beheben.
Behebung des Bugs
Halten Sie den Dienst rsyslogd mit diesem Befehl an:
sudo service rsyslog stop
Im nächsten Schritt deaktivieren Sie das Kernel-Logging:
sudo sed -i -e 's/^\$ModLoad imklog/#\$ModLoad imklog/g' /etc/rsyslog.conf
Alternativ können Sie auch die Datei /etc/rsyslog.conf mittels eines Editors (z.B. Notepad) prüfen und diese Zeile auskommentieren:
$ModLoad imklog # provides kernel logging support
Zum auskommentieren stellen Sie der Zeile bitte ein #-Zeichen voran.
Starten Sie den Dienst rsyslogd mit diesem Befehl am Ende wieder:
sudo service rsyslog start
Der Dienst rsyslogd wird zukünftig nicht mehr die Performance Ihres V-Servers übermäßig beeinflussen.
4. Wie kann mich der STRATO-Support unterstützen?
Haben Sie anhand der bisherigen Hinweise keine Ursache für die Performance-Schwankungen finden können, können Sie sich an den Support wenden. Die Kollegen benötigen für eine genaue Prüfung einige Angaben. Dies sind folgende:
- Wie genau zeigen sich die Performance-Probleme?
Beispiel.: “Webseite xyz.de lädt sehr langsam” oder “Sehr langsamer Up- und Download zum Server” - Wann genau tritt die Performance-Problematik auf?
Beispiel: “Dauerhaft seit 2 Tagen” oder “Jeden Freitag um 15:00 Uhr”. - Welche Windows-Version bzw. Linux-Distribution verwenden Sie? (Sind alle Updates installiert?)
- Die Messwerte zu den Festplatten / SSDs (siehe oben)
- Bei einer defekten Festplatte oder SSD mindestens die Seriennummer der Festplatte, die noch in Ordnung ist (kann z.B. mit smartctl ausgelesen werden)
- Die Netzwerkverbindungen und Ergebnisse vom Up- und Download (siehe oben)
- Die Auswertungen der Prozesse und Speicherbelegung (siehe oben)
- speziell bei Windows-Servern:
- Angaben aus der Windows-Ereignisanzeige (gefiltert)
- Anzeige der CPU- und Systemlast (siehe oben)
- Je nach Verfügbarkeit auch Werte von einem Langzeit-Monitoring
- speziell bei Linux-Servern:
- Die Ausgabe des Kernel-Logs (
sudo dmesg) - bei Linux V-Servern: Inhalt der Datei
/proc/user_beancounters
- Die Ausgabe des Kernel-Logs (