Einer oder gleich mehrere der Dienste auf Ihrem Linux VServer läuft verdächtig langsam, Sie können aber sicher ausschließen, dass es an der Konfiguration des Daemons liegt? Oder sie planen die Anschaffung eines VServers, wissen aber nicht, welche hardware-Konfiguration Sie dazu brauchen?

Oft überschätzen Kunden die Performance Ihres VServers – und unterschätzen die Anforderungen und Komplexität von vielen Anwendungsszenarien, die sie auf ihm realisieren wollen.

Grundsätzlich kann es sein, dass Ihr VServer aufgrund eines technischen Fehlers oder Versehen vom Serverhoster nur noch eingeschränkte Ressourcen zugewiesen bekommt. Supportforen sind voll mit solchen Fehlern. Als erstes sollten Sie also wirklich das untere Kapitel aufgreifen und die Ressourcen Ihres Servers bestimmen. Vergleichen Sie Ihre Ergebnisse mit denen anderer Kunden mit dem selben Vserver-Paket. Liegen ihre WErte deutlich unter den Vergleichswerten, wenden Sie sich an den Support.

Was Sie ebenfalls ausschließen sollten – ist – dass in Ihren Server eingedrungen wurde und Sie nun Teil eines botnetzes geworden sind. Das kann nämlich auch rechtliche Konsequenzen für Sie haben! Ist die Performance Ihres VSErvers nicht von Anfang an schlecht, sondern erst seit einem gewissen Zeitraum,liegt die Vermutung nahe, dass Ihr Server im Hintergrund Ressourcen für ungebetene Gäste verwendet. Hier sollten Sie einen grundlegenden Sicherheitscheck durchführen – wenn möglich, sichern Sie Ihre Daten und installieren das Serverpaket sogar komplett neu – und kümmern Sie sich im nächsten Anlauf um eine entsprechende Absicherung.

Es kann aber auch sein, dass Sie sich einfach verschätzt haben. Die Installation einer WordPress- oder Joomla-Website beispielsweise braucht mehr Ressourcen, als Sie vielleicht glauben – und zwar im Hinblick auf die CPU-Leisstung und die Netzwerkbandbreite. Oftmals sind dedizierte Hostingspakete – wie beispielsweise dedizierter Webspace – besser für die meisten Anwendungsszenarien. Natürlich wollen viele dennoch einen VServer haben, da er grundsätzlich mehr Freiheiten und Kontrolle über den Web- und Mailserver bietet. Besonders Webentwickler sind oftmals frustriert, wenn ein Webspacepaket eines Kunden bestimmte Addons nicht mitliefert und dessen Installation ausschließt, die man aber im Entwicklungsprozess verwendet hat. Seien Sie aber nicht stur: Viele heutige Pakete geben dem Kunden aufgrund des Wettbewerbes uaf dem Markt immer mehr Kontrolle über seine Hostingumgebung. Sie müssen sich nur richtig umsehen. Sollte dennoch kein Paket Ihren Anforderungen entsprechen, müssen Sie umdenken.

In diesem Fall müssen Sie dann entweder auf ein leistungsstärkeres Paket upgraden oder sich die Anschaffung eines Root-Servers, der zu 100% Ihnen gehört, überlegen. Denn mit einem Root-Server teilen Sie sich nicht die Ressourcen mit anderen Nutzern. Für Power-User kann es sich sogar rentieren, sich selbst einen Server anzuschaffen, diesen zu Hause auf seine Performance zu testen und ihn dann über Server-Housing in ein Rechenzentrum stellen zu lassen.

In diesem Post werden wir erstmal erläutern, wie man die Hardwareressourcen für einen einzigen Server, unabhängig vom zu verwendenden Dienst (egal ob Webserver, GAmeserver, Voiceserver oder kombinierte Dienste) feststellt und kalkuliert. Desweiteren werden wir lernen, wie man die derzeitigen Hardwareressourcen eines Servers durch Tests bestimmt, damit man Sie a) mit den kalkulierten Ressourcen und b) vielleicht sogar mit den versprochenen Ressourcen auf der Angebotsausschreibung des hosters vergleichen kann – so kann man sich vllt vor Betrug schützen.

Die Anforderungen meines Servers feststellen

Um feststellen zu können, welche Anforderungen ihr Server braucht, müssen natürlich die Services bekannt sein, die auf dem Server laufen.

Festplattenspeicher

Festplattenspeicher zu berechnen ist ebenfalls eine Kunst. Was man fest berechnen kann, ist der speicher der zur Installation der Services notwendig ist. Das basiert auf Erfahrungswerten, die Sie sich ganzu einfach online oder durch ausprobieren beschaffen können. Große Serverdienste wie beispielsweise Microsoft- oder SAP-Produkte bracuhen zur Installation gut und gerne mal größen zwichen 10 und 50 GB. Acuh bei einer website können Sie in der regel schon im Voraus feststellen, wei viel Speicherplatz Sie beim Upload benötigten.

Aber auch hier sollten Sie einen Puffer für Updates hinzurechnen. Bei Serverprodukten von Microsoft und SAP beispielsweise Updates für die Serversoftware selbst, aber auch bei Webanwendungen kommen für die Module des Entwicklungsframeworks desöfteren updates raus. Planen Sie hier auf jeden FAll erstmal ein plus von 10% der Installationsgröße ein – alles was darüber geht, kann man nicht wirklkich voraussagen und muss dann spontan durch eine zusätzliche Platte bewältigt werden. die nutzung von Logical Volumes hilft hier auf jeden Fall weiter.

Dann brauchen Sie noch die Größe Ihres Swap-Speichers. Dieser bekommt in der regle eine extra Partition. Hierbei mus sman den Swap-Sepciher nicht messen, sondern man kann sich an folgende einfache Regel halten

Menge  an RAM im System	Empfohlene Swap Größe
2 GB oder weniger	2 mal RAM Größe
2GB bis 8 GB	1-fache RAM Größe
8 GB bis 64 GB	0,5-fache RAM Größe
ab 64GB	4 GB Gesamtgröße

 

diese Richtlinienwerte für den Swap-Speicher können sich bei großen Serverdiensten wie Microsoft Active Directory oder SAP NetWeaver verändern. Vergessen Sie jedenfalls nicht, den Swap-Speicher in die Berechnung Ihrer Speicherberechnung miteinzubeziehen.

