Das längste Thema

  • Wie könnt ihr eigentlich eure Server so lange laufen lassen? Bekommt ihr nicht auch mal die Meldung im SCP, dass eine neue KVM Version verfügbar ist und dass dafür einmal die Maschine abgeschaltet und neu eingeschaltet werden muss? Oder ignoriert ihr die Meldung einfach und lasst euere Kiste auf der alten KVM Version weiterlaufen?

    Bei netcup habe ich nur einen Server, der so lange (s.o.) läuft. Das ist ein kleiner Monitoringserver, bei dem ich es nie für nötig gehalten habe ihn mal zu rebooten.

    Mein anderer, der seit zwei Jahren online ist, ist ein dedizierter, da gibt es kein KVM.

    Ansonsten werden die durchaus alle mal ab und an neugestartet. (Schon alleine um zu testen, ob sie nach meinen ständigen Rumfrickeleien überhaupt noch booten ^^ )

  • Im Moment laufen alle. Eigentlich ist einer davon zuviel, bin noch am Überlegen, ob der VPS Funny Bunny oder der RS 2000 G9. Naja, wahrscheinlich läuft es eh wieder darauf raus, dass ich mir noch einen weiteren hole.

  • Bin grad recht frustriert.


    So gegen 14 Uhr kam eine Email an, dass mein Webhosting gesperrt wurde. Grund war der, dass ein Skript eine zu hohe Last beim SQL-Server auslöste. Ich gehe mal davon aus, dass diese Last wohl schon über längere Zeit bestand, da sie durch einen Cronjob ausgelöst wurde und es möglich ist, dass so das Skript mehrere Instanzen am rumSELECTen hatte. Ich hatte vergessen, einen Index zu erstellen. Zwischen 5 und 30 Sekunden ohne Index, 0.02 mit Index.


    Kann ich verstehen, dass das nicht gut ankommt. Aber das direkt alles gesperrt wird finde ich recht extrem. Ok, AGB eben, muss ich schlucken.


    Gegen 15 Uhr habe ich die Email gesehen und angerufen, dann das Formular ausgefüllt. Gegen 16 Uhr wurde das Webhosting-Paket wieder freigeschaltet. Soweit so gut.


    Nun habe ich aber das Problem, dass der VPS (auch von Netcup), der den Cronjob laufen ließ und somit die Datenbank überforderte anscheinend durch Fail2ban gebannt wurde, laut der Aussage des Kundendienstes. Der kann sich nun nicht mehr mit der Datenbank verbinden. Andere VPS können das, geht auch von Zuhause aus. Am Telefon wurde mir gesagt, ich solle das im Kontaktformular schildern, was ich dann auch gemacht habe, so gegen 17:20.


    Nun sind schon zwei Stunden vorbei und es tut sich nichts. Im Grunde ist das ein Einzeiler oder ein Klick in einer GUI.


    Ich kann verstehen, dass ich dafür verantwortlich war und deswegen einzustecken habe, aber wenn ein VPS mal down ist weil dies oder jenes, was nicht von mir verursacht wurde, dann bleibt mir auch nichts anderes übrig als nur rumzuwarten. Irgendwie nicht fair.


    Liegt aber wohl eher generell an meinen letzten drei Tagen, dass ich grad nicht so frusttolerant bin. Gestern ist meine Lieblingstasse auf den Boden gefallen und kaputt gegangen, während ich versuchte einen Secure Erase einer SSD zu machen, was einfach nicht ging, weil ein Rechner zu alt ist, um von USB zu booten können und der andere zu neu, um keinen PS2-Port für die Tastatur bereitzustellen, die das blöde Samsung Secure-Erase-Tool benötigt um Tastatureingaben verstehen zu können, und nach dem ganzen Umstecken der SSD nun eine USB3-PCIe-Karte nicht mehr geht. Dazu noch eine Schulterprellung und man fragt sich warum zum Teufel manchmal alles geladen auf einmal kommt. Mein Handy ist auch kurz vor'm platzen weil der Akku...

  • Kann ich verstehen, dass das nicht gut ankommt. Aber das direkt alles gesperrt wird finde ich recht extrem. Ok, AGB eben, muss ich schlucken

    Naja, einerseits verständlich aber auf der anderen Seite musst du halt berücksichtigen, dass du beim Webhosting den Webserver mit anderen Kunden teilst. Wenn bei einem Kunden plötzlich ein Skript anfängt Amok zu laufen, sodass andere Kunden negative Performance Probleme erleiden, dann muss Netcup schnell reagieren. Kritische Websites würde ich daher auch niemals auf einem Shared Webhosting betreiben wollen.

    Ich kann verstehen, dass ich dafür verantwortlich war und deswegen einzustecken habe, aber wenn ein VPS mal down ist weil dies oder jenes, was nicht von mir verursacht wurde, dann bleibt mir auch nichts anderes übrig als nur rumzuwarten. Irgendwie nicht fair.

    Das war doch dein Skript was die Sperre ausgelöst hat? Und Netcup hat nun mal eben auch noch ganz viele andere Kunden. Auch wenn dein Fall sehr schnell gelöst wäre, so gibt es eben noch andere Tickets die nach der Priorisierung abgearbeitet werden. Andernfalls wäre das nicht fair gegenüber den anderen Kunden.

  • Naja, einerseits verständlich aber auf der anderen Seite musst du halt berücksichtigen, dass du beim Webhosting den Webserver mit anderen Kunden teilst.


    Das ist mir ja klar. Aber da würde ja etwa das Fail2ban ja ausreichend sein, da die verursachende Adresse ja bekannt war. Man könnte genauso gut den SQL-Prozess des Kunden renicen, damit er die niedrigste Priorität bekommt, bis er das Problem behoben hat.


    Das war doch dein Skript was die Sperre ausgelöst hat? Und Netcup hat nun mal eben auch noch ganz viele andere Kunden. Auch wenn dein Fall sehr schnell gelöst wäre, so gibt es eben noch andere Tickets die nach der Priorisierung abgearbeitet werden.


    Ja, ist ja klar. Aber was bringt mir das entsperrte Webhosting, wenn ich wegen dem Ban nicht mehr darauf zugreifen kann? Für mich ist es gerade wertlos.


    Wie finde ich überhaupt heraus, ob meine Datenbank eine unerträglich hohe Last auf dem Server generiert?

  • Man könnte genauso gut den SQL-Prozess des Kunden renicen, damit er die niedrigste Priorität bekommt, bis er das Problem behoben hat.

    Wie soll das gehen, wenn die Last durch MySQL (und nicht durch das Script selbst) verursacht wird?


    MySQL-Prozesse kann man nicht sinnvoll per User limitieren, das würde somit ebenfalls alle User auf dem gleichen DB-Server betreffen.


    Dass netcup dann erst einmal keine andere Wahl hat, als das ganze Webhosting zu sperren, ist definitiv nachvollziehbar.

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

    Einmal editiert, zuletzt von KB19 ()

  • Man könnte genauso gut den SQL-Prozess des Kunden renicen, damit er die niedrigste Priorität bekommt, bis er das Problem behoben hat.

    neee, weil man am schluß auf 100 wappler wartet, bis sie aus'm urlaub zurück sind und sich dann evtl. "bemühen", ihr problem zu lösen.

    »Hauptsache BogoMIPS!«

    Fleischfresser

  • Nun habe ich aber das Problem, dass der VPS (auch von Netcup), der den Cronjob laufen ließ und somit die Datenbank überforderte anscheinend durch Fail2ban gebannt wurde, laut der Aussage des Kundendienstes. Der kann sich nun nicht mehr mit der Datenbank verbinden. Andere VPS können das, geht auch von Zuhause aus.

    Wenn es das Script weiterhin versucht hat, obwohl die MySQL-Zugangsdaten durch die Sperrung ungültig sind, könnte auch MySQL den Zugang selbst blockieren.


    Welche Fehlermeldung erhältst Du denn beim Verbindungsversuch? Oder wird die TCP-Verbindung direkt abgelehnt bzw. läuft in ein Timeout?

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

  • Wie soll das gehen, wenn die Last durch MySQL (und nicht durch das Script selbst) verursacht wird?


    MySQL-Prozesse kann man nicht sinnvoll per User limitieren, das würde somit ebenfalls alle User auf dem gleichen DB-Server betreffen.


    Dass netcup dann erst einmal keine andere Wahl hat, als das ganze Webhosting zu sperren, ist definitiv nachvollziehbar.



    Nun mal aus provisorischer Perspektive: Wie kann ich herausfinden, dass meine Datenbank Statements am ausführen ist, die derart asozial sind, dass sie eine Sperrung und einen Ban rechtfertigen? Ich tippe mal, dass es um eine Metrik wie Seconds of Execute per Hour geht. Es ist gut möglich, dass mein Skript zu 100% der Zeit am Tag nur noch am Executen war (damit meine ich die Execute-Phase im SQL-Abfrageablauf) sogar mehrere Instanzen parallel nebeneinander.


    Aber wie gesagt, das ist nichts, was schlagartig kam, das muss sich über Wochen hingezogen haben. Ich kann es halt nicht überprüfen, weil solche Statistiken nirgendwo geloggt werden und ich jetzt auch gar nicht mehr in der Lage sein werde, ein postmortem zu machen, da ich das nicht wiederholen werde. Irgendwie müsste es doch für Netcup messbar sein, dass da etwas so langsam aber sicher beginnt, sich durch die CPU zu fressen, und dies einem Nutzer zuordnen kann, so dass er abgemahnt werden kann.


    Welche Tools, also auch etwa Open Source Tools stehen mir zur Verfügung, um so was zu messen. Wobei man berücksichtigen muss, dass ich auf dem SQL-Server nichts anderes als meine Datenbank anschauen kann, kein `htop` oder sonstwas. Wie viele parallele Abfragen welcher "stärke" kann ich mir erlauben, ohne dass ich mich unfair benehme, wie finde ich das heraus?


    Es ist nämlich gut möglich, dass eine einzelne oder gar zwei Abfragen, die meine Datenbank zu 100% auslasten, die CPU den anderen Nutzern gar nicht auf unfaire Art und Weise wegschnappt.


    Mein Problem ist halt, dass mir da die Möglichkeit fehlt, selbst auf Problemerkennung, -suche und -behebung zu gehen, bevor mir unfaires Verhalten zugeschrieben wird.

  • Welche Fehlermeldung erhältst Du denn beim Verbindungsversuch? Oder wird die TCP-Verbindung direkt abgelehnt bzw. läuft in ein Timeout?


    Ein Telnet von einem ungeblockten VPS sieht so aus:


    telnet 91.xxx.xxx.xxx 3306

    Trying 91.xxx.xxx.xxx...

    Connected to 91.xxx.xxx.xxx.

    Escape character is '^]'.


    vom geblockten hingegen so:


    telnet 91.xxx.xxx.xxx 3306

    Trying 91.xxx.xxx.xxx...

    telnet: Unable to connect to remote host: Connection refused

  • Nun mal aus provisorischer Perspektive: Wie kann ich herausfinden, dass meine Datenbank Statements am ausführen ist, die derart asozial sind, dass sie eine Sperrung und einen Ban rechtfertigen?

    indem man weiß was man tut ... bzw. getan hat ... ;)


    das ganze ist ohnehin nur eine 'was-wäre-wenn-Diskussion'; aber stell Dir vor, Du weißt was Du machst,

    aber der Verursacher liegt in einer Infiltration Deines Systems (VPS, ...) und da wäre eine harte Sperre ohnehin die einzige sinnvolle Mglkt.

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Einmal editiert, zuletzt von mainziman ()

  • Nun mal aus provisorischer Perspektive: Wie kann ich herausfinden, dass meine Datenbank Statements am ausführen ist, die derart asozial sind, dass sie eine Sperrung und einen Ban rechtfertigen?

    Bei einem Shared DB-Server? Gar nicht bzw. nur sehr eingeschränkt.


    Das einzige was Du machen kannst: Deine Queries benchmarken (Ausführungszeit & übertragene Byte) und alle mal mit EXPLAIN aufrufen. Aber sonst wirst Du da nicht viele Möglichkeiten haben.


    Was "zu viel" ist, wird Dir nur netcup beantworten können. Hängt auch von der Hardware und den anderen Kunden ab. Eine Faustregel kann man da nur schwer definieren.

    Connection refused

    Gut, dann wohl wirklich in der Firewall blockiert.

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

  • Gut, dann wohl wirklich in der Firewall blockiert.

    Du meintest vorhin, dass `Wenn es das Script weiterhin versucht hat, obwohl die MySQL-Zugangsdaten durch die Sperrung ungültig sind, könnte auch MySQL den Zugang selbst blockieren.`.


    Wäre das etwas, was ich selbst dann via PMA beheben könnte? Ich habe mich gerade dort überall durchgewühlt und nichts gefunden.

  • leinad Nein, weder die Blockade in MySQL noch in der Firewall kannst Du selbst beheben.


    Außer Du findest irgendwo root-Rechte, was ich nicht hoffe. ^^

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

  • Ich kann verstehen, dass ich dafür verantwortlich war und deswegen einzustecken habe, aber wenn ein VPS mal down ist weil dies oder jenes, was nicht von mir verursacht wurde, dann bleibt mir auch nichts anderes übrig als nur rumzuwarten. Irgendwie nicht fair.

    Naja, wenn du mit einem VPS und einem fehlerhaften Cronjob den Datenbankserver eines Webhostingservers zuballerst, dann finde ich das schon recht heftig. Der Datenbankserver des Webhostings ist ja in erster Linie dazu da, den Webhostingkunden Datenbanken zur Verfügung zu stellen für ihre Websites. Da leiden die Wortpressen :D der anderen Webhostingkunden und die laufen meist eh schon nicht besonders flüssig, wenn man nicht cachet was irgendwie zu cachen ist.

    Ich kenne deinen Anwendungsfall nicht, vielleicht kann ja auch dein VPS nebenher noch Datenbankserver spielen.


    Wenn dein VPS down ist aus Gründen, die nicht in deiner Verantwortung liegen, dann kannst du im Notfall ;) auch den Notfallsupport anrufen. Und wenn es möglichst schnell gehen muss, hilft eventuell auch ein dazugebuchter Service-Level.

  • Sachen "zu Hause" erst mal zu entwickeln, zu testen, zu benchmarken und dann bei Funktionsfähigkeit zu deployen wird anscheinend überbewertet. Einfach gleich mal Bananensoftware ins Internet ballern.

    RS Ostern L OST22 (~RS "3000" G9.5) (8C,24GB,960GB) | RS Cyber Quack (1C,2GB,40GB)

    Danke 1
  • Sachen "zu Hause" erst mal zu entwickeln, zu testen, zu benchmarken und dann bei Funktionsfähigkeit zu deployen wird anscheinend überbewertet. Einfach gleich mal Bananensoftware ins Internet ballern.

    Naja, wurde Zuhause ja zuerst entwickelt und getestet. Nur, als die Datenbank noch klein war lief alles ganz sauber, auch vom VPS aus.


    Deswegen meine ich ja, dass es dieses Problem wohl schon länger gegeben haben muss, da dieses Skript schon über ein Jahr lang lief und die Datenbank so lange wuchs. Da es nur so eine Nebensache war, wurde da auch nicht gemonitort. Ich kann verstehen, dass dies gar nicht gut ankommt, aber mir fehlen irgendwie die Tools, um so was zu überprüfen.


    Wir haben ja einige Statistiken beim Webhosting sowie auch bei den VPS, die uns sehen lassen, dass da was etwa am ansteigen ist oder nicht rund läuft. Diese Tools gibt es aber für die Datenbanken nicht. Und nur schätzen geht ja auch nicht, wenn man keine Infos über den Server hat.


    Die Datenbank auf einen VPS auslagern war auch mein erster Gedanke, aber so von jetzt auf gleich wird das nicht machbar sein. Ich meine, jetzt, durch die korrekten Indices wird das ja erstmal eine Zeit lang gut laufen, die werde ich dann für eine Migration nutzen. Da kommt dann ja noch eine PMA-Installation dazu, sowie die Frage, ob nicht gleich auf PostgreSQL migriert wird.