vServer drehen (dreht) durch!

  • Warum glaubt mir denn niemand? :(
    Es sind definitiv Cronjobs (ob nun vom System-Sheduler oder aus Applikationen heraus).
    Und höchstwahrscheinlich nicht (nur) die eigenen.

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Zitat von Patschi;24762

    Wie kann ich das aufrufen?
    Die Logs und so...


    ähm ja? Die Frage ist so allgemein wie "welches Rezept soll ich benutzen zum Backen"? In diesem Thread wurden verschiedene Logging-Lösungen vorgestellt, jede loggt auf ihre eigene Art. Niemand (außer dir) weiß, wie du bei dir loggst und wie man diese Log-Files anschaut.


    Zitat von Artimis;24763

    Warum glaubt mir denn niemand? :(
    Es sind definitiv Cronjobs (ob nun vom System-Sheduler oder aus Applikationen heraus).
    Und höchstwahrscheinlich nicht (nur) die eigenen.


    Zitat von [netcup] Felix;24547

    Wenn Sie ausschließen können das kein Fehler auf Ihrem System selber vorliegt, können wir gerne testhalber Ihren vServer auf einen anderen Node verschieben. Dieses muss uns aber glaubhaft dargelegt werden.


    sowie


    Zitat von [netcup] Felix;24598

    Wenn es ganz schlimm mit dem IO-Wait ist (dieses bitte nachweisen), ziehen wir einen vServer auch gerne kostenlos auf einen anderen Node um. Uns muss aber verständlich gemacht werden, dass man als Kunde weiß wo die Probleme liegen und das Probleme seitens des Kunden (leider liegen die im Schnitt bei diesem), ausgeschlossen werden können.


    Das kann doch nur bedeuten: konkret mitloggen - Und zwar nicht in bunten Bildchen, wo ältere Daten mit Verlust komprimiert werden. Diese Ältere Rohdaten müssen noch zugänglich sein. Daher sind die Mehrzahl der vorgeschlagenen Monitoringlösungen nicht für solche Probleme geeignet, sondern höchstens als Resourcenfresser bzw. Gimmick geeinget.


    => Guckt wann die eigenen Cronjobs laufen und dann einfach mal spaßeshalber mitloggen was um den entsprechenden Zeiten im System passiert. Irgendwelche lustig-komisch-bunten Lösungen halte ich dafür eher ungeeignet (siehe meine Erfahrung mit Zabbix).

    "Security is like an onion - the more you dig in the more you want to cry"

  • Naja, Zabbix ist da nicht das bunte-Bildchen-Teil, wie man denkt. Es loggt in eine mySQL-DB und generiert diese Bilder ausschließlich dynamisch aus den auch gerne Jahre alten Daten.
    Allerdings habe ich Zabbix auf deinen Hinweis erst einmal deaktiviert. Mal sehen, ob ich Verbesserungen spüre.


    Aber davon ab: Ich habe bereits die IO-Waits und Loads der letzten Monate vorgelegt. Das beweist aber nicht, dass ich sie nicht selbst produziere.
    Meine Versicherung, in den Lagzeiträumen bewusst keine eigenen Jobs laufen zu lassen, sodass ich immer dann, wenn es lagt am wenigsten Last selber verursache, scheint nicht zu interessieren.


    Denn ich habe es ja schon mehrfach betont: Meine Cronjobs laufen ausschließlich außerhalb der Lag-Zeiträume. Während es i.d.R. zu einer runden 5min-Zahl lagt, schreibe ich in meine Crons z.B. "2-57/5" statt "*/5", um nicht auch noch in die Kerbe zu hauen, ganz blöde bin ich ja nicht ;)

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Artimis, ich habe dich stellvertretend für alle Anderen angesprochen, weil du klar schreibst und nicht irgendwelche nebligen Aussagen machst. Ich weiß, dass du viel Erfahrung mit Linux hast. Sorry wenn das nicht klar geworden ist. ice-breaker und ein paar Andere ebenso, auch wenn ich sie nicht zitiert habe :)


    Zitat von Artimis;24767

    Das beweist aber nicht, dass ich sie nicht selbst produziere.


    So was kann nur netcup selbst nachschauen. Dein Weg mit den konkreten Logs ist ider richtige Weg.


    Ich dachte bisher, echte Lags würden nur durch die hier oft erwähnten Amokläufer-Prozesse entstehen. Ich dachte nicht, dass die üblichen Cronjob-Zeiten so massiv den I/O-Wait beeinflußen würden.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Aber 3 Kerne auf 100% ist doch nicht normal :D


    Habe gerade einen TeamSpeak 2 Server dazuerstellt, danach hab ich gemerkt das das Interface laggt... Hab zur Sicherheit TeamSpeak 2 mal abgedreht.
    Trotzdem sind noch 3 Kerne auf 100%...


    Und sonst hab ich gerade keine Programme dazugestartet/installiert...


    Irgendein anderer vServer dreht grad durch :D

  • Patschi, zum X. Mal: Die Auslastung der Kerne ist komplett irrelevant, wenn irgendein anderer Kunde mal einen vollen Kern nutzt ist das kein Problem. Du lenkst aber mit diesen Posts jedesmal alles wieder auf deine irrelevanten Kerne und suggerierst damit in diesem Thema eine vollkommen falsche Problemursache. Denn andere die reale mögliche Ursachen werden wegen sowas weniger wahrgenommen.

  • Auch ich habe schon bemerkt, dass der vServer immer wieder mal lagt. Ich hatte aber weder Lust noch Zeit, da Ursachenforschung zu betreiben, und fand mich bisher damit ab: "mehr kann man von einem billigen vServer nicht erwarten".


    Nun habe ich hier etwas mitgelesen und gebe nun auch meinen Kommentar:


    - von den Messungen her, tritt der Effekt in bestimmten Intervallen auf.
    - logrotate wird es nicht sein: Eine Datei umzubennen macht keine Load.


    Meine Vermutung:


    Eines (oder alle?) dieser schönen Überwachungstools, die auf einem (mehreren/allen?) vServer läuft, fragt regelmäßig etwas ab, was dann den Lag verursacht.


    Der Hauptkandidat ist dabei etwas in /proc.


    Lustig und traurig zugleich wäre es, wenn das Problem z.B. durch


    Code
    [B]cat /proc/loadavg[/B]


    verursacht würde...


    ... ist nur mal laut gedacht.


    Bebbo

  • Zitat von killerbees19;24388

    Einen vServer kann man jetzt aber schlecht mit einem starkem EQ-4 vergleichen :o
    MfG Christian


    Hi Christian, das ist mir vollkommen klar. ;) Ich setze auf dem vServer natürlich nicht die selben Maßstäbe an wie auf dem EQ-4 und belaste den vServer natürlich auch nicht so stark. Trotzdem sollte der 1000er von den Leistungsdaten her locker die von mir installierte Software "Wuppen" - und das tut er ja auch, bis auf die jetzt sporadisch aufgetretenen Verbindungsausfälle.


    Wie dem auch sei- ich kann berichten das auf meinem vServer die "Lags" seit etwa 3 Tagen nicht mehr auftreten. An der Konfiguration des Servers wurde übrigens nichts verändert, die Nutzung ist gleichbleibend und er wurde auch nicht neu gestartet o.Ä.


    Trotzdessen finde ich es sehr Schade wie netcup mit dem Problem umgegangen ist. Natürlich ist die Supportleistung hier im Forum "freiwillig" da es ein Kunde <-> Kunde-Forum ist und die Kunden sind für die Konfiguration und die Stabilität der auf ihrem vServer eingesetzten Software selbst verantwortlich und es gibt sicher auch einige Leute unter den Kunden die aufgrund ihres Wissens über Server eigendlich lieber ein Webspacepaket nutzen sollten anstatt einen vServer zu betreiben.


    Aber generell die Probleme erst einmal auf die Kunden abzuwälzen ist auch keine Methode. Ich beispielsweise habe natürlich vorher alle mir bekannten Faktoren geprüft auf die ich Einfluss nehmen kann bevor ich mich hier gemeldet habe. Ich habe auch absichtlich zunächst nicht den Ticketsupport bemüht sondern erst den Weg hier ins Forum genommen.


    Für mich steht eines fest: Sobald es die Finanzen wieder zulassen werde ich erneut einen EQ-4 bei Hetzner mieten und nicht wie geplant den vServer "aufstocken". Schade um das Geld für Domains, NS, etc. die ich dann vermutlich doppelt bezahlen muss und schade um die Einrichtungsgebühr die erneut anfällt. Und schade um die Zeit die ich mit der Servereinrichtung verbringen muss.


    Aber bei netcup bin ich nicht zufrieden, es tut mir wirklich leid. Vielleicht stelle ich aber auch zu hohe Ansprüche, ich weiß es nicht.

  • Vielen Dank für Ihr Feedback!


    Wir versuchen da Support zu geben, wo es uns möglich ist. Was aber sollen wir machen, wenn Kunden schreiben "mein vServer laggt, bitte behebt das Problem"? Hier können wir nur um weitere Fakten bitten. Leider bleiben diese viel zu oft aus.


    Fehler können nie ausgeschlossen werden. Fehler können aufgrund von Millionen verschiedenen Ursachen entstehen, sowohl auf der Seite des Kunden wie auch auf unserer Seite oder weil es einfach ein vServer ist, der besonders was die Festplattenzugriffszeiten angeht, nicht mit einem dediziertem Server mithalten kann.


    Um die Ursache für einen Fehler finden zu können, ist es wichtig strukturiert an die Aufgabe heran zu gehen. Dieses fängt mit einer Analyse der Ressourcenauslastung an, geht über eine Logfileanalyse (für Lags sind z.B. gecrashte InnoDB-Tabellen eine häufige Ursache) und kann dann gerne bei einer Anfrage beim Support enden.


    Wer nicht bereit ist sich mit seinem eigenem System auseinander zu setzen, dem können wir gerne ein Management inkl. Confixx für 25 Euro (inkl. MwSt.) Aufpreis zu jedem unserer vServer Angebote optional anbieten. Hier stellen wir dann nicht nur die Funktionalität des Wirtssystems sicher, sondern auch die des vServers. Wir bringen hierzu jahrelange Erfahrung mit und ein ausgereiftes Monitoring-System (auf den vServern die wir managen, können wir übrigens die mysteriösen Lags nicht feststellen, genau so wie das viele andere Kunden nicht nachvollziehen können).

  • Zitat von bebbo;24813

    - logrotate wird es nicht sein: Eine Datei umzubennen macht keine Load.


    logrotate macht bei den meisten Systemen mehr, als nur eine Datei umzubenennen :rolleyes:



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Zitat von bebbo;24813

    Auch ich habe schon bemerkt, dass der vServer immer wieder mal lagt. Ich hatte aber weder Lust noch Zeit, da Ursachenforschung zu betreiben, und fand mich bisher damit ab: "mehr kann man von einem billigen vServer nicht erwarten".


    Nun habe ich hier etwas mitgelesen und gebe nun auch meinen Kommentar:


    - von den Messungen her, tritt der Effekt in bestimmten Intervallen auf.


    Wobei zu 97% klar ist, wieso zu den Zeitpunkten I/O-Last auftritt. Es sind cronjob. Und zwar vor allem unnötige Cronjobs, denn niemand wird aller 10min in Confixx, syscp, etc neue Kunden, vhosts, etc anlegen. Theoretisch würde ein manuelles anstoßen reichen oder noch besser wäre ein besserer Check von Seitens der Programmierer aus.


    Zitat von bebbo;24813

    - logrotate wird es nicht sein: Eine Datei umzubennen macht keine Load.


    Logrotate macht aber noch viel mehr. Die alten Dateien werden komprimiert, der Inhalt nach Datum durchsucht und der entsprechende Dienst wird neugestartet. Das macht Last, aber nur genau einmal um 3:00 bei den meisten vServern.



    /proc ist ein virtuelles Filesystem was Werte direkt aus dem Kernel zurückliefert. Genau genommen liefert proc dir ein paar Variablen aus dem Speicher zurück. Mehr nicht.
    Es ist klar, dass Überwachungstools auch Last erzeugen, aber diese verstärken nur die Grundlast die eh schon da ist. zabbix hat bei mir ja dauerhaft auf mehreren Kernen Last erzeugt bzw. lief amok.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Bei meinen Monitorixx-Monitoring ist die I/O-Wait auch sogar etwas hoch...


    Wird jede 5 Minuten aktualisiert:


    Tagesstatistik:
    [Blockierte Grafik: http://server.patschi95.de/monitorix/imgs/kern1.day.png]


    Wochenstatistik:
    [Blockierte Grafik: http://server.patschi95.de/monitorix/imgs/kern1.week.png]


    Monatsstatistik:
    [Blockierte Grafik: http://server.patschi95.de/monitorix/imgs/kern1.month.png]


    Also I/O-Wait ist schon etwas auffällig (rosa-farbig)...


    Ich weiß, dass die CPU-Last immer aufgeteilt wird.
    Könnte man aber nicht den Verursacher finden und dann ihn darauf hinweißen, dass er die etwas reduzieren kann?

  • Zitat

    Wird jede 5 Minuten aktualisiert:

    Öhm? Etwas grob, das Raster, um die Auswirkungen der 5min-Cronjobs zu erwischen, oder?

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Häh? Umso schlimmer.
    Wenn du die Peaks der 5min-Cronjobs aufzeichnen willst, brauchst du 1min-Intervalle, keine bis zu wöchentlichen.


    Aber: Meinst du die Generierung des Graphen oder die Datenerhebung?

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de

  • Ach soo :)
    Klar, das ist sinnvoll!
    In welchem Intervall werden denn die Daten erfasst?

    Mein Server:
    v(olks)Server 1. Serie: 2,5GHz, 1024MB RAM, 1024MB Swap, 2x60GB-Raid1-HDD, Traffic-Flat
    Node:
    78.46.117.9x | hos-tr2.ex3k4.rz7.hetzner.de