V-Server performance bei Server4You / hohe iowait Werte

xctrails

New Member
Hallo allerseits,

ich habe seit einigen Tagen massive Performance-Einbrüche auf einem V-Server bei Server4You, bis hin zu Nichterreichbarkeiten > 1 Stunde. Beim Support speist man mich bisher mit Standard-Antworten ab, à la "normal bei einem V-Server", Wochenends-Spitzen (war auch unter der Woche) ect. Klar, die wollen mir einen dedizierten Server verkaufen.

M.e. läuft auf dem Host seit ein paar Tagen ein Container der sich (bewusst oder unbewusst) nicht an die vom Server4You so bezeichneten "Fair-Use" Praktiken hält. Fakt ist, dass ich laut sar -p über längere Zeiträume iowaits > 10% beobachten kann, währenddessen ist auf meinem V-Server ein Normalbetrieb fast unmöglich (man hat mir praktisch bestätigt, dass mein Server nicht die Ursache ist).

Wie sind Eure Erfahrungen an der Stelle? Und ist es tatsächlich so, dass ein ISP über entsprechendes Virtuozzo Management/Monitoring aus dem "Ruder laufende" Container nicht schneller und effektiver ausbremsen kann?

Aktuell denke ich darüber nach einen Root-Server bei Serverdiscount zu testen - aber der Umzug ist halt mit Aufwand Verbunden und für eine Hobbyprojekt kann ich nur bedingt Zeit und Geld aufwenden.

Danke,
xctrails
 
Das geht bei Containervirtualisierung durchaus auch. So oder so sollte der Provider eingreifen, wenn ein stabiler Betrieb des Hostsystems bzw. anderer Kunden nicht mehr möglich ist; m.E. muss er das sogar. Wir sind auch sehr sparsam mit harten Limits, monitoren aber eben 24/7 alle möglichen Parameter und greifen im Bedarfsfall sehr schnell ein.
 
Und ist es tatsächlich so, dass ein ISP über entsprechendes Virtuozzo Management/Monitoring aus dem "Ruder laufende" Container nicht schneller und effektiver ausbremsen kann?

Wenn die Systeme von einer vernünftig konfigurierten Monitoring-Umgebung überwacht werden, sollten solche "Amokläufer" normalerweise sehr schnell auffallen.

Aktuell denke ich darüber nach einen Root-Server bei Serverdiscount zu testen - aber der Umzug ist halt mit Aufwand Verbunden und für eine Hobbyprojekt kann ich nur bedingt Zeit und Geld aufwenden.

An dieser Stelle solltest du mal grundsätzlich über dein Projekt und dessen Erfordernisse nachdenken.
1. Brauchst du wirklich einen eigenen Server?
Oft reicht ein gut bemessenes Webspacepaket völlig aus. Positiver Nebeneffekt dabei...du brauchst dich nicht mehr um die Serveradministration kümmern, denn das ist Aufgabe des Hosters und du kannst dich voll und ganz auf dein Projekt konzentrieren. Das spart in der Regel viel Zeit und ist unterm Strich auch meist billiger als ein eigener Server.
2. Wenn ein eigener Server, soll es wirklich ein dedizierter Server sein?
Bei den dedizierten Servern im unteren Preissegment ist die Hardwareausstattung meist nicht so umwerfend, oft sind auch nur einzelne Platten verbaut, was bei einem Plattenausfall ein komplettes Neuaufsetzen erfordert. Bei einem vServer (von einem guten Anbieter) kannst du in der Regel davon ausgehen, daß die Hostsysteme mit hochwertiger Hardware bestückt sind und Ausfälle oder andere Hardwareprobleme eher die Ausnahme sind. Weiterer Vorteil ist die Skalierbarkeit. Brauchst du irgendwann mehr Ressourcen, ist dies bei einem vServer meist ohne Probleme machbar, auf ein größeres Paket upzugraden. Fährt dein dedizierter Server am Limit, mußt du dir einen neuen größeren Server anmieten und wieder komplett neu einrichten und die Userdaten umziehen.

Was die Wahl des Anbieters angeht, setze ich persönlich lieber auf kleinere Anbieter als auf die Massenhoster. Die sind zwar meist ein paar wenige Euro teurer, allerdings stimmt da auch der Service und kleinere Anbieter sind auch in der Regel viel flexibler, was spezielle Kundenwünsche angeht.
Aus eigener Erfahrung könnte ich hier PHP-Friends und IP-Projects empfehlen. Aber auch über Netcup habe ich schon viel Gutes gehört. Alle genannten Anbieter sind übrigens auch hier im Forum aktiv, du kannst also gern mal die Forensuche bemühen und dir selber ein Bild von ihnen machen.

Edit:
Tim von PHP-Friends hat unwissentlich meine Empfehlung gestützt :D
Während ich meinen Post geschrieben habe, hat er schon seine fachkundige Meinung kundgetan. ;)
 
Last edited by a moderator:
Wenn die Systeme von einer vernünftig konfigurierten Monitoring-Umgebung überwacht werden, sollten solche "Amokläufer" normalerweise sehr schnell auffallen.
das würde ich eigentlich auch erwarten, findet aber scheinbar nicht (oder manuell? und damit zu spät) statt.
An dieser Stelle solltest du mal grundsätzlich über dein Projekt und dessen Erfordernisse nachdenken.
1. Brauchst du wirklich einen eigenen Server?
Selbstgeschriebene J2EE Software für die ich einen Tomcat o.ä. bauche, vollen shell Zugriff um Openstreetmap-Daten aufzubereiten, mehrere Postgres Datenbanken, etc. kann mir nur schwer vorstellen, das auf einem Webspace Host der für Standard-Anwendungen ausgelegt ist zu machen. Zum Thema Skalierung: Im Zweifelsfalls skaliert der Geldbeutel nicht mit ;) bzw. ab einem bestimmten Kostenaufwand hab ich keine Lust mehr Dienste die andere gerne umsonst verwenden aus der eigenen Tasche zu finanzieren (aber das ist ein anderes Thema ;))
2. Wenn ein eigener Server, soll es wirklich ein dedizierter Server sein?
Bei den dedizierten Servern im unteren Preissegment ist die Hardwareausstattung meist nicht so umwerfend, oft sind auch nur einzelne Platten verbaut, was bei einem Plattenausfall ein komplettes Neuaufsetzen erfordert. Bei einem vServer (von einem guten Anbieter) kannst du in der Regel davon ausgehen, daß die Hostsysteme mit hochwertiger Hardware bestückt sind und
wie gesagt, war mit dem Hobby-Server 3 Jahre bei Strato ohne größere Probleme, bin dann aus Kostengründen zu server4you weil ich dort mit einem dedizierten Server für die Arbeit eigentlich keine schlechten Erfahrungen gemacht hatte.

Aus eigener Erfahrung könnte ich hier PHP-Friends und IP-Projects empfehlen. Aber auch über Netcup habe ich schon viel Gutes gehört. Alle genannten Anbieter sind übrigens auch hier im Forum aktiv, du kannst also gern mal die Forensuche bemühen und dir selber ein Bild von ihnen machen.
ok, danke, werd ich mir mal ansehen.
 
Aber nochmal konkret: Hier die sar -p Werte der letzte Nacht, ab ca. 7 Uhr war der Server praktisch unerreichbar. Mir fehlen Erfahrungswerte an der Stelle, ist das normal/akzeptabel bei iowaits > 10% ? Hätte der ISP hier (automatisiert?) eingreifen können/müssen? Der um ~ 9 Uhr angestossene Reboot dauerte dann bis um 10:40 :eek:

Code:
12:00:01 AM CPU %user %nice %system %iowait %steal %idle
02:05:02 AM all 0.00 0.46 0.12 0.08 0.00 99.34
02:15:18 AM all 0.00 0.82 0.19 6.77 0.00 92.22
02:25:12 AM all 0.00 0.72 0.18 12.41 0.00 86.69
02:35:03 AM all 0.00 4.34 0.26 8.25 0.00 87.15
02:45:05 AM all 0.00 0.52 0.15 4.58 0.00 94.75
02:55:02 AM all 0.00 0.41 0.10 0.96 0.00 98.54
03:05:02 AM all 0.00 0.45 0.11 1.71 0.00 97.72
03:15:02 AM all 0.00 0.67 0.10 3.24 0.00 95.99
03:25:01 AM all 0.00 0.39 0.10 2.79 0.00 96.71
03:35:03 AM all 0.00 0.96 0.18 3.71 0.00 95.15
03:45:03 AM all 0.00 0.58 0.15 6.41 0.00 92.86
03:55:04 AM all 0.00 0.42 0.11 4.10 0.00 95.38
04:05:02 AM all 0.00 0.42 0.11 3.57 0.00 95.90
04:15:03 AM all 0.00 0.63 0.15 8.41 0.00 90.81
04:25:03 AM all 0.00 0.72 0.16 11.09 0.00 88.03
04:35:05 AM all 0.00 0.55 0.12 4.49 0.00 94.85
04:45:03 AM all 0.00 0.22 0.08 2.73 0.00 96.97
04:55:03 AM all 0.00 0.23 0.10 1.58 0.00 98.10
05:05:06 AM all 0.00 0.74 0.28 4.01 0.00 94.96
05:15:03 AM all 0.00 1.31 0.24 2.01 0.00 96.43
05:25:06 AM all 0.00 0.48 0.23 3.05 0.00 96.25
05:35:13 AM all 0.00 0.29 0.07 5.47 0.00 94.16
05:45:03 AM all 0.00 0.24 0.11 11.53 0.00 88.12
05:55:01 AM all 0.00 0.33 0.18 18.69 0.00 80.81
06:05:06 AM all 0.00 4.64 0.25 19.18 0.00 75.94
06:15:01 AM all 0.00 0.17 0.12 6.05 0.00 93.67
06:25:01 AM all 0.00 0.18 0.09 4.48 0.00 95.24
06:35:04 AM all 0.00 0.19 0.06 8.30 0.00 91.45
06:45:03 AM all 0.00 0.23 0.06 18.10 0.00 81.61
06:55:05 AM all 0.00 0.25 0.12 10.78 0.00 88.85
07:05:08 AM all 0.00 0.42 0.22 15.93 0.00 83.43
07:15:15 AM all 0.00 2.67 0.12 10.35 0.00 86.86
07:25:10 AM all 0.00 1.51 0.22 15.17 0.00 83.10
07:35:03 AM all 0.00 11.65 0.48 17.30 0.00 70.56
07:45:08 AM all 0.00 0.60 0.18 8.07 0.00 91.15
07:55:07 AM all 0.00 2.33 0.07 5.17 0.00 92.44
08:05:02 AM all 0.00 0.41 0.07 6.23 0.00 93.28
08:15:08 AM all 0.00 0.70 0.13 9.15 0.00 90.03
08:25:11 AM all 0.00 0.26 0.25 11.69 0.00 87.79
08:35:06 AM all 0.00 1.20 0.13 10.82 0.00 87.85
08:45:05 AM all 0.00 0.14 0.06 5.17 0.00 94.63
08:55:04 AM all 0.00 0.22 0.13 8.28 0.00 91.37
09:05:05 AM all 0.00 0.20 0.07 5.09 0.00 94.64
09:15:04 AM all 0.00 0.75 0.05 7.39 0.00 91.81

09:15:04 AM CPU %user %nice %system %iowait %steal %idle
09:25:03 AM all 0.00 0.12 0.10 5.45 0.00 94.33
09:35:06 AM all 0.00 0.50 0.17 11.31 0.00 88.03
Average: all 0.00 0.89 0.14 6.10 0.00 92.87

10:40:02 AM LINUX RESTART

10:45:02 AM CPU %user %nice %system %iowait %steal %idle
10:55:04 AM all 0.00 0.53 0.08 4.34 0.00 95.05
11:05:05 AM all 0.00 0.15 0.06 0.76 0.00 99.02
11:15:03 AM all 0.00 0.12 0.06 0.40 0.00 99.42
11:25:04 AM all 0.00 0.11 0.05 0.35 0.00 99.49

in den beancounters fiel mir lediglich das hier auf:

Code:
       uid  resource                     held              maxheld              barrier                limit              failcnt
            tcprcvbuf                 2339304              4953056              4942675              7056211                 7642
            othersockbuf               231200              1413936              1647558              3056582                  365

und jede Menge CLOSE_WAIT connections von uptime robot (mit dem ich neben monit/monitorix den Server überwache)
 
@xctrails
Ohne die technischen Daten zum Server zu kennen würde ich jetzt nach deinem SAR-Auszug eher mal darauf tippen, dass aufgrund deiner Java-Anwendung (eventuell ein eigener WMS-Server) und den darauf laufenden Datenbanken der Server eventuell unterdimensioniert sein wird. Von daher nehme ich eher mal an, dass nicht dein Provider oder die Nachbarn das Problem sind.

Um dein Problem besser eingrenzen zu können, wäre es gut, wenn du uns hier auch mal die technischen Daten und einen aktueller Auszug vom load average mitteilen würdest.
 
Von daher nehme ich eher mal an, dass nicht dein Provider oder die Nachbarn das Problem sind.
Naja, der hat mir bereits bestätigt, dass ein anderer V-Server die Ursache war/ist. Außerdem läuft mein Software-Stack eigentlich seit Monaten relativ konstant ohne größere Probleme und ohne selbst hohe I/O Lasten zu erzeugen. Die massiven Probleme treten erst seit ein paar Tagen auf (ohne Software-Änderung auf meiner Seite).

Ich glaube also eigentlich nicht, dass der Server unterdimensioniert ist. Einige Datenbank-Zugriffe habe ich zudem kürzlich auf vor-generiertes statisches Json umgestellt und eine andere Quelle möglicher hoher Parallel Zugriffe durch eine UI Änderung im Frontend signifikant reduziert.

Hier mal der load average der letzten 24h:
MOD: Bilder bitte immer als Anhang. Danke.

Mein Verständnis ist, dass ein hoher Load average auch dadurch zustande kommen kann, dass lange/zu lange auf I/O gewartet wird, hier die Annahme, dass der I/O von einem anderen V-Server auf dem gleichen Host hervorgerufen wird der mich wiederum blockiert. Aus dem Monitorix Protokoll kann ich jedenfalls nichts erkennen was auf einen Einbruchsversuch etc. hindeuten würde der ab 2 Uhr Nachts diese I/O Last auf meinem Server erklären würde.

Mit iotop beobachtet Datenbankzugriffe während derartig hoher iowait Phasen dauern dann ewig, verursachen aber für sich relativ geringe CPU Last (anders als bei Datenbank-Batch Updates bei denen im Normalbetrieb die CPU schon signifikant hochgeht, der iowait sich aber in Grenzen hält).

WMS Server habe ich keinen laufen. (-> https://www.xctrails.org)
 

Attachments

  • 2016_10_23_215307.png
    2016_10_23_215307.png
    16 KB · Views: 124
Last edited by a moderator:
Und hier noch der I/O wait Graph:
 

Attachments

  • 2016_10_23_220807.png
    2016_10_23_220807.png
    15 KB · Views: 111
Last edited by a moderator:
Aus meiner Sicht wird man dir ohne die technischen Daten zum Server trotz der hier aufgezeigten Logs nicht wirklich weiterhelfen können.
 
ok ;) 4 vCores alles andere aus top und lscpu, fehlt noch was?

Code:
top - 08:40:27 up 22:05,  1 user,  load average: 0.07, 0.04, 0.00
Tasks:  57 total,   1 running,  56 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.1 sy,  0.1 ni, 99.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  12582912 total,  2431264 used, 10151648 free,        0 buffers
KiB Swap:        0 total,        0 used,        0 free.  1098172 cached Mem

Code:
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 26
Stepping:              5
CPU MHz:               2266.766
BogoMIPS:              4532.68
Virtualization:        VT-x
 
Inzwischen hat man auf dem Hostsystem einen Festplattendefekt festgestellt, außerdem sei die iowait Rate auf Grund laufender Backups erhöht gewesen :eek: (ich fahre meine eigenen Backups mit Crashplan bzw. BackupPC, das zieht die iowaits auch nicht hoch?!) sehr merkwürdig das alles...
 
@xctrails
Ich habe mir mal deine Logs und die technischen Daten zur VM angeschaut und sehe es an Hand der Daten wie folgt:

Laut deinem lscp Auszug besitzt deine VM 16 vCores und nicht 4.
Da deine Aufzeichnung des Load Average bis maximal 10 ging und dies nur sehr kurzfristig, aber deine VM 16 vCores hat, liegt die Last noch aus meiner Sicht im grünen Bereich.

Laut deiner TOP-Ausgabe wird dein RAM gerade mal bis zu einem Fünftel genutzt. Liegt damit also auch noch im grünen Bereich.

Zwar hat man in der Zwischenzeit einen Festplattendefekt festgestellt, aber dennoch würde ich aufgrund der IO-Wait-Aufzeichnung eher vermuten, dass hier auch im Normalbetrieb die Festplatte/SSD und/oder der RAM der Flaschenhals sein könnten, weil eventuell zu viele Kunden auf die gleiche Festplatte oder im gleichen RAM schreiben. Hier würde ich an deiner Stelle mal mit Hilfe des DD-Befehls, sobald die defekte Festplatte getauscht wurde, die Schreibgeschwindigkeit der Festplatte mit einer Dateigröße von mindestens 10GB und die Schreibgeschwindigkeit des RAM´s mit einer Dateigröße von mindestens 1GB testen.

Die Schreibgeschwindigkeit des RAM´s liegt gewöhnlich je nach Ausführung des RAM´s im Idealfall so zwischen 3 und 5 GB/s. Bei Festplatten oder SSD eher weit darunter.

Hoffen wir aber mal, dass es tatsächlich nur an dem Festplattendefekt lag und die VM danach wie in alten Zeiten wieder rennt.
 
Ganz allgemein aus Hostersicht. Das Problem was auch wir momentan haben ist, dass gerade neue Software Debian 8, Apache 2.4, ... etwas RAM benötigen als das früher der Fall war. 512 MB RAM sind hier nicht mehr viel und wir haben teilweise noch virtuelle Maschinen mit 256 GB RAM. S4U vermietet neue vServer mit 4 GB RAM, werden aber sicher noch eine Vielzahl an Altlasten haben so wie wir. Wenn also auf einem Host mit sagen wir einmal 100 vServern 30 vServer Ihr OS von Debian 7 auf Debian 8 aktualisieren, einige Anpassungen vornehmen, MySQL 5.3 auf 5.7 Updaten, ... Dann noch Nachts Backups davon erstellt werden, kann es mit dem RAM schon einmal knapp werden und dann passiert es, dass die VMs in den SWAP laufen. Man kann sich vorstellen, wie sich die I/O entwickelt wenn einmal 30 VMs auf einem Host in den SWAP laufen, I/O Limits hin oder her. Dann laufen noch VM Backups und der Host verhält sich in der Sache so wie beschrieben. Gerade wenn noch HDDs eingesetzt werden die eine max IOPS von 140 bei Enterprise HDDs aufweisen.

Uns betrifft dieses Problem momentan auch, wir haben aber schon neue Hosts im Testlauf mit anderen Storage Konzepten und neue vServer Angebote sind auch ausgearbeitet. Man muss hier also auch bei Altlasten reagieren um diese Problematik in den Griff zu bekommen. Unser neues Konzept sieht u.a. vor für SWAP Partitionen eigene Arrays zu verwenden, damit dieser nicht die Performance des Gesamtarrays lahmlegen können.

Für dich würde ich aber einmal empfehlen bei S4U zu fragen, ob diese deine VM nicht auf einen anderen Host legen können, der nicht so viele VMs aufweist.
 
Back
Top