vServer drehen (dreht) durch!

  • @ ice-breaker: /SIGN!


    Ich selbst würde nicht behaupten, dass mein vServer über das hinaus, was er verkraften sollte, beladen ist. Der RAM fährt auf 50% bis 60%, die CPU hat fast nie etwas zu tun, Besucher habe ich kaum, denn die Dienste nutze ich eher selbst.


    Dennoch treten Lags auf, die definitiv nicht von mir verursacht sind, sondern mit einfachster deduktiver Logik auf Cronjobs anderer vServer auf em Hostsystem zurückzuführen sind.


    Und dass selbst ein frisch aufgsetztes System, welches eigentlich von einem 50MHz-CPU-System problemlos zu bewältigen sein sollte, in der Konsole ab und zu hängt, wird wohl auch nicht Schuld des Serveradmins sein, sondern hat eventuell mit den Nachbarn auf dem Hostsystem zu tun.


    Zitat

    Der Ort dieser Diskussion ist auch etwas unglücklich da bestimmte Probleme (z.B. die von Patschi) bestimmt auf Selbstverschulden zurückführbar sind.

    Das stimmt wohl leider.
    @ Patchi: Die CPU-Auslastungen, die htop dir zeigt, sind egal. Nicht nur, da sie nur die Zeit anzeigen, in denen die CPU überhaupt beschäftigt ist, wo durch das Sheduling auf jeden Fall die dir zugesicherten Leistungen parat stehen, es hat, wie es bei dir aussieht, nichts mit Lags zu tun. Und welche CPU was hat, ist Zufall, es gibt nicht deine CPU, meine CPU.
    Aber der RAM ist schön! Nur braucht er durch fehlendes Caching und so natürlich umso mehr IO auf der HDD.

    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, du bist immer Schule ;) ;) ;)


    Soory... musste jetzt sein...


    Ich stell dir gerne mal meinen leeren Server zur verfügung...Den kannst du konfigurieren... Ich habe solche Probleme nämlich nicht und ich hab ihn gestern Platt gemacht.
    Dann kannst du ausschließen, dass es an deier KOnfiguration liegt...

  • Zitat von Artimis;24587

    Ich selbst würde nicht behaupten, dass mein vServer über das hinaus, was er verkraften sollte, beladen ist. Der RAM fährt auf 50% bis 60%, die CPU hat fast nie etwas zu tun, Besucher habe ich kaum, denn die Dienste nutze ich eher selbst.


    30% Ram und nur Daemons im Hintergrund sowie einen Java-Webserver der nur idlet, CPU und IO-Zugriffe macht da bei mir nichts.


    Trotzdem kann ich immerwieder mal feststellen (meist nachts), dass Verzeichnisoperationen (somit IO-Zugriffe) mehrere Sekunden hängen.
    Für mich ist es verkraftbar, ich habe daraus den Schluss gezogen nur noch Dev-Systeme auf dem vServer laufen zu lassen und mir keinen starken Produktiv-vServer zuzulegen, dafür wird nun ein dedicated genutzt.

  • Sorry, was meinste mit "ich bin immer Schule"? :D


    Ne, deinen vServer will ich nicht testen, da er sich wohl auf einem anderen Hostsystem befindet. Es reicht, meinen in den Rettungsmodus zu versetzen oder ein Backup zu erstellen und neu aufzusetzen. Dann habe ich weiterhin die gleichen lieben Nachbarn.
    Am Anfang, als ich den vServer neu hatte (und so natürlich alles platt war), habe ich schon diese Konsolenhänger mitgekriegt. Ich habe sie aber auf meine Internetanbindung geschoben.

    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

  • Wir können ja mal schauen, ob mein vServer schuld ist.


    Wenn der nächste "Lag" auftritt, schaut wer auf "htop" und ich dreh meinen vServer ab. Dann können wir beobachten, ob die 100% Auslastung der Kerne wieder sinkt oder nicht.

  • ice-breaker: OK, zu uns beiden muss man sagen, dass man natürlich durch die Configs ordentlich "optimieren" kann. So erhält man eine RAM-Auslastung wie die von Patschi, sogrt aber für massive IO-Zugriffe auf die Platte.
    Aber meine Konfigs sind mit großzügigem Caching und so konfiguriert.


    Scaleo: Axo^^
    Naja, ich tue mein bestes, die Ressourcen nicht übermäßig und dann zu beanspruchen, wenn andere sie ebenfalls brauchen.

    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

    Dennoch treten Lags auf, die definitiv nicht von mir verursacht sind, sondern mit einfachster deduktiver Logik auf Cronjobs anderer vServer auf em Hostsystem zurückzuführen sind.

    Sie bemängeln Fehler an einer VoIP-Softwarelösung die sehr stark danach aussehen, dass sie von einer nicht vorhandenen Paket-Priorisierung herrühren. Das hat nichts mit einem vServer an sich zu tun. Würden wir hier im Büro im Router die Priorisierung abschalten, könnten wir nicht mehr sauber telefonieren.


    ice-breaker: Das besonders Nachts die Festplatten aufgrund von Logrotates und Backups ausgelastet sind, ist bei vServer die ein geteiltes Festplattensystem nutzen nicht vermeidbar. Die Lösung dafür ist meistens, dass man selber Logrotate z.B. um 8 Uhr Morgens ausführt. Da haben die Festplatten immer am wenigsten zu tun und man kann auch Nachts mit seiner anteiligen Zugriffsgarantie auf das Festplattensystem so zugreifen, dass gängige Aufgaben (Webserver, MySQL...) ohne Aussetzer arbeiten können. Ein vServer kostet weit aus weniger als ein Dedizierter Server, da hier Ressourcen geteilt werden.


    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.

  • Könnte ich machen, aber wir nicht viel bringen.


    Die Cronjobs brauchen nicht viel Ressourcen.
    Um Mitternacht sind legendlich nur 2 Cronjobs.


    1) Lädt die Spammer'IPs von stopforumspams.com herunter und entpackt die in einen Ordner. (500kb-Datei)
    2) Backup-Script. Packt einige Ordner in .tar.gz Format und lädt die auf meinen FTP Server hoch. Das sind 250MB. Belastet eigentlich nur die Internetverbindung und nicht die CPU-Auslastung. Das packen geht ziemlich schnell und verursacht sicher nicht so eine hohe und eine langfristige Auslastung auf 100%.


    Die restlichen Cronjobs rufen legendlich einfache Seiten auf.

  • Zitat von Artimis;24593

    Es reicht, meinen in den Rettungsmodus zu versetzen [...] Dann habe ich weiterhin die gleichen lieben Nachbarn.


    Hast du bzw. alle hier im Thread das schon einmal versucht? Einfach Rettungssystem booten und dort die einfachsten Befehle wie ls|exit usw. ausführen, die laut euren Aussagen einige Sekunden bis Minuten dauern? Das wäre dann doch der beste Beweis, dass es nicht am eigenen System liegt, wenn nur ein SSH-Daemon und keine Cronjobs o.ä. laufen. Dazu vielleicht noch einige tar Dateien zum Test (ent)packen.



    MfG Christian

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

  • Zitat von [netcup] Felix;24598

    ice-breaker: Das besonders Nachts die Festplatten aufgrund von Logrotates und Backups ausgelastet sind, ist bei vServer die ein geteiltes Festplattensystem nutzen nicht vermeidbar. Die Lösung dafür ist meistens, dass man selber Logrotate z.B. um 8 Uhr Morgens ausführt. Da haben die Festplatten immer am wenigsten zu tun und man kann auch Nachts mit seiner anteiligen Zugriffsgarantie auf das Festplattensystem so zugreifen, dass gängige Aufgaben (Webserver, MySQL...) ohne Aussetzer arbeiten können.


    ich mache momentan weder Logrotates noch Backup noch loggt der Webserver, wenn ich einmal im Monat darauf zugreife, den Zugriff.
    Ich selbst verursache also keine nennenswerte IO-Last, trotzdem hängt Putty dann manchmal für mehrere Sekunden.


    Was ich genauso feststellen kann ist, dass der Webserver (wenn lange nicht zugegriffen wurde) 2-3 Sekunden für eine Antwort benötigt, danach geht alles wieder in unter 100ms. Kann es sein, dass der unsichtbar vom Host geswapped wird?

  • Zitat von killerbees19;24602

    Hast du bzw. alle hier im Thread das schon einmal versucht? Einfach Rettungssystem booten und dort die einfachsten Befehle wie ls|exit usw. ausführen, die laut euren Aussagen einige Sekunden bis Minuten dauern?


    Tritt bei mir leider so selten und sporadisch auf, dass ich nicht die Zeit habe stundenlang in Putty rumzuspielen, bis das Problem irgendwann einmal auftreten können.

  • Zitat

    Was ich genauso feststellen kann ist, dass der Webserver (wenn lange nicht zugegriffen wurde) 2-3 Sekunden für eine Antwort benötigt, danach geht alles wieder in unter 100ms. Kann es sein, dass der unsichtbar vom Host geswapped wird?


    Nein, alles was im RAM ist, ist auch im physikalischen RAM.


    Wenn wirklich nichts auf Ihrem vServer los ist und SSH nicht korrekt arbeitet, wenden Sie sich doch bitte einmal an den Support. Dieser würde die Auslastung Ihres Systems prüfen und es dann test-halber auf einen anderen Node verschieben.


    Bei Apache2 kann ich dieses Phänomen bestätigen. Es liegt aber nicht am vServer. Das tritt auch bei dedizierten Server auf.

  • Zitat

    Sie bemängeln Fehler an einer VoIP-Softwarelösung die sehr stark danach aussehen, dass sie von einer nicht vorhandenen Paket-Priorisierung herrühren. Das hat nichts mit einem vServer an sich zu tun.

    Die Software ist der alles andere als unausgereifte Asterisk, der auf einem anderen vServer und einem NAS-Terminal schon hervorragend lief. Leider hat der andere vServer nicht soo die fetten Ressourcen, sodass ich auf andere Anwendungen dort verzichten müsste, und das NAS-Terminal ist mit ADSL-6000/512 nicht gut genug angebunden, falls ich nebenher Traffic verursache.
    Der einzige Fehler von Asterisk ist und bleibt: Alle 10min, besonders bei 0, 20 und 40 lagt es.
    Das liegt wohl eher nicht an der Paketpriorisierung, da ich nicht mit einem schlagartig erhöhten Trafficaufkommen zu der Zeit rechne.
    Außerdem kommt es weiterhin zu hängern in der Konsole, die bestimmt nicht durch "schlechte Paketpriorisierung in der SSH-Software" verursacht werden.
    Der Fehler wird wohl sein, dass zu der Zeit Cronjobs (und zwar nicht die meinen!) durchlaufen, die die CPU so sehr belasten, dass die Pakete nicht schnell genug konvertiert werden können.
    Ein Node-Umzug kommt allerdings nicht infrage, da die IP-Adressen inzwischen an einen sehr breiten Benutzerkreis ausgegeben wurden.


    Ich weiß nicht, wo man bei diesen voneinander unabhängigen Problemen von Konsolen-Lags und Telefonserver-Lags bei einem System, was nachweislich nichts zu den Lagzeitpunkten zu tun hat, noch davon sprechen kann, dass der Fehler eindeutig auf meiner Seite liegt. Ich meine: offensichtlicher geht es doch kaum, oder? Und es gibt auch Kunden von den "Bei mit lagts"-Beschwerern, wo keine 3 GameServer, 2 IRCds und Schwergweichte wie Apachen und mySQLds laufen und bei denen dennoch schon die Shell zum Kaffee-Trinken auffordert.

    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 [netcup] Felix;24606

    Wenn wirklich nichts auf Ihrem vServer los ist und SSH nicht korrekt arbeitet, wenden Sie sich doch bitte einmal an den Support. Dieser würde die Auslastung Ihres Systems prüfen und es dann test-halber auf einen anderen Node verschieben.


    nein, wie gesagt ist es nur noch ein Dev-vServer, dem ist es egal ob er mal hängt, dann geben sie lieber Artimis die Chance, deren Problem ist reproduzierbar.


    Zitat von [netcup] Felix;24606

    Bei Apache2 kann ich dieses Phänomen bestätigen. Es liegt aber nicht am vServer. Das tritt auch bei dedizierten Server auf.


    *gg*
    wer Apache verwendet ist selbst Schuld :D

  • Zitat von Artimis;24607

    Und es gibt auch Kunden von den "Bei mit lagts"-Beschwerern, wo keine 3 GameServer, 2 IRCds und Schwergweichte wie Apachen und mySQLds laufen und bei denen dennoch schon die Shell zum Kaffee-Trinken auffordert.


    Nicht nur die shell, auch HTTP, etc.
    Der komplette Server laggt.


    Wie kann ich Logdatei-Rotation deaktivieren?
    Ohne die Einträge löschen zu müssen.

  • Artimis: Wieso gehen Sie davon aus, dass ein anderes System Ihr System negativ beeinflusst? Steht Ihnen kein RAM oder keine CPU mehr zur Verfügung? Wie hoch ist die Load? Woher stammen die Lags?


    Zu Asterisk: Bei VoIP ist eine Priorisierung der Pakete eine generelle Empfehlung. Bei uns im Büro würde VoIP nicht ohne Priorisierung funktionieren. Meldet sich Ihr System (rein zufällig) alle 10 Minuten am SIP-Server an?