Beiträge von KB19

    Da könnte der Angreifer doch genau so gut einen DNS-Eintrag setzen. Das fändest du dann weniger gefährlich?

    Natürlich nicht, da kann er doch nachher den Verursacher finden: whois example.xyz

    "Aja, ganz weit unten steht ja was. Hab ich Dich, Du böser F.P. in der Daimlerstr." ^^

    (SCNR)

    Sorry für die späte Antwort, ich habe die Benachrichtigung übersehen…

    psd.phi Wenn die Warnmeldung auch bei so einer einfachen PHP-Datei wie aus meinem Beispiel erscheint, muss definitiv der Support ran. Das kannst Du selbst nicht lösen.

    Gib bitte nachher Bescheid, was der Support dazu gesagt hat. :)

    Wenn man Speicherplatz sparen möchte durch Entfernen unnötiger Locales und einen Fehler macht… :rolleyes:

    Ich habe mir versehentlich das ganze /usr/share/locale Verzeichnis gelöscht! 8o

    Ich suche mal das Backup, geht schneller als alle Pakete neu zu installieren… :S

    Edit: Das kommt davon, wenn man -mindepth beim find Befehl vergisst und die Ausgabe nicht sorgfältig genug kontrolliert.

    eripek PayPal nutzen, dort kannst Du auch KK hinterlegen und für einzelne Zahlungen oder dauerhaft verwenden. Zusammen mit PayPal-Guthaben kann man so auch effizient Restguthaben von Prepaid-KK bis zum letzten Cent nutzen.

    Morgen bewerte ich die Situation neu.

    Der VPS 1000 G8 Plus macht keine Probleme mehr seit heute Nacht.

    O-Ton des Supports (sinngemäß): Geteilte Systeme, Systeme werden laufend überwacht um Engpässe festzustellen, Engpass wurde beseitigt, Ursache dürfen sie mir nicht sagen, …

    Na dann :/

    Planänderung: Keinerlei Änderung heute Nacht, nichts mit NFS, alles läuft unverändert weiter…

    Der Backuptask läuft seit 02:00 Uhr und zeigt keine Auffälligkeiten. Der Slave dümpelt auf schönen 0s Delay herum.

    Ich verschwinde ins Bett und hoffe, dass das Monitoring nicht erneut Amok läuft. Morgen bewerte ich die Situation neu.

    Bis 0 kam er dieses Mal nicht…

    Also nochmals ein Neustart… :D

    Hui, das ging schnell! =O Wobei man beachten muss, dass es sich dabei um Daten ab Mitternacht handelt und da ist normalerweise etwas weniger los am Master.

    Den nächsten "Neustart" führe ich zum Test mal so aus, dass der VM-Prozess nicht beendet wird. Also wirklich nur ein Reboot. Sollte es am Kernel des Gastes liegen, sollte das genau das gleiche Verhalten zeigen, wie bei den anderen Neustarts mit komplettem Shutdown. Andernfalls wird die I/O-Performance wahrscheinlich nicht besser.

    Kurze Ergänzung: Irgendwas ist da wirklich faul. Nach einem Shutdown und erneuten Start der VM… :/

    Ich will aber nicht behaupten, dass das zwangsläufig die Schuld vom Host sein muss. Der Fehler könnte theoretisch auch in meinem System liegen. Seltsame I/O Probleme könnten ebenso durch Kernelbugs entstehen. Langsam unwahrscheinlich, aber immer noch denkbar.

    tab  H6G Ich ziehe den bzw. die Slaves heute Nacht noch nicht um. Ich will mal schauen, wie es sich verhält, wenn ich nur das Datenverzeichnis auf einen anderen Server verlege und mittels NFS anspreche. Den Backuptask werde ich für heute Nacht mal temporär aussetzen.

    Was meinen VPS 1000 mit Optane angeht: Der Support hält mir einen Werbevortrag für die Vorteile von RS :*

    Ich habe nochmals nachgehakt… :saint:

    Spoiler anzeigen

    Wenn alles nichts hilft, schiebe ich die Slaves heute Nacht (temporär) auf den RS X-Mas 2016, da läuft gerade eh nichts drauf.

    Mal schauen, wie lange es dieses Mal anhält. Sehr komisch.

    Hat wohl nur eine gute Stunde gehalten, geht wieder los… :/

    Also entweder läuft da auf meinem System etwas schief oder der I/O-Scheduler am Host regelt mich aggressiv runter nach einigen Minuten bzw. einer bestimmten Datenmenge. Nach einem erneuten Shutdown der VM läuft es wieder super schnell und dieses Mal war es sogar ein sauberer Shutdown:

    Mal schauen, wie lange es dieses Mal anhält. Sehr komisch.

    Ok, Ticket eröffnet. Der Slave lief sauber auf 0 Delay runter, mittlerweile pendelt er sich wieder bei 300-500 Sekunden ein. Die Werte sahen dazwischen super aus, jetzt gehen sie erneut in den Keller… :(

    Vielleicht läuft am Host ein Raid-Rebuild? Auf jeden Fall suche ich nicht gerne weiter einen Fehler bei mir, wenn es vielleicht am Hostsystem liegt.

    Was sagt der Support dazu?

    Siehe mein Edit: Den habe ich noch nicht kontaktiert. Nach dem Neustart scheint es zu laufen. Aktuell ist der Slave bei nur mehr 1.8k Delay.

    Könnte genauso am Kernel liegen, ich weiß es nicht. Auf meinem KVM-Host (nicht Gast!) zu Hause hatte ich auch erst vor wenigen Tagen ein seltsames I/O-Problem, das ich nicht eingrenzen konnte. Erst ein Neustart hat geholfen, dass es wieder flüssig lief. Und auch dort war die Uptime relativ hoch…

    Laut meinen Aufzeichnungen gab es so einen Engpass schon einmal Ende Dezember am VPS 1000, der hat sich aber wieder von selbst aufgelöst nach einigen Stunden.

    Hat hier zufällig noch jemand Probleme mit einem VPS 1000 G8 Plus? Seit ca. 01:30 stieg das I/O-Wait massiv an, einer meiner MariaDB-Slaves kam selbst mit den wenigen Queries der Nachtstunden absolut nicht mehr hinterher. Mittlerweile ist er bei 1h Delay! :D

    Dazwischen war er sogar bei 20k Delay (in Sekunden) ^^

    Ich habe jetzt mal einen (garantierten) Neustart durchgeführt. Mit dem Ergebnis, das das Speichermedium so ausgelastet war, dass nicht einmal ein sauberer Shutdown möglich war. Nach dem Neustart holt der Slave auf, mal schauen, ob es so bleibt:

    Den Support habe ich nicht kontaktiert, gibt derzeit keinen Grund dazu. Ich bin gespannt, wie die Werte in den Nachtstunden während der Backuptasks ausschauen.