Eine Übersicht über die aktuelle Nutzung des virutal memory kann Ihnen das kommando vmstat liefern.

Neben diesen noch relativ einfach zu berechnenden Größen kommen aber die beiden größten Datenfresser hinzu: Datenbanktabellen und Multimedia-Daten – besonders bei Webanwendungen mit vielen Usern sind dies die beiden größten Positionen, die Sie im Augenschein haben sollten. Als erstes sollten Sie die Basisgröße der Multimedia-Daten und Datenbanktabellen feststellen, wenn Sie die Anwendung frisch hochladen. Danach sollten Sie die Weblösung probeweiser in einer LAN-Umgebung oder beispielsweise auf einem kleinen Testserver eine weile laufen lassen. Wichtig ist, die Wachstumsrate bei einer bestimmten Useranzahl festzustellen und ständig im Auge zu behalten. Messen Sie beispielswiese das Wachstum der Datenbank und der Multimedia-Daten im Zeitraum von drei Monaten bei einer konstanten Userzahl zwiscehn 50 und 100 angemeldeten Benutzern.

Diesen Wachstumsfaktor setzen Sei jetzt ins Verhältnis zur Anzahl der angemeldeten Benutzer. Sie haben nun den durchschnittlichen Wachstumsfaktor von Datenbank und Mediadateien pro User und Monat.

Jetzt messen Sie, wie viele User Sie im Durchschnitt im Monat dazugewinnen, und nehmen dies mit dem Wachstumfaktor pro User und Monat und der bisherigen Speichergröße von Datenbank und Multimediadateien mal. Wenn Sie dieses Ergebnis nun mit der Anzhal Monate, die Sie in die Zukunft planen wollen, mal nehmen, und die Installationsgröße von Betriebsystem und Serveranwendungen drauf addieren, erhalten Sie den Speicherplatz, den sie in der Zukunft brauchen werden.

Festplattenzugriff (Schreibe-/Lesedurchsatz , I/O, „Throughput“)

Bei manhcen diensten können Sie berechnen, wie schnell Ihre Festplatte auf Daten zurgeifen können muss. Bei einem Webserver beispielsweise gibt es Modukle, mit denen Sie messen können, wie lange eine webiste zum Laden braucht und wie groß Sie ist. Obwohl diese Daten grundsätzlich in den Arbeitsspeciher geladen werden, mussten die daten zur Erzeugung ddieser Seite grundsätzlich von der Festplatte gelesen werden – der Quellcode der Seite und der Datenbankinhalt von der datnebanktabelle, die ebenfalls auf der Festplatte liegt. Führen Sie heir einige Basismessungen durch und berechnen Sie die Durchschnittsladezeit einer website und die durchschnittsgröße all ihrer websiten, die geladen werden sollen.

Wenn Sie jetzt noch wissen, wie viele Seitenzugriff esie gleichzeitig haben wollen, sagen wir mal 150, dann können sie nun berechnen, welche Zugriffsgeschwindigkeit Sie haben müssen durch

<Gewünshcte gleichzeitige Seitenzugriffe> / <druchschnittliche Ladezeit> * <Durchschnittliche Größe der WEbsiten>

die durchschnittliche Ladezeit ziehen wir mit ein, weil: wenn beispielsweise Ihre Seiten in durchschnittlich 2 Sekunden geladen werden, dann müssen Sie ja die Größe durch zwei teilen

Sie haben aber auch Festplatten zugriffe durch das Betriebssystem selbst.  Davon müssen Sie wieder den Durchschnitt pro Sekunde rehcnen und mit in die ´Lesegeschwindigkeit einrechnen, da auch diese Datne gelesen werden müssen.desweiteren können Sie bei einigen Diensten solche berechnungen nicht anstellen. In diesem Fall müssen Sie messen. Das geht mit den Linux Kommandos iotop und iostat.

Bei Festpaltten ist es so, dass bei konstanter Rotationsgeschwindigkeit der Datendurchsatz am äußeren Rand der plattenscheiben höher ist als im Inneren. Da Festplaten von außen nach innen beschrieben werden, ist der Druchsatz am Beginn des Datenbereichs somit höher als am Ende des Datnebereichs der festpaltte.  Wenn Sie also mehrere Festplatten miteinander vergleichen, achten Sie darauf, jeweils die gleichen Bereiche der platten zu vergleichen. Am einfachsten testet man Festplatten direkt am Beginn des Datenbereichs. Wenn Sie eher das ende testen möchten, beginnen Sie über Offset-paramter der Performance-Tools bei beispeislweise 90% Kapazität der festplatte.

Das Testen von festplatten-Lese- und Schreibperformance am Beginn des Datenbereichs geht beispielsweise über

fio --filename=/dev/sdd --direct=1 --rw=read --bs=1m --size=5G --offset=0G --name=file1

und

dd if=/dev/sdd of=/dev/null bs=1M count=5120 iflag=direct)

Das messen am Ende des Datenbereichs über

fio --filename=/dev/sdd --direct=1 --rw=read --bs=1m --size=5G --offset=460G --name=file1

und

dd if=/dev/sdd of=/dev/null bs=1M count=5120 skip=471040 iflag=direct

 

mit dem fio-Befehl messen Sie den Lesedurchsazu, mit dem dd-Befehl den Schreibdurchsatz.

sie könenn die Schreibperformance auch testen, indem sie über fio ein großes File schreiben lassen

fio --direct=1 --rw=write --offset=<ihr offest> --bs=1M --name=test --size=10G --filename=testfile

sie können aber auch einen ganzen Datenträger vollschrieben lassen (das sollten Sie nicht auf einer systempartition machen). Vorsicht hierbei, da Sie damit auch Produktivdaten überschrieben können

fio --direct=1 --rw=write --bs=1M --filename=/dev/<device>

Ihnen wird vielleicht auffallen, dass Sie beim Messen der Schreibperformance über dd und fio unterschiedlcihe Ergebnisse herausbekommen. Das liegt daran, dass wir bei dd die Performance mit Einbeziehung des cache / Arbeitsspeichers gemessen haben und bei fio aufgrund des APramters –direct=1 ohne einbezug des Page caches.

Desweiteren können Sie die Performance vonn gemischten, parallel ablaufenden Schreib/-Lesezugriffen testen:

fio --rw=readwrite --name=test --size=50M --direct=1 --bs=1024k --numjobs=2

