Wieviel iowait muss man akzeptieren?

  • Hallo,


    wieviel iowait ist eigentlich normal, bzw. ab wann wäre ein nodewechsel gerechtfertigt und sinnvoll? Ich bin im allgemeinen mit meinem Vserver 1000 ganz zufrieden, aber von Zeit zu Zeit wird der Node durch hohe IO-Last mehr oder weniger außer Gefecht gesetzt.


    [Blocked Image: http://talion.caldron.de/2011/netcup.talion-cpu-day.png]


    Bei den hohen Peaks ist keinerlei Reaktion mehr vorhanden (weder ssh noch http noch sonst irgendwas, auch das Webinterface geht dann oft nicht mehr), und bei den nicht ganz so hohen aber breiteren Peaks reagiert der Server sehr träge. Load bleibt die ganze Zeit im harmlosen Bereich, RAM-Auslastung und andere relevante Werte ebenfalls.


    Bei Bedarf kann ich auch sysstat-Output zur Verfügung stellen.


    Grüße,
    Hannes

  • Ich würde da einfach mal dem Support ne Mail schreiben. Evt. ist ja auch einfach einer der anderen Vs auf deinem Node etwas "ausser kontrolle" und wird verschoben um das gesammtsystem nicht zu bremsen.


    Wir hier im Forum können da kaum helfen :D

  • Bei mir sieht es leider auch manchmal so aus:


    Code
    1. Cpu0 : 16.3%us, 1.3%sy, 0.0%ni, 0.0%id, 80.5%wa, 0.0%hi, 2.0%si, 0.0%st
    2. Cpu1 : 6.5%us, 1.0%sy, 0.0%ni, 0.0%id, 92.2%wa, 0.0%hi, 0.3%si, 0.0%st
    3. Cpu2 : 53.3%us, 0.7%sy, 0.0%ni, 45.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st
    4. Cpu3 : 5.2%us, 4.6%sy, 0.0%ni, 0.0%id, 90.2%wa, 0.0%hi, 0.0%si, 0.0%st
    5. Cpu4 : 36.7%us, 1.6%sy, 0.0%ni, 0.0%id, 61.4%wa, 0.0%hi, 0.3%si, 0.0%st
    6. Cpu5 : 7.1%us, 1.4%sy, 0.0%ni, 0.0%id, 91.5%wa, 0.0%hi, 0.0%si, 0.0%st
    7. Cpu6 : 32.7%us, 1.3%sy, 0.0%ni, 0.0%id, 66.0%wa, 0.0%hi, 0.0%si, 0.0%st
    8. Cpu7 : 4.0%us, 1.3%sy, 0.0%ni, 0.0%id, 94.4%wa, 0.0%hi, 0.3%si, 0.0%st


    Gruß
    Konni

  • Grundsätzlich würde ich mich mal an den Support wenden.


    Ich hatte aber selbst auch schon beobachtet das ein vServer zeitweise überhaupt nicht reagiert.


    Quote

    Wieviel iowait muss man akzeptieren?


    Im prinzip darf der Wert nur so hoch sein das dir deine garantierten und bezahlten Leistungen zur verfügung stehen. So weit ich mich erinnern kann haben alle vServer eine garantierte Leistung und wenn ein vserver aufgrund hoher Nodelast nicht reagiert läuft was falsch. Wie gesagt beobachten und an den Support melden. Auf dauer würde ich es auf alle Fälle nicht akzeptieren.


    Grüße

  • ich hab auch einige probleme mit dem wait,


    ich schiebe es zu 99% auf die hdd..


    auf meinem gameserver waren heute 2 user (!),bei jedem kill der ins logfile geschrieben wird lagt der server 1sek, wait: 60-280%! bei 0 server auslastung


    der support sagte dazu in der 1. mail: es liegt an mir, und an der 2. das ich evtl. mehr hdd resourcen als mir zusteht verbrauch .. soso, ich weis ja nicht was zuviel ist.. aber paar logs ziehen gleich den ganzen server runter?

  • Hallo! Ich habe ähnliche Probleme. Mit etwas Systematik und Engagement kommen wir hier vielleicht weiter. Ich versuchs mal:


    ChaosKrieger;30920 wrote:


    der support sagte dazu in der 1. mail: es liegt an mir, und an der


    Das ist erstmal wahrscheinlich, klar. Wahrscheinlich hast Du nicht geschrieben wieso Du das ausschließt.


    ChaosKrieger;30920 wrote:


    2. das ich evtl. mehr hdd resourcen als mir zusteht verbrauch .. soso, ich weis ja nicht was zuviel ist.. aber paar logs ziehen gleich den ganzen server runter?


    Es erzeugt nicht nur dein Gameserver Logs, sondern noch 30 andere Dienste und das auf jeder virtuellen Maschine. Ob nun genau deine Software den Server runterzieht musst Du selbst prüfen (Suchmaschine anschmeißen). Dann sprichst Du den Support einfach nochmal an.


    Bei mir kommen da folgende Fragen auf:
    1. Sind die HDD-Ressourcen tatsächlich pro Kunde kontigentiert?
    2. Falls ja, wieviel steht einem denn zu?



    Weiter:
    Das Diagramm von Threadsteller ist nicht aussagekräftig. Wieso?
    Es ist zu grob. Es umfasst 24 Stunden. Ein Pixel darauf sind vielleicht 7 Minuten. Ich glaube kaum, dass du so lange Lags hast. Die Lags die Du meinst kann man dort nicht sehen.


    Konni meint wohl das gleiche wie Du. Sein Output ist aber aussagekräftig, allerdings nur für den Moment. Er hat 8 CPUs, von denen nur auf einer gerechnet werden kann. Das ist ein Problem, klar.


    christian hat geschrieben:
    Iowait sollte nur so hoch sein, dass die garantierte Rechenleistung zur Verfügung steht. Das seh ich auch so.
    Trotzdem stell ich die Frage in den Raum (vielleicht mag ja jemand von Netcup was dazu sagen, da das hier häufig nicht klar ist):


    3. Angenommen ich habe 1GHz gebucht. Müssen die dann ständig (99%) zur Verfügung stehen? Oder nur im Mittel?
    4. Ist es zuzumuten, dass diese 1GHz beispielweise auf 4 wechselnden Kernen zur Verfügung steht?


    Neben Antworten auf diese Fragen braucht man folgendes um dazu Aussagen zu treffen:


    • Wieviel iowait verursache ich selbst?
    • Wann und wie oft genau steht mir wegen zu hohem Iowait meine garantierte Rechenleistung nicht zur Verfügung?


    Wenn man das weiß, kann man das mit den SLAs und dem gebuchten VServer abgleichen. Dann weiß man, wie man sich an den Support zu wenden hat.
    Der letzte Punkt erfordert relativ genaue Messungen, wofür es auch kein fertiges Tool gibt das auf den VServern läuft.



    Bei meinem VServer Gold sieht es für mich so aus:

    • iowait Schnitt 24 Stunden CPU7: 14%
    • iowait Schnitt 4 Wochen CPU7: 11%
    • iowait Schnitt 1 Jahr CPU7: 3,9%


    (Hier wird nochmal das Problem vom Diagramm von Threadsteller deutlich)
    Ergebnis einer Messung heute 16 Stunden, angegeben ist: "Wie oft im Schnitt gibt es >>50% iowait für 0,5 Sekunden auf der angegeben Anzahl von CPUs."
    Kein Ergebnis ist Teilmenge eines anderen, also 4 CPUs sind nicht auch bei 8 CPUs mit bei.

    • alle 53 Minuten auf allen 8 CPUs gleichzeitig
    • alle 15 Minuten auf 7 CPUs gleichzeitig
    • alle 5 Minuten auf 6 CPUs gleichzeitig
    • alle 104 Sekunden auf 5 CPUs gleichzeitig
    • alle 44 Sekunden auf 4 CPUs gleichzeitig
    • alle 22 Sekunden auf 3 CPUs gleichzeitig
    • alle 12 Sekunden auf 2 CPUs gleichzeitig
    • alle 6,5 Sekunden auf 1 CPU


    Load ist dabei nahe Null und der iowait wird auch nicht von meinen Prozessen verursacht.
    Ob das einen Dienst stört, hängt nun natürlich auch davon ab, wie mobil er zwischen den Kernen ist. Die Praxis wird da bei jedem von uns unterschiedlich aussehen (mehr oder weniger Lags, auf jeden fall aber Lags).


    Bei mir ist das ist qualitativ seit über einem Jahr so und ich hatte damit bis jetzt kein Problem. Habe aber auch keine Gameserver :) Inzwischen störts mich aber, da man es auch beim Apache merkt.



    Gruß,
    Philipp

  • cosmopol_b;30923 wrote:

    Das Diagramm von Threadsteller ist nicht aussagekräftig. Wieso?
    Es ist zu grob. Es umfasst 24 Stunden. Ein Pixel darauf sind vielleicht 7 Minuten. Ich glaube kaum, dass du so lange Lags hast. Die Lags die Du meinst kann man dort nicht sehen.


    Wie ich dazugeschrieben hab, kann ich auch z.b. sysstat-Output zur Verfügung stellen, da ist das deutlich detaillierter. Davon abgesehen ist der Server tatsächlich bei den Peaks für mehrere Minuten extrem langsam oder zeigt gar keine Reaktion (weder ssh noch web, imap, ftp oder sonst irgendetwas), d.h. die Grafik zeigt genau das was ich meine.
    (Es geht übrigens nicht um einen Gameserver)


    Welche Daten genau gebraucht werden, damit der Support feststellen kann, ob die garantierte Qualität noch gewährleistet wird, sollte der Support vermutlich am besten selbst sagen. Wobei mir nicht bekannt wäre, dass es für iowait irgendeine Garantie gäbe, aber es wird eben auch die garantierte Rechenleistung beeinträchtigt.
    Damit wir vergleichbare Daten haben, wäre es auch sinnvoll, dass du (Philipp) sagst, wie du deine Messung durchgeführt hast. Meine Daten stammen von munin und sar.
    In den letzten Tagen ist es aber wieder deutlich besser geworden, daher habe ich bisher auch nicht weiter nachgehakt.

  • Talion;30930 wrote:


    Welche Daten genau gebraucht werden, damit der Support feststellen kann, ob die garantierte Qualität noch gewährleistet wird, sollte der Support vermutlich am besten selbst sagen.


    Keine Ahnung was der Support braucht. Man sollte nur vorher soviel rausfinden wie möglich, sonst gehts einem wie ChaosKrieger.


    Talion;30930 wrote:


    Damit wir vergleichbare Daten haben, wäre es auch sinnvoll, dass du (Philipp) sagst, wie du deine Messung durchgeführt hast. Meine Daten stammen von munin und sar.


    Meine Daten stammen aus /proc/stat, also die gleichen wie dein sar ausgibt.
    Übrigens sind meine Messungen auch nicht aussagekräftig. Die taugen nur um zu zeigen, dass z.B. ein Prozess, der immer auf der gleichen CPU arbeitet, irgendwann blockiert würde.
    Eigentlich will man ja wissen wie oft die eigenen Prozesse blockiert werden, obwohl man die garantierten Ressourchen nicht nutzt.


    Talion;30930 wrote:


    In den letzten Tagen ist es aber wieder deutlich besser geworden[...]


    Kommen diese iowaits bei Dir auch so krampfartig? Also es wird erst eine CPU mit iowait gefüllt, und dann innerhalb einer Sekunde die restlichen CPUs?
    Und kannst Du mal von so einem langen Lag von dir ne sar-Messung einstellen, wo man sieht was die CPU außer iowait noch so macht?



    Gruß,
    Philipp

  • http://talion.caldron.de/2011/01/sar23
    sar loggt bei mir normalerweise im 3 Minuten Takt, etwas genaueres hab ich für den Tag leider nicht. Auffällig ist aber, dass der 3 Minuten Takt nicht eingehalten wird, sondern von 21:40 uhr auf 21:45 gesprungen wird und dann wieder 21:46 Uhr. Das passt zum Peak in der Munin-Grafik; zu dem Zeitpunkt ging für mehrere Minuten absolut gar nichts mehr, da konnte ich auch keine detaillierten Messungen starten. (Zumal ich damit die Auslastung noch in die Höhe getrieben hätte).


    Wenns wieder vorkommt, bemüh ich mich mal um eine brauchbare Datenbasis.

  • Talion;30933 wrote:

    Auffällig ist aber, dass der 3 Minuten Takt nicht eingehalten wird, sondern von 21:40 uhr auf 21:45 gesprungen wird und dann wieder 21:46 Uhr.


    Die User-Last ist auf deinem Server nochmal ne ganz andere als bei mir (x10).
    Den Sprung sehe ich. Man kann sich denken, dass da irgendwas nicht gut läuft. Wenn Mittelwerte über 3 Minuten so stark variieren, wird dazwischen relativ viel los sein. Aber das kann man nicht sehen, das ist wie gesagt das Problem mit Mittelwerte in einem so großen Intervall. Besser wäre, in dem Intervall zu messen, was man als "Lag" wahrnehmen würde, also z.B. 0,5 Sekunden.
    Die Last wird durch so eine Messung an sich nicht viel verändert.


    Zum Vergleich der User-Load nochmal nen 24h-Diagramm bei mir:
    [Blocked Image: http://188.40.201.249/downloads/graph.png]



    Gruß,
    Philipp

  • Das große Problem bei der Sache ist ja das man auf einem vserver wenige Möglichkeiten hat zuverlässig an Daten zu kommen. Es reicht schon wenn eine Festplatte oder ein Arbeitsspeicher oder ein anderes Hardwareteil nicht mehr 100% in Ordnung ist und schon hängt es.


    Quote

    1. Sind die HDD-Ressourcen tatsächlich pro Kunde kontigentiert?
    2. Falls ja, wieviel steht einem denn zu?
    3. Angenommen ich habe 1GHz gebucht. Müssen die dann ständig (99%) zur Verfügung stehen? Oder nur im Mittel?
    4. Ist es zuzumuten, dass diese 1GHz beispielweise auf 4 wechselnden Kernen zur Verfügung steht?


    Zu 1. Es wäre zumindest logisch wenn jeder ein garantiertes Kontingent hat. Alles andere wäre fahrlässig ;) , leider geht es nicht aus der Produktbeschreibung hervor.


    Zu 2. Das kann nur Netcup beantworten


    Zu 3. Im Angebot steht z.B "Prozessorgarantie: 1000 MHz" also wird gerantiert das mir diese 1000 MHz jederzeit uneingeschränkt zur verfügung stehen. Zumindest sehe ich keine Sterne oder andere ausheblungen der Aussage.


    Zu 4. Das ist nun eine Frage die wieder nur Netcup beantworten kann, weder aus der Produktbeschreibung noch aus den AGB geht das hervor. Obwohl es ein sehr wichtiger Punkt ist. 1 Ghz auf einer CPU oder 1 GHz aug 8 Cpu's verteilt macht unter umständen schon einen großen unterschied.


    Aber wir können hier Messen und vermuten wie wir wollen so lange Netcup sich nicht an dem Thread beteiligt kommen wir nicht weiter.


    Grüße