Posts by leinad

    Jup.

    Oder erstelle halt schnell eine lokale VM z.B. mit VirtualBox :)


    Ein Linux-System und das MySQL/MariaDB Paket sind ja schnell installiert. Dann kannst Du die jeweiligen SQL-Queries mal grob über SSH testen, wie sie sich im Detail auswirken.

    Vom ganzen Shared MySQL-Server? Das wird nicht klappen, da Du dort ja nicht einmal PHP selbst ausführen kannst. Und phpMyAdmin dafür anzuzapfen ist zwar denkbar, aber auch nicht Sinn der Sache. Letzten Endes sind die Zahlen sowieso nichtssagend, Du weiß so ja nicht, ob Du der Verursacher der Last bist. ;)


    Ich habe noch einen VPS rumliegen, auf den ich heute Morgen schon MySQL in Docker "installieren" wollte. Da dann aber noch phpMyAdmin dazukommen muss, wird das noch etwas aufwändiger. Dann kamen die Arzttermine wg. der Schulter dazwischen (im "originalen Post" erwähnt) und der Tag ist auch bald zu Ende.


    Die CPU-Zahlen sind nicht ganz so nichtssagend. Inzwischen habe ich schon erkannt, dass es irgendwo Cronjobs gibt, die alle Minute den Server zu 80-90% auslasten, immer so für ca 5 Sekunden. Das, während bei mir gar nichts auf der Datenbank gemacht wird, ist also nicht von mir verursacht. Grundlast liegt bei 20%. Wenn ich dann mein Skript laufen lasse, dann erkennt man da gar nichts, hat also so gut wie keine Auswirkungen auf die CPU-Last, nach der Korrektur.

    Okay, nun hat sich das mit der geblockten IP geklärt, die war "noch in der Firewall des Mailservers gesperrt". :/


    Ich habe mich mal näher mit PMA auseinandergesetzt und gesehen, dass unter /phpMyAdmin/index.php?route=/server/status/monitor die CPU-Auslastung sichtbar ist, sofern man dies in den Einstellungen hinzugefügt hat.


    Wenn ich mir das so anschaue, scheint es die mit allen geteilte CPU-Last sein, also die Gesamtlast auf dem Server.


    Ich wünschte, ich könnte mal kurz die Indices wieder löschen, um genau zu schauen, wie asozial das wirklich war, aber da lasse ich besser die Finger von. Ich werde das mal auf einem VPS nachbauen und checken, eventuell die DB gleich auf den VPS migrieren. So mit Index scheinen meine Abfragen rein gar nichts auszumachen.


    Super wär's, wenn ich diese CPU-Leistung selbst loggen könnte. Hat da jemand eine Ahnung, ob man das machen kann?

    Ich hoffe ich habe es nicht überlesen (es ist viel zu früh und ich bin absolut keine Morgenperson), aber wie oft läuft denn dein Skript?

    Das macht mich neugierig, weil wenn es nur 1-2x am Tag für 5-30 Sekunden etwas macht, klingt das für mich gar nicht so krass :/

    Wenn das alle 5 Minuten passiert, upsi.

    Es lief alle 5 Minuten. Es hatte mehrere solche Abfragen, die 5-30 Sekunden liefen (in der Regel eher zu den 5 Sekunden tendierend, mit 30-Sekunden auschreitern), so dass es möglich sein kann, dass ein Skript über 5 Minuten lief und diese sich somit überlagerten.


    Wenn ich mir aber die Stats des VPS anschaue, auf dem dieser Cronjob lief, hat sich in den letzten 30 Tagen nichts verändert gehabt. Genauer gesagt ist die Last in diesem Zeitraum sogar runter gegangen. Es ist gut möglich, dass die sich nicht überlagerten, aber ich kann das ja nun nicht mehr überprüfen.


    Ich frage mich nur, wann dieser Ban beseitigt wird.

    genau so und auch mit der kompletten Entwicklungsumgebung auf dem VPS :D

    Hey, über so was macht man keine Witze! Ich musste schon meinen .vscode-server Ordner auf dem VPS löschen weil der einfach zu groß war. ;)


    Immerhin hat mir das alles was gezeigt: Beim Suchen bin ich drauf gekommen, dass es anscheinend auch keine enforcte Speicherplatz-Quota gibt, und ein Überschreiten ebenfalls streng geahndet wird. Zum Glück monitore ich den Speicherplatz wie verrückt.

    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.

    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.

    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

    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.

    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?

    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...

    Hi,


    sagt mal, wisst ihr ob diese Neuerung mit der 1-Monats-Kündigungsfrist, die seit diesem Jahr gilt, auch auf Dinge wie Server- oder Webhosting-Verträge anwendbar ist?


    Also angenommen ich habe am 15.03.2020 einen Webhosting-Vertrag abgeschlossen, dann wurde der ja immer wieder für ein Jahr verlängert. Dieses Jahr wäre also die Kündigung für den 15.03.2022 möglich, also spätestens am 12.02.2022 einzureichen, damit er sich nicht wieder für ein Jahr verlängert.


    Mit dieser Neuerung wäre ja aber der Vertrag nun jeden Monat mit einem Monat Frist kündbar, also ich können ihn am 14.03.2022 kündigen und die würde dann am 15.04.2022 in kraft treten.


    Ist das richtig so, oder hat das nur mit Zeitungen, Fitnessstudios und Telco-Verträgen zu tun?


    Zudem gibt es kürzere Kündigungsfristen für Verträge mit Fitnessstudios oder Zeitschriften-Abos, die ab dem 1. März abgeschlossen werden. Statt drei Monate im Voraus können die Kunden die Laufzeitverträge nun einen Monat vor der Frist kündigen. Die monatliche Kündigungsfrist gilt jederzeit - auch nach Ablauf der ursprünglichen Vertragslaufzeit. Bisher verlängerten sich die meisten Verträge um ein Jahr, wenn nicht drei Monate vorher die Kündigung eingereicht wurde.


    Für Handy- und Internetverträge gelten die kürzeren Kündigungsfristen bereits seit Anfang Dezember. Lediglich Versicherungsverträge sind von der neuen Regelung ausgenommen.




    Hi. Ich hatte heute nach einem Technikertermin eine neue IP-Adresse bekommen und seit dem ist der Upload zum Server auf ca 2-3 MBit/s gekappt. Ist so was bekannt, dass bestimmte IP-Adressen gedrosselt werden?


    ---


    Update: Das betrifft nur einen Server (RS 1000). Ein weiterer bei Netcup hat dieses Problem nicht. Bei der Konkurrenz ebenfalls kein Problem.


    Ich habe den schon rebootet, hat aber nichts gebracht.

    Zeigt der erste Screenshot nicht einen Packet Loss von 18% zum ersten externen Gerät an?


    Wenn du diese Probleme bei Netcup bemerkst, sind dann auch andere Seiten betroffen? Ist dein Upstream eventuell ausgelastet? Mach mal einen Speedtest während diese Probleme auftauchen, am besten mit einen Server von deinem ISP. Bei Vodafone in BW ist dies etwa speedtest.unitymedia.de

    Habt ihr den kleinen Root-Server für 10,36€ schon gesehen? Mich würde interessieren was der für Spezifikationen mitbringt, die meisten Angebote sind mir dann doch zu groß :)


    Grüße!


    Meinst du den?


    RS Ostern M OST21

    Da hoppelt der Osterhase gleich viel schneller. Der RS Ostern M für nur 11,49 EUR pro Monat!


    AMD EPYC™ 7702

    16 GB DDR4 ECC RAM

    KVM-Technologie

    99,9 % Mindestverfügbarkeit

    Sicheres und schnelles RAID10 (Hardware-RAID-Controller)

    Konsole zur Fernwartung, Backupsystem uvm...

    11,49€ pro Monat

    In den Warenkorb >



    Ich würde gerne mal einen RS Ostern S OST21 sehen. Also falls jemand einen sieht, ihr wisst bescheid.