Die Schreibperformance von SSDs und Flashspeicher kann scih mti dem Füllstand ändern. Eine fast vollgeschribeene SSD hat zumeist eine geringere Schreibperofrmance als eine leere SSD – die bestenfalls zuvor mittels Secure erase vollstädnig gelöscht wurde.

Desweiteren ist es bei SSDs wichtig, dass man beim Messen ihrer IO-Performance immer die gleichen Cache-Einstellugnen verwendet. Der Cache einer SSD, auch DRAM-Puffer geannnt, dient zur Beschleunigung von Schreiboperationen. Um den Cache-Inhalt bei einem stromausfall zu schützen, verfgen manche neueren SSD-Cnotroller über einen Kondensator, um bei Stromausfall die Daten auf einen Flash-Chip zu schreiben.

Beim Testen sollte man außerdem mit zufälligen Daten testen. Manche SSd-Controller haben eine Datenkompression integriert. Testet man mit gleichstrukturierten Daten, führt das zu sehr hohen Messwerten, da hier eine sehr hohe Kompression erreicht werden kann. Diese Werte werden dann aber mit echten Daten nicht erreicht. Deswegen solltenS ie eine solche Festplatte vorher mit zufallsdaten am zu testenden Bereich beschreiben. Um einen zuverlässigen Test einer SSD zu gewährleisten, müssen Sie daher die Befehle zum messen der Performance mit fio so abändern, das Sie zufällig den Paramter –refill_buffers angeben müssen. Damit gewährlesiten sie, dass der Puffer der SSD regelmäßig neu beschrieben wird.

Beachten Sie, dass laufende SMARt-Tests die Performacne der Tests beeinträchtigen. Deswegen sollten sie SMART beim Testen der Festplatten ausschalten.

Ebenfalls beeinträchtigtend ist der Pre-Scan von SAS-Festplatten. Neuere SAS-platten führen vor Beschreiben eines sektors autoamtisch einen Media-Scan durch. Damit sollten defekte Sektoren frühzeitig erkannt werden. Die Schreibperformance sinkt dabei um 50%. Deswegen sollen Sie die Festplatte vor dem Test einam komplett beschreiben. Damit ist der Pre-Scan abgeschlossen und hat somit keine weiteren negativen Auswirkungen auf die Perofmrance.

Wenn sie Festplatten messen, die sich im RAID-Verbund befinden, achten Sie außerdem darauf, dass im Hintergrund keine raid-Initialisierungen, RAId-Verifies etc. ausgeführt werden.

Grnde für geringen Throughput können sein, dass derzeit viele Dateien gleichzeitig auf dem System geöffnet sind. eine Auflistung darüber bietet das Kommando

#>lsof

Das Kommando listet alle derzeit geöffneten Files auf dem System, darunter dateisystem-dateien, netzwerksockets, pipes, devices und prozesse.

 IOPS

Mit IOPTS misst man die Anzahl der möglciehn Ein/ausgabe-operationen pr sekunde. ind er Regel msst mand abei die worst-case-Szeanriern, also zufällig generierte IOPS Lesen und Schrieben – also zufällig erteilte zugriffe. Jeder zugriff überträgt dabei nur sehr wenige Daten.

Im oberen Kapitel haben wir sequenteilles Lesen und Schreiben getestet – die dort ermittelten Größen bezeichnet man als Throughput oder Durchsatz. Mit unseren IOPS-Tests, die ich hier vorstellen werde, werden wir hingegen zufällige Zugriffszeiten testen.

Zum Messen der Schreib- und Lese-Performance bei zufälligen Zugriffen müssen Sie die befehle aus dem oberen Kapitel mit dem Kommando fio nur insoweit abändern, das Sie beim Paramter –rw statt „read“ oder „write“ einfach „randread“ bzw. „randwrite“ schreiben müssen. Statt „readwrite“ schreiben Sie „randrw“.

Hat man die IOPS eines Datenträgers ermittelt, kann man damit die mittlere Zugriffszeit eines Datenträgers berechnen. Die mittlere Zugriffszeit in Sekunden ist der Kehrwert der IOPs.

Arbeitsspeicherkapazität und -durchsatz

Für bestimmte dienste können Sie den Speicher berechnen, für andere Dienste wiederum müssen Sie messen. Nehmen wir an, Sie hosten auf einem Webserver eine dynamische Webanwendung. Rufen Sie mal viele seiten auf, am besten die mit den meisten Daten darin. Mit einem Modul wie beispielsweise „Profiler“ für PHP können Sie sich am Ende eines Ladevorgangs die Zeit und den genutzten Speicher anzeigen lassen, welche zum Laden der Seite nowtendig waren. Wenn Sie nun einen Durchschnitt aus den Memory-werten bilden, die Ihre Seiten beim laden in Anspruch nehmen, können Sie den Gesamtarbeitsspeichers Ihres Servers durch diesen Durchschnittswert teilen und erhalten dadurch, wie viele parallele Seitenaufrufe Ihr Server verwalten kann. Eventuell müpssen Sie vom Gesamtarbeitssepicher noch den Speicher abziheen, den das serverbetriebssystem an sich braucht. Rufen sie dazu das Kommando top auf und ziehen Sie vom Gesamtspeicher den Speicher von Prozessen ab, die ihnen angezeigt werden. Hat ein prozess unwichtig wenig Memory Load, wird Ihnen nämlich von top automatisch kein wert angezeigt.

erstmal können Sie sich kapazität, Typ und Geschwindigkeit des verbauten Arbeitsspeichers über

dmidecode --typ 17 | more

anzeigen lassen.

Eventuell wollen Sie ermitteln, wie viel Arbeitsspeicher derzeit gerade im System genutzt wird, das geht über

free -m

#oder

cat /proc/meminfo

#oder

vmstat -s

#oder

top

#oder

htop

Wenn wir ausrechnen wollen, wie viele User wir mit diesen Werten gleichzeitig online haben können, müssen wir herausfinden, wie viele Anfragen wir pro Sekunde haben (0,03 wäre beispeilsweise realistisch bei einer statischen Seite, 1 bei einer dynamischen seite mit viel AJAx im Hintergrund). Wenn wir 150 anfragen pro sekunde bewältigen wollen und jeder user pro sekunde eine anfrage stellt, können wir erstmal 150 user online haben. Aber: Dann brauchen wir die durchschnittliche Zeit, die eine einzelne Seite zum Laden braucht (rauszufinden über ein modul wie Profiler). Denn dies ebsetimmt auch die anzahl der user. wenn jede seite durchschnittlich 2 sekunden zum laden braucht, jeder user aber jede sekunde eine neue anfrage stellt, dann bedeutet dass, dass wir pro user teiwleise 2 anfragen parallel laufen haben. Das halbiert wiederum die anzahl der möglichen gleichzeitigen user auf 75. Wenn hinggen jede seite in 0,5 sekunden geladen ist, sind die 150 anfragen, die 150 user gleichzeitig stellen, einfach gesprochen schon in einer halben sekunde fertig, das heißt wir haben noch eine halbe sekunde übrig, in der nichts gemacht wird – das bedeutet im endeffekt, eine geringere laezeit von 0,5 sekunden verdoppelt die mögliche anzahl der gleichzeitigen user. Vorischt: In der Realität verändert isch natürlich die durchschnittliche Ladezeit, je mehr user gleihczeitig eine anfrage stellen. Deswegen sollte man hier nochmal einen puffer von beispielsweise 10% einrechnen.

Die Formel zur berechnung der eingeloggten user ist also

(Anfragen eines einzelnen Users pro sekunde) / <durchschnittliche ladezeit einer seite> * <gleichzeitige anfragen pro sekunde, die wir unterstützen wollen>.

die Geschwindigkeit des Arbeitsspecihers können Sie mit ramspeed auf Betriebssystemebene testen. Deswetieren gibt esn spezielle Live-System wie stresslinux.org oder Memtest.

Traffic

Der Traffic die die Gesamtmenge an Netzwerkverkehr, den Sie innerhalb einer Periode (meistens pro MOnaT) ohne kostenzuschlag haben können. Die meisten Serverangebote glänzen mit „unbegrenztem Traffic“ – die Grenze des maximal möglichen Netzwerkverkehrs ist dann lediglich die weiter oben angesprochene Bandbreite.

Generell können Sie aus Ihrer Bandbreite und den Online-Zeiten Ihrer Besucher den Traffic errechnen. Wenn Sie mit den oben geannnten Methoden Ihren Trafficverbrauch müssen, reduziert sich der Aufwand auf bloße Additionsmethodik.

Theoretisch könnten Sei aber den Traffic ja nicht planen wollen, sondern überprüfen, ob der von IHrem Server-Anbieter ermittelte Traffic der wahrheit entspricht.

testen mit netstat

ein sehr simpler Traffic-test wird durchgeführt, indem man regelmäßig netstat ausführt und damit die gesendeten doer empfangenen Bytes misst. Bei jedem durchlauf von netstat wird der aktuelle stand an übertragenen oder gesendeten Bytes pro entzwerkschnittstelle gemeldet. Denaktuellen Verbrauch kann man dann über einfache Mathematik ermitteln.

Um den input-Traffic/Downstream-Traffic zu ermitteln, gibt man ein

netstat -ib | grep -e "$INTERFACE" -m 1 | awk '{print $7}'

Und für den Output/ Upload-Traffic gibt man ein

netstat -ib | grep -e "$INTERFACE" -m 1 | awk '{print $10}'

mit einem derartigen Skritp könnte man beispielweise eine Prüfung durchführen und bei Überschreiten einer bestimmten Grenze eine Netzwerkschnittstelle herunterfahren, um das Limit nicht zu überschreiten.

#!/bin/bash

set -e # exit if any error occurs



previous_days_bytes_xferred=`cat $flatfile_storage`

todays_bytes_xferred=`netstat -ib | grep -e "$INTERFACE" -m 1 | awk '{print $10}'`



if [ $((todays_bytes_xferred - previous_days_bytes_xferred)) -gt $threshold ]; then

   DO SOME STUFF

fi

echo $todays_bytes_xferred > $flatfile_storage

Messen mit vnstat

eine einfachere Methodik ist das Tool vnstat.

vnStat 1.6 by Teemu Toivola <tst at iki dot fi>



     -q,  --query          query database

     -h,  --hours          show hours

     -d,  --days           show days

     -m,  --months         show months

     -w,  --weeks          show weeks

     -t,  --top10          show top10

     -s,  --short          use short output

     -u,  --update         update database

     -i,  --iface          select interface (default: eth0)

     -?,  --help           short help

     -v,  --version        show version

     -tr, --traffic        calculate traffic

     -l,  --live           show transfer rate in real time





 eth0  /  monthly



   month         rx      |      tx      |   total

-------------------------+--------------+--------------------------------------

  Oct '09     225.70 GB  |   798.52 GB  |     1.00 TB   %%%%:::::::::::::

  Nov '09     138.46 GB  |   616.54 GB  |   755.01 GB   %%::::::::::



 eth0  /  daily



day         rx      |     tx      |  total

------------------------+-------------+----------------------------------------

   31.12.      6.56 GB  |   34.39 GB  |   40.95 GB   %%%::::::::::::::::

   01.01.      1.13 GB  |  746.92 MB  |    1.86 GB

es gibt auch eien webbasierte Lösung von vnstat namens vnstat PHP

messen mit netload

Die schier einfachste Methode der kurzfristigen trafficmessung geht mit netload. Jedoch kaum geeignet für langristige messungen.

sudo apt-get install netdiag

$>netdiag eth0

 

Messen mit MRTG

Sniffing mit tcpdump

zu guter letzt kann es manchmal sinnvoll sein, mit dem Kommando tcpdump den Netzwerkverkehr mitzusnifffen, um eventuell festzustellen, welche Anwendung bzw. welches Protokoll für eine schlechte Netzperforamnce verantwortlich sein könnte.

Bandbreite

Grundsätzlich geht man bie der Ermittlung der Bandbreite davon aus, dass die Geschwindigkeit, in der sich eine minimaleinheit ein Datne bewegt, ist immer dieselbe. Denn der server hat in die Weiten des Internets eine oder mehrere vorherbestimmte Routen, die auf Übertragungsmedien mit einer bestimmten Geschwindigkeit basieren. Was letzendlich beeinflusst, wie schnell und flüssig die kommunikation zwischen SErver und Kunde läuft, ist die Tatsache, wie viele Daten sich durch diese Verbindung in der selben Zeit bewegen können. Wasser läuft schneller durch eine Badewanne mit weiterem Abfluss.Das beschränken auf Serverseite die Anbieter oder Hoster des Servers, damit ein einziger Server nicht die gesamte Leitung für sämtliche anderen Knotenstellen belegen kann. Auf Kundenseite gibt es diese Begrenzung der Bandbreite auch – auf Seiten des Internet Providers. Was wir also ermitteln müssen, ist – wie viel Bandbreite wir brauchen, um eine flüssige Kommunikation zwischen Server und Kunden gewährleisten zu können.

Bandbreite sagt also aus, wie viele Daten gleichzeitig durch unser Netzwerk laufen können. Da man eben davon ausgeht, dass im INternet alle Daten mit der selben Durchschnittsgeschwindigkeit laufen, bestimmt also nicht die Reisegeschwindigkeit der Daten, sondern die Bandbreite der gleichzeitig reisenden Daten, in der Praxis die Übertragungsgeschwindigkeit.

die Standardmesseinheit für Bandbriete ist megabits pro Sekunde.

Bei einfachen Diensten kann man grundsätzlich aus dem Stegreif berechnen, wie viel Bandbreite man benötigt. Wenn Sie beispielsweise einen Webserver hosten, bei welchem ausschließlich statische HTML-Seiten übertragen werden, können Sie den Übertragungsbedarf theoretisch von Hand kalkulieren, indem Sie berechnen, welche größe Ihre Seiten durchschnittlich haben und wie viele Seitenaufrufe Sie pro Tag in etwa haben. Nun haben Sie die Gesamtgröße der zu übertragenden Daten pro Tag. Sie haben wahrscheinlich auch eine STatistik, an wie vielen Stunden pro Tag Sie Besucher haben – nur wenige Seiten haben wirklich 24 Stunden pro Tag Besucher. Meistens beschränkt sich dies auf einen Zeitraum von ca. 9-12 Stunden, wo wirklich hoher Besuchertraffic kommt. Wenn Sie nun die zu übertragenden Gesamtdaten durch die Stunden teilen und Sie sich  die Daten von Megabyte und Stunden umrechnen auf Megabit und Sekunden, haben Sie die benötigte Bandbreite.

Leider ist eine solche berechnung bei komplizierteren Services cshon nicht mehr möglich. Sie können beispielsweise bei einer dynamischen WEbsite nicht mehr so genau berechnen, wie viel Traffic Sie brauchen, da Sie nicht nur die dynamisch erzeugten Seiten an die Kunden schicken, sondern sich beispielsweise auch Programmierbibliotheken aus der Cloud laden, Daten an Google AdSende und Google Analytics überliefern, Sie vielleicht Daten aus einer Datenbank eines fremden Servers benötigen und und und. Noch schwieriger wird es, wenn Sie mehrere Services auf einem einzigen Server komibineren.

Deswegen ist generell die einfachste Lösung zur Kalkulation der Bandbreite, sie zu messen. Das können Sie bereits vor der bestellung eines Servers und von teuren Softwareprodukten vielleicht mit einer Testversion des Dienstes und einer LAN-Serverumgebung machen.

Egal welches Tool Sie verwenden wollen, die grundlegende Vorgehensweise ist Folgende:

• Messen Sie den bandbreitenverbrauch  des Servers bei einer bestimmten Basisusermenge, beispielsweise 10-50 User pro serverdienst.
• Messen Sie den bandbreitenzuwachs für beispielsweise 5-10 User mehr pro Serverdienst. das bedeutet, Sie haben derzeit Traffic von 10-50 Basisusern auf allen Diensten. Dann nehmen sie 10 User auf einem Serverdienst dazu und messen den Bandbreitenzuwachs. Dann nehmen Sie die 10 User von dem deisnt wieder runter und fügen 10 User auf einem anderen Serverdienst hinzu. Messen Sie auch hier den bandbrietenzuwachs. Dabei sollten sie beispielswiese auch nicht vergessen, dass man auf einem einzigen webserver mehrere Websiten hosten kann. In dem Fall sollten Sie den Bandbrietenzuwachs für die einzlenen Websites testen.
• jetzt haben Sie den Basiswert, den Ihr Serverdienst braucht, plus den Bandbreitenzuwachs für 10 zusätzliche User für jeden einzelnen Serverdienst.
• Berechnen Sie jetzt aus Basiswert und Zuwachs die Bandbreite für die zu erwartende Menge Nutzer, die Ihre Dienste gleichzeitig betreuen müssen. Das gleichzeitig ist hier wichtig. Denn Sie können beispielsweise insgesamt 3000 Nutzer haben, Sie können aber vielleicht mit Sicherheit sagen, dass Sie nie mehr als 1000 gleichzeitig eingeloggte Benutzer haben werden.
• zu diesen dynamischen Werten kommen vielleicht noch statische Werte hinzu. Beispiel: sie hosten zusätzlich auf dem Server bestimmte Dateien mit einer festen Größe und rechnen pro Tag mit einer bestimmten Menge downloads. Dei Bandbreite pro Download begrenzen Sie mit Servereinstellungen, so dass Sie hier fest sagen können, wie viel Bandbreite sie pro Download hinzurechnen sollten. Wenn Sie 10 Userdownloads zusätzlich zu ihrem normalen Serverbetrieb stets sicherstellen wollen, dann sollten Sie diese Bandbrieten nun zum normalen Serverbetrieb hinzurechnen.

Wenn Sie diese Rechenschritte sauber für alle Szenarieren, die Sie auf dem Server abbilden wollen, sauber durchführen und die einzelnen Werte aufaddieren, haben Sie den Bandbreiten verbrauch Ihres Servers ermittelt.

Eine berechnete Bandbreite bringt natürlich nur etwas, wenn man durch entsprechende Maßnahmen verhindert, dass ein noch höheres Serveraufkommen zustande kommt und sich noch mehr User gleichzeitig auf dem System befinden. Das müssen Sie durch eine von zwei MÖglichkeiten verhindern: Entweder sie verhindern die weitere Nutzung des Services durhc noch mehr Nutzer mittels interner servereinstellungen oder Netzwerkbeschränkungen (indem Sie beispielsweise die gleichzeitigen Verbindungen auf einem bestimmten Port beschränken), oder Sie kümmern sich um eine Lastausgleichslösung, die einspringt, sobald eine bestimmte Usermenge erreicht ist.

Über die Berechnung der Anforderungen an einen Lastausgleich kümmern wir uns später noch.

maximale Bandbreite messen

Als allererstes interessiert uns als Administrator natürlich, ob die vom Serveranbieter versprochene Bandbreite theoretisch auch wirklcih erreicht werden kann. Wichtig ist, dass Sie vor dem Test alle Services Ihres Systems so weit wie möglich abschalten, da diese das Testergebnis beeinflussen. Jeglicher Netzwerkverkehr, der außerhalb des Bandbreitentesttools läuft,. verschlechtert und verfälscht das Ergebnis.

Grundsätzlich kann man die maximale Bandbreite auch auf einem server mit web-Speed-Test testen, wie ich sie beispielsweise in meinem post Die besten Web-Tools vorstelle. Diese sind jedoch nur annähernd akkurat, da der verwendete Webbrowser im Hintergrund ebenfalls testunabhängigen Bandbreitenverbrauch verursacht. Bekannte Tools zum Bandwidth Perforation Testing sind tools wie Netcps, JDSU GT600, Spirent Test Center, IxChariot, Iperf, Ttcp, netperf oder bwping.

Testen mit wget

Grundsätzlich kann man, wenn man allen weiteren Netzverkehr ausgeschlossen hat, die Bandbreit auch mit wget testen. Dazu bieten viele Content-Delivery-networks (CDN) 10 MB, 100 MB und 1GB-Testfiles zum Download an, um die Download-Geschwindigkeit zu testen. Beispieslweise kann man sich ein Testfile von Softlayer.com herunterladen mit folgendem Befehl

wget -O /dev/null http://speedtest.dal01.softlayer.com/downloads/test100.zip

der Parameter -O leitet dabei die Datei n das nichts, so dass kein Speicherplatz verbraucht wird. Nach dem Downlaod der Datei wird eine Statistik angezeigt, die man zur Analyse nutzen kann.

Aus einem einmaligen Download lässt sich noch kein repräsentativer Wert für die Bandbreite ermitteln. Mit eienr Schleife kann man den wget-Befehl mehrmals ausführen und dann einen durchschnittswert errechnen.

for i in $(seq 20); do wget -O /dev/null "http://speedtest.dal01.softlayer.com/downloads/test100.zip" >>/dev/null; done

Alternativ noch die Varaitne für ein 5GB-Testfile

wget -O /dev/null http://speedtest.qsc.de/5GB.qsc

http://speedtest.qsc.de/5GB.qsc

Testen mit Speedtest-CLI

Das Python-Skritp Speedtest-CLI ist ebenfalls eien relativ einfache Speedtest-Methode. Downloaden kann man das Skript hier.

Auf dem System muss python installiert sein.

ipkg install python py25-crypto py25-curl libcurl py25-openssl py25-django py25-pil tesseract-ocr tesseract-ocr-lang-eng ossp-js

Das Skript kann dann ausgeführt werden

python ./speedtest.py

Bisher haben wir lediglich den Download getestet. Interessant für einen Server ist aber vor allen Dingen die Bandbreite im Upload eines Servers.

Grundsätzlich sind bei Servern Upload und Download synchron, es ist also nicht wie bei ADSL, dass man weniger Upload zur Verfügung gestellt bekommt als Download. Der Download-Wert ist also bereits ein guter Richtwert. Dennoch kann es in der Praxis differenzen zwischen diesen beiden Werten geben, die es ggf. zu ermitteln gilt.

Ein einfacher Test für die Bandbreite wäre, eine Datei auf dem zu testenden Server per FTP von einem Rechner / server mit hoher Download-Bandbreite (höher als die theoretisch angebotene Upload-Bandbreite unseres Testservers) herunterzuladen. Im FTP-Protokoll gibt es zwra Datenoverhead, dieser ist jedoch relativ gering und in der Praxis bei den Nutzern ja ebenfalls vorhanden.

Es gibt auch Web-Upload-Tests die man im Brwoser ausführen kann, so wie ich sie beispielsweise in meinem Post Die besten Web-tools aufzähle.

Bandbreitenverbrauch messen

Neben der maximal möglichen Bandbreite interessiert uns in der Produktivphase des Servers, wie viel Bandbreite zu welchen Tageszeiten im Server gebraucht hat. Die oben genannten Testmöglichkeiten können  wir hierzu nicht verwenden, da diese ja die komplette zur Verfügung stehende Bandbreite ausnutzen würden und uns somit die Leitung zu machen würden. Mit den hier gezeigten Methoden finden wir raus, wie viel von unserer maximalen Bandbreite im Moment gerade genutzt wird, wann auf dem Server unsere Lastzeiten auftreten, ob die angebotene Bandbreite für unsere Nutzer derzeit noch ausreicht, und hilft beim Erkennen von versteckten Bandbreitenfressern, die eventuell Bandbreite von den wirklich wichtigen Services auf dem Server klauen.

bandwidthd

bandwithd trennt den bandbreitenverbrauch nach subnetzen und erstellt HTML Dateien, um die Nutzung anhand von Graphen anzuzeigen. Der Verbrauch lässt sich hierbei über 2, 8, 40 oder 400 tage messen. Außerdem kann sich der verbrauch von verschiedenen IP Adressen des Systems in Intervallen von 3,3 Minuten, 10 Minuten, einer Stunde oder 2 Stunden im cdf-Format messen.

messen mit dstat

$>sudo apt-get install dstat

$>dstat -nt

 

Bmon

bmon ist eine portable alternative für verschiedene betriebssysteme. Ausgabe möglich in HTML und formatierbarem ASCII. das Tool zeigt den netzwerktraffic über alle interfaces im system.

Installation

sudo apt-get install bmon

#oder

sudo yum install bmon

messen über slurm

zeigt die bandbreite im sende und empfangen pro netzwerkschnittstelle in einem ascii-graphen. die verscheidenen ASCII-Graphen können mit den Tasten [C], [S] und [I] umgeschaltet werden.

Installation

sudo apt-get install slurm

#oder

sudo yum install slurm -y

verwendung

slurm -s -i eth0

messen mit tcptrack

zeigt die geschwindigkeit zwiscehn zwei sockets an, untescheidte dabei leider nicht zwischen gesendetr und empfangener bandbreite

Installation über

sudo apt-get install tcptrack

#oder

sudo yum install tcptrack

vnstat

vnstat kann neben dem feststellen des traffics auch für die ermittlung der täglichen durchschnittsbandbreite verwendet werden

vnstat läuft dabei im gegensatz zu den meisten anderen tools hier ständig als daemon im hintergrund.

Installation

sudo apt-get install vnstat

#oder

sudo yum install vnstat

Verwendung

service vnstat status

 * vnstat daemon is running

$> vnstat

ein echtzeitcapture der aktuellen badnbreite für eine bestimmte netzwerkschnittstelle ist möglich über

$> vnstat -l -i eth0

 

Bwbar

kleines C-basiertes Programm für Linux, welches statistiken über die bandbreitennutzung eines netzwerkinterfaces sammelt.

bwm

sehr kleiner bandiwth monitor der bis zu 16 interfaces gleichzeitig messen kann.

messen über Pktstat

zeigt alle aktiven verbindungen in echtzeit und die zugehörige bandbreite an.

Installation

sudo apt-get install pktstat

verwendung

sudo pktstat -i eth0 -nt

messen über netwatch

sudo apt-get install netdiag

sudo netwatch -e eth0 -nt

messen über Trafshow

sudo apt-get install netdiag

sudo trafshow -i eth0 top

 

messen über bwm-ng

hat mit bwm an sich nichts zu tun. Rein konsolenbasiert, reported die empfangene und gesendete Bandbreite pro netzwerkschnittstelle.

Installation

sudo apt-get install bwm-ng

#oder

sudo apt-get install bwm-ng

Verwendung

$>bwm-ng

#oder

$>bwm-ng -o curses2

 

Cacti

cacti ist eine komplette Netzwerkvisualisierungslösung inklusive User management Features. Sehr gut, um komplexe netzwerke mit hunderten Geräten zu messen, für den typischen VServer Nutzer aber etwas zu oversized.

Andere Tools in dem bereich sind beispielsweise cbm, dstat, EtherApe, gdesklets, GKrellM, ipband, iftop, dstat, iperf, ipfm, ifstat, ibmonitor, ipaudit, IPTraf, IFstatus, nettop, Multi Router traffic grapher MTRG, moodss, monitord, Netmrg, nload, ntop, netpseed, Netwatch, NOCOL, NeTraMet, NetPIPE, netperf, potion, nethogs, pktstat, RTG, speedometer, Spong, slurm, SNIPS, tcpflow, tcptrack, vnstat, IPTraf, NetHogs, Monitorix,trafshow, vnstat, speedometer, pktstat und WMND.

messen mit ifstat

sudo apt-get install ifstat

#oder

sudo yum install ifstat

$>ifstat -t -i eth0 0.5

messen mit collectl

sudo apt-get install collectl

#oder

sudo yum install collectl

$>collectl -sn -oT -i0.5

 

messen mit iftop

iftop misst den Datenverkehr der durch einzelne Socket-Verbindungen fließt. dazu nutzt das tool die pcap bibliotheken um pakete aufzufangen die in und aus einem netzwerkadapter fließen. leider werden nicht die prozessnamne angezeigt, die an dem datenfluss an den sockets beteiligt sind.

Installation

yum install iftop -y

#oder

sudo apt-get install iftop

Verwendung:

sudo iftop -n

der APrameter -n verhindert, dass iftop die ip-adressen in hostnamena uflöst – dadurc wird kein zusätzlichert netzwerktraffic erzeugt, der das ergebnsi verfälscht.

messen mit iptraf

iptraf ist ein übersichtliches kommadnozeilentool, welches zwar nicht in ein- und ausgehenden verkehr unterscheidet, aber den netzverkehr zwischen zwei hosts übersichtlch anzeigt

Installation

yum install iptraf

#oder

yum install iptraf-ng -y

#oder

sudo apt-get install iptraf iptraf-ng

Nutzung

sudo iptraf

messen mit nethogs

nethogs zeigt die bandbreite, aufgeteilt in gesendete und empfangene bandbreite, pro process / daemon an. man kann hier also bandbreiten-fresser driekt ausmachen

Installation

sudo apt-get install nethogs

#oder

sudo yum install nethogs -y

Nutzung

sudo nethogs

messen mit cbm – color Bandwidth meter

zeigt sehr übersichtlich die badnbreite dern netzwerkschnittstellen

sudo apt-get install cbm

messen über speedometer

zeigt einen sehr übersichtlichen ascii-graphen für alle netzwerkschnittstellen an

Installation

sudo apt-get install speedometer

Verwendung

speedometer -r eth0 -t eth0

arpwatch

mit arpwatch können Sei die Aktivität des Address Resolution Protocols auf dem System überwachen.

Pagespeed / Loading Times

Neben der Bandbreite ist ein wesentlicher Faktor zur Performance-Bestimmung eines VServers auch der Page Speed (Geschwindigkeit beim Aufbau von Websiten) oder die Ladezeiten für den Aufbau von Nutzerbildschirmen bei Applikationsservern.

Die Ladezeit von Websiten lesst sich grundsätzlich mit Web-Pagespeedtests testen, wie ich sie beispielswiese in meinem Post Die besten Web-Tools verlinkt habe.

Ein berühmter ist etwa http://tools.pingdom.com/fpt/

nload

nload ist ein sehr einfach zu bedienendes kommandozeilentool um den eingehen und ausgehenden traffic derzeitig anzuzeigen.

Installation über

yum nload

#oder

sudo apt-get install nload

Aufruf und Anzeige des traffics einfach über

nload

 

Performance des  aktuellen Servers feststellen und statistisch erfassen

Gesamtperformance benchmarken

Dafür bieten sich Kommandozeilenbenchmarks wie beispielswiese WHT-Unix-Benchmark.

Installation geht meist wie folgt. Zuerst müssen installierte Pakete vorinstalliert werden.

Ein weiteres nützliches Tool in dem Bereich ist nmon.

 

CPU-Performance und CPU-Nutzung

Zunächst einmal sollten Sie mit dem Befehl cat /proc/cpuinfo die grundlegenden Informationen über die CPU abgreifen.

Die CPU-Performance können Sie mit dem Kommandozeilentool htop testen. Meistens dürfte dieser jedoch auf Ihrem VServer nicht vorinstalliert sein. Sie müssen es über einen Paketmanager wie YUM nachinstallieren.

Die aktuelle Belastung der CPU können Sie sich vom Kommando top anzeigen lassen.Hierbei wird die CPU-Belastung für jeden individuellen prozess angezeigt.

Auch das kommando vmstat kann Ihnen Aufschluss über die CPU Usage geben.

Und zu guter letzt gibt es noch das allseits beliebte Kommando top, welches die CPU Usage pro Prozess anzeigt.

will man die CPU benchmarken, kann man sich mit dieser zeilie einen einfachen cpu benchmark basteln

time echo “scale=1000; 4*a(1)” | bc -l

Die Zeile berechnet die zahl Pi auf 1000 Stellen.

Mein aktueller Server läuft sehr unperformant und langsam – was ist da los?

Prüfen sie zunächst einmal anhand der oben genannten Informationen, ob die Leistungsmerkmale Ihres VServers für die von Ihnen verwalteten Diesnte kalkulatorisch ausreichend sind. Wenn Sie dann ausschließen könne, dass Sie einen Fehler gemacht haben, gilt es, festzustellen, ob Ihr Server zurzeit technische Performanceprobleme hat.

Der häufigste grund, warum ein VServer unperformant läuft, wenn kalkulatorische Fehler augseschlsosen sind, sind unzureichend gsetzte Limits. Sie müssen sich das so vorstellen, dass Auf einem großen Server mehrere kleinere virtualisierte Server laufen – einer davon ist Ihre kleine virtuelle Maschine, die Ihnen zugeordnet wurde, als Sie den VServer erworben haben. Damit eine dieser virutellen Maschinen nicht die Performance der anderen zunichte machen kann, werden Limits gesetzt. Diese sind nicht selten zu klein bemessen. Sie können diese Limits mit dem Kommando

cat /proc/user_beancounters

Version: 2.5

 uid resource held maxheld barrier limit failcnt

 2254288: kmemsize 240802897 244121600 9223372036854775807 9223372036854775807 0

 lockedpages 0 0 1572864 1572864 0

 privvmpages 223555 287575 9223372036854775807 9223372036854775807 0

 shmpages 43114 75898 9223372036854775807 9223372036854775807 0

 dummy 0 0 9223372036854775807 9223372036854775807 0

 numproc 497 500 500 500 2246

 physpages 588191 606321 1572864 1572864 0

 vmguarpages 0 0 1572864 1572864 0

 oomguarpages 52904 73481 1572864 1572864 0

 numtcpsock 32 40 500 500 0

 numflock 7 11 9223372036854775807 9223372036854775807 0

 numpty 2 20 9223372036854775807 9223372036854775807 0

 numsiginfo 0 48 9223372036854775807 9223372036854775807 0

 tcpsndbuf 564752 1495744 9223372036854775807 9223372036854775807 0

 tcprcvbuf 524288 655360 9223372036854775807 9223372036854775807 0

 othersockbuf 758336 1148592 9223372036854775807 9223372036854775807 0

 dgramrcvbuf 0 3600 9223372036854775807 9223372036854775807 0

 numothersock 374 470 1000 1000 0

 dcachesize 181945538 182566381 9223372036854775807 9223372036854775807 0

 numfile 8901 9390 9223372036854775807 9223372036854775807 0

 dummy 0 0 9223372036854775807 9223372036854775807 0

 dummy 0 0 9223372036854775807 9223372036854775807 0

 dummy 0 0 9223372036854775807 9223372036854775807 0

wichtig ist hierbei, auf wieviel pages die werte barrier und limit gesetzt sind und was für Werte bei maxheld drinstehen. maxheld bedeutet, wie viel pages der aktuelle Höchstwert des Vservers war. Liegt der maxheld-Wert ziemlich nahe an dne Werten barrier oder limit, ist es angeraten, dieses Limit vom VServer-Anbieter erhöhen zu lassen. Das können Sie im Support beantragen und wird meistens ohne Umstände durchgeführt.

Im oberen Biepsiel sehen wir, dass der maxheld  von numproc bei 500 liegt und daher bereits an das Limit herankommt. weitere Werte, die gerne überlaufen, sind privvmpages  und kmemsize.

Ein weiterer Flaschenhals, der gerne entseht, ist, dass Ihnen vom Serverbetreiber temporär weniger Arbeitsspeicher zugesichert wird, als Ihnen in Ihrem Paket eigentlich zusteht. Das können Sie mit den Kommandos top, htop oder free -m überprüfen.

Ansonsten müssen Sie mit den oben genannten Benchmark- und Messwerkzeugen messen, wo der Flaschenhals in Ihrem System liegt. Liegt es an der CPU-Auslastung, am freien Arbeitsspeicher, an der verfügbaren oder freien Bandbreite?

Temperatur-Monitoring

Neben den ganzen Leistungsdaten interessiert Sie womöglich auch die TEmperaturentwicklung Ihrer Komponenten in Ruhe- und Lastzeiten.

diese können Sie mit dem Tool lm-sensors messen.

die messwerte sind in der Regel auf einem VServer nicht interessant, da Sie ohnehin keinen Zugriff auf die physikalischen Hardwaresensoren Ihres Servers haben. Auf einem Root-Server oder über Server-Housing eingestellten Server, der Ihnen alleine gehört, können diese Daten hingegen nützlich sein.

Interrupts

Die Statistiken über die Interrupts des Systems können Sieb sich anzeigen lassen über

#>cat /etc/interrupts

 

 Richwerte

 

Grundsätzliche Performance-Tipps

 

Datenbanken sind sehr arbeitsspeicherlastig und hängen desweiteren stark von der Zugriffsgeschwindigkeit des speichermediums ab, auf dem sie gepseichert sind.Speichern Sie Datnebanktabellen deshalb wenn möglich auf SSD festplatten oder zumindest auf einer anderen physikalishcen platte als das betriebssystem. Die Zugriffe auf die daten laufen dann performanter. Wichtig: Einige DBMS muss man auf SSD-Fstplatten speziell tunen und dazu spezielle Konfigurationseinstellungen vornehmen. Wenn Sie mySQL nutzen, benutzen Sie die InnoDB ENgine anstelle von MyISAM. Hilft auch das nicht, lagern Sie die Datenbank auf einen anderen Server aus.

Wenn dir dieser Post gefallen hat, teile ihn doch auf Social Media, abonniere und verfolge mich per E-Mail, RSS-Feed, Social Media oder registriere dich auf meiner Seite. Wenn du registriert bist, like den Post bitte, wenn er dir gefallen hat!