Beiträge von SCD

GRUB_CMDLINE_LINUX war leer

Gab zwar keine Fehlermeldung, aber trotzdem bleibt es none.

Aber egal, durch sysfsutils habe ich ja eine Lösung ...

Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-8-amd64 root=xxxx ro quiet elevator=mq-deadline

io scheduler mq-deadline registered (default)

jedoch dann

I/O scheduler mq-deadline not found

Zitat von sudo

Außerdem gehts ja um das Grundlegende, du kannst da natürlich eintragen, was du willst

Zitat von SCD

Leider bekomme ich es nicht hin, dies fest in der default/grub zu hinterlegen (es wird einfach nicht beachtet bzw. mq-deadline nicht gefunden).

Edit: Sorry, habe den Link nicht beachtet - Das ist die Lösung, vielen Dank

Zitat von sudo

https://www.netcup-wiki.de/wiki/KVM_Tuning#1._I.2FO_Scheduler

Genau das ist in diesen Fall verkehrt.

Zitat von Ryker

Dir ist schon klar, dass du im Rescue auch dein Filesystem mounten, Anwendungen starten und so prüfen kannst, ob ggf. dein FS das Problem ist? Wenn ein Problem im Livebetrieb auffällt ist IMMER zuerst das Rettungssystem zu konsultieren. Auch wenn dir das in deiner anscheinenden Li-La-Laune Welt nicht passt.

Inzwischen habe ich über die Beschwerde-Stelle die Bestätigung, das das Rettungssystem hier wirklich sinnlos war.

Zitat von Ryker

Zum Schluss: Wenn deine Anwendungen nicht Crash-Safe sind dann ist das nicht das Problem von netcup sondern deins. Wir sprechen hier immer noch über selbst administrierte Systeme.

Mich würde interessieren, was da wirklich los war. Selbst das ext4-System (mit journal) ist so gecrasht das es nicht automatisch wieder hochgekommen ist.

Es gibt also immer noch eine kleine Lücke für den Super-Gau. Siehe Atomkraftwerke ...

Hallo,

ich habe das Problem, das mein Server immer mit dem I/O Scheduler none startet und deshalb eine Utilization per device hat.

Sobald ich

echo deadline > /sys/block/sda/queue/scheduler

bzw.

echo mq-deadline > /sys/block/sda/queue/scheduler

ausführe ist das Problem behoben.

Leider bekomme ich es nicht hin, dies fest in der default/grub zu hinterlegen (es wird einfach nicht beachtet bzw. mq-deadline nicht gefunden.

Wie funktioniert dies jetzt unter Debian 10.3 und warum wird nicht wie bei meinem anderen Server mq-deadline direkt gewählt ?

Stefan

Ist die Frage ob sich das auf den Winter bezieht, oder auf G8.

Wobei ich im Moment nicht glücklich hier bin

Einmal die Auslastungsprobleme mit der HD (siehe oben) und dann ist auch gestern noch der Wirt eines RS 8000, welchen ich betreue, abgestürzt und hat mich einen Tag Wiederherstellung gekostet, da die MySQL-Datenbank so beschädigt war, das ein Recovery nicht mehr möglich war.

Hier durfte ich dann die Datenbank mit MySQL-Dumps wieder aufbauen, die zum Glück nur 15 Minuten alt waren ...

Es geht nur um %util von iostat.

Die Geschwindigkeit selbst in Ordnung.

Zitat

dd if=/dev/zero of=./test.file bs=1M count=500 oflag=direct
500+0 Datensätze ein 500+0 Datensätze aus 524288000 bytes (524 MB, 500 MiB) copied, 0,465063 s, 1,1 GB/s

Und laut SCP Festplatte IOPS ist die Auslastung auch nicht gestiegen. Ich merke sonst auch derzeit keine Einschränkungen.

Wieso antwortet der Support bei jeder Anfrage, man soll erst es in Rettungssystem probieren, ob es da auch auftritt.

Ich habe wieder so ein Fall, wo dies sinnlos ist - Hier die Anfrage nach einer Migration

Zitat

Ich habe gestern den Server neugestartet um die KVM-Verbesserungen zu aktivieren.

Dananch war eine Speicheroptimierung notwendig, die ich auch ausgeführt habe. Seit

dem wird meien Festplatte laut Munin zu 100% beansprucht. Auch iostat zeigt

ähnliche Werte. Vorher war die Auslastung unter 5%.

- Wie geschrieben, war es nun ein Reboot da können keine Fehler an der Software meines Servers sein.

- Es sollte klar sein, das im Rettungssystem das Problem nicht auftritt, da ja da überhaupt nichts auf der Platte gemacht wird.

Oder übersehe ich da etwas und es kann doch direkt an meinem Server liegen ?

a) Let's Encrypt ist auch bei den kleinen Servern möglich

b) In Plesk kann Überbeanspruchung ist zulässig (nicht empfohlen) und Speicherplatz Unbegrenzt gewählt werden

Mein VPS 1000+ ist seit dem Black Friday abgeschaltet.

Deshalb kann ich nicht sagen, was für Auswirkungen der Fehler beim Wirt hatte.

Scheinbar kam der BlackPearl genau richtig

Zitat von timkoop

Meiner dreht gerade am Rad (oder eben nicht). Apache tot, Docker tot, SSH tot (und wahrscheinlich alles andere auch). Im SCP läuft der Monitor noch, ping geht auch noch durch... Mal schauen was er hat

Vielleicht hat die Migration nicht funktioniert:

Mail vom 06.12.11:13

Zitat

aufgrund eines Hardwaredefekts am Wirtssystem Ihres Servers muss dieser auf ein anderes Wirtssystem verschoben werden.

vxxxxxxxx - VPS 1000 G8 Plus

Wir führen dies zum Schutz Ihrer Daten durch. Der Umzug startet binnen der nächsten 24 Stunden. Da Sie Snapshots angelegt haben wird der Server nach dem Umzug einmal neu gestartet.

Hallo,

habe heute meinem VPS 1000 G8 Plus durch den RS BlackPearl BF19 ersetzt (der Arbeitsspeicher wurde langsam zu klein).

Der Server ist derzeit bis zum 12.12.2019 bezahlt und läuft aufgrund der Kündigungsfrist bis zum 11.01.2020.

Stefan

560 GB ist richtig. Wird mir im SCP angezeigt.

Zitat von eripek

Ich glaube die Antwort zu kennen: Froxlor. Wobei man sich wahrscheinlich gedacht haben wird, dass man Debian 9 auslassen kann. Nur gibt es schon getestete Konfigurationssnippet für Froxlor mit Debian Buster?

Auf meinen Server läuft Froxlor zusammen mit Debian 10 ohne Probleme.

Froxlor 0.10.0-rc2 hat auch direkt die Konfiguration für Debian 10 an Board.

Folgende Mail habe ich zum managed Server vor kurzem bekommen:

Zitat

Wir planen aktuell, Ihr System zeitnah auf die neueste Version des Panels Plesk und des verwendeten Betriebssystems zu aktualisieren. Sie profitieren dadurch von Verbesserungen in Plesk (z.B. höhere Geschwindigkeit der Benutzeroberfläche und Verbesserungen im Wordpress Toolkit), von neueren Programmversionen und von einer allgemein erhöhten Performance des Systems.

Bei unseren Vorabprüfungen ist uns aufgefallen, dass Sie noch PHP-Versionen verwenden, die von der neuen Version des Betriebssystems nicht mehr unterstützt werden. Hiervon sind grundsätzlich alle PHP 5.X Versionen betroffen. Versionen ab PHP 7.0 werden weiter unterstützt.

Wir gehen aktuell davon aus, dass viele der Domains die auf PHP 5.6 eingestellt sind, dieses nicht zwangsläufig benötigen, da diese Version standardmäßig beim Erstellen neuer Domains im Plesk-Panel vorausgewählt war. Die gängigen CMS (z.B. Wordpress) und die meisten anderen, aktuellen Webanwendungen, können auch problemlos mit PHP 7.3 arbeiten. Gleichzeitig bietet PHP 7.3 Ihnen als Anwender einige Vorteile, darunter insbesondere große Geschwindigkeitsverbesserungen.

Nutzern von PHP 5.6 werden wir eine PHP 5.6 Version bereitstellen, welche auch nach dem Update genutzt werden kann. Webseiten mit PHP 5.6 werden somit im Rahmen der Upgrades nicht auf PHP 7 umgestellt. Diese PHP 5.6 Version weist allerdings aufgrund des verwendeten, aktualisierten Betriebssystems einige technische Einschränkungen auf und es kann nicht garantiert werden, dass Ihre Anwendungen einwandfrei mit dieser funktionieren werden. Außerdem können wir nicht garantieren, wie lange diese Version noch bereitgestellt werden kann, weswegen wir auch hier dringend ein Update Ihrer Anwendungen auf PHP 7 Kompatibilität empfehlen.

Webseiten, welche zum Zeitpunkt des Updates, welches wir am Anfang des nächsten Jahres ankündigen werden, weiter Versionen älter als PHP 5.6 verwenden, werden im Rahmen des Upgrades automatisch auf PHP 7.0 umgestellt. Sie können bereits jetzt prüfen, ob Ihre Webseite PHP 7.0 oder neuer unterstützt: Loggen Sie sich dazu in das Plesk-Panel Ihres managed Servers ein, wechseln Sie zur betroffenen Domain und ändern Sie die PHP-Version in den "Hosting-Einstellungen" der Domain. Wir empfehlen Ihnen, zunächst die neueste Version, PHP 7.3 zu testen, um auch langfristig für die Zukunft gerüstet zu sein. Sollte diese nicht funktionieren, testen Sie am Besten auch PHP 7.2. Unter Umständen kann es nötig sein, dass Anpassungen Ihrer Anwendungen nötig sind, um eine Kompatibilität mit jeglichen PHP 7 Versionen zu gewährleisten. Dies betrifft die meisten gängigen Webanwendungen nicht, kann aber z.B. insbesondere bei individuell programmierten, oder nicht mehr weiterentwickelten Skript en, zutreffen. Wir verstehen, dass dies einen hohen Aufwand für Sie darstellt. Aus Gründen der Systemstabilität und -sicherheit kann allerdings eine weitere Unterstützung von PHP 5 nicht mehr geleistet werden. Wir bitten hierfür um Ihr Verständnis.

PHP 5.5 wird bereits seit Mitte 2016 nicht mehr mit Aktualisierungen versorgt. Trotzdem haben wir diese und ältere PHP 5 Versionen weiter unterstützt. Dies ist nun aufgrund der neuen Betriebssystem-Version nicht mehr möglich. Auch PHP 5.6 erhält seit Anfang 2019 keine Updates mehr.

Wir verstehen, dass diese Maßnahme für Sie eine hohe Belastung darstellen kann. Dennoch ist die Abschaltung von PHP 5 aus technischer Sicht unvermeidlich. Es sei bereits vorab darauf hingewiesen, dass wir Versionen, welche älter als PHP 5.6 sind, auf keinen Fall länger unterstützen können. Diese Versionen werden in jedem Fall im Rahmen des Upgrades entfernt und diesbezüglich können wir auch keine Ausnahmen machen. Wir bedanken uns für Ihr Verständnis.

Alles anzeigen

Zitat von Paul

Alle Reboots haben anstandslos funktioniert. Hier mal ein Dankeschön an Netcup für die reibungslose Arbeit. Ich weiß, andere hier hatten nicht so viel Glück, aber ab und zu kann man ja auch mal die postitiven Geschichten erwähnen.

Bei den meisten Servern die ich direkt oder für anderen Kunden bei Netcup betreue lief auch alles glatt. Aber der Server heute ging gewaltig daneben.

Sollte nicht, kann aber passieren. Wenn sich Netcup dann beim Anruf direkt drum kümmern wurde, hätte ich ja Verständnis gehabt.

Aber nicht wenn bei der Hotline direkt gesagt wird "Fehler bei Reboot durch ZombieLoad, im Recovery-System nachzuvollziehen" und man nur als Antwort bekommt, schreiben Sie ein Ticket. Und dieses Ticket wird erst nach vier Stunde bearbeitet.

Von einen professionellen Anbieter erwarte ich dann sofortige Hilfe und keine Abarbeitung der Tickets in Reihenfolge.

Und der Kunde, welcher dem Server gehört wäre auch gerne Bereit gewesen, die Notfallgebühr zu bezahlen, wenn es doch nicht Schuld von Netcup gewesen wäre.

[netcup] Felix P. Ich häte hierzu gerne eine Stellungnahme. Es geht um https://forum.netcup.de/administration…icht-erreichbar

Um 13:50, 4 Stunden nach dem Reboot läuft der Server wieder.

Leider wurde ich von der Hotline nicht zum Techniker durchgestellt.

Ich kann zwar verstehen, dass dies nicht bei jeder Anfrage geht, aber bei einen Komplettausfall in der Länge sollte doch schon die Möglichkeit dazu geben.

Gerne kann dafür auch die Notfall-Nummer auch zur Geschäftszeit mit den gleichen Konditionen wie außerhalb der Geschäftszeit genutzt werden.

Ist fest hinterlegt. Aber wie gesagt, selbst das Recovery-System startet nicht ...