Kernelupdate vom 09.04.2010

Die Gameserver sind nun wieder mal erreichbar. TS geht nach wie vor nicht. So langsam nervt das extrem. Vor dem Update gab es 0 Probleme .....

Also Ausfälle hatte ich noch keine, allerdings springt mein Load gelegentlich auf über 1.5 obwohl nicht viel los ist auf dem Server. Dadurch kommt es zu gelegentlichem laggen. So ein verhalten konnte ich vor dem Update auch nicht beobachten.

Da ich mehrere Server verwalte kann ich auch diverse Werte vergleichen und muss feststellen das auf meinem Server die CPU Grundauslastung höher liegt als auf unserem Clan Server (beides sind vServer VP3000). Das hat nichts mit den laufenden Diensten zu tun sondern kommt direkt vom Node. Es ist auch nicht temporär sondern dauert schon einige Tage an. Eigentlich nichts schlimmes, aber es läuft alles etwas unrund bei mir.

Hier mal 2 Screens

Meiner
[Blockierte Grafik: http://www.stachi.de/dl/cpu_chart.png]

Der Clan-Server
[Blockierte Grafik: http://www.stachi.de/dl/cpu_chart_clan.png]

Bilder powered by sims's vServer Monitor (mit ein paar Updates von mir):D

Zitat

bei dem bild was ich gepostet hab

... ist ein htaccess-Schutz davor

Etwas ist mir beim vServer Bronze jetzt doch noch aufgefallen: Seit dem Kernel Update friert die Konsole Pseudo-Mäßig ein, wenn ich HDD-intensive Aufgaben ausführe. Also z.B. große Dateien kopieren/modifizieren/einlesen. So z.B. auch bei du oder einem MySQL-Start. Die Konsole zeigt aber wieder alles weitere an, sobald ich z.B. 10-mal einen Buchstaben drücke. Vor dem Kernel Update hatte ich dieses Problem aber nicht und am vServer Gold habe ich es auch jetzt nicht. Ich werde das morgen einmal genauer beobachten.

MfG Christian

Wir sind natürlich bemüht, unseren Kunden eine zufriedenstellende Situation zu bieten. Das Kernelupdate hat, wie ja bereits geschrieben, dass komplette CPU-Scheduling gefestigt. Es wurde deutlich stabiler was sich auch daran zeigt, dass MySQL fehlerfrei arbeitet, was bei einer größeren Zahl von Kunden die den älteren Kernel hatten nicht der Fall war. Festplattenzugriffe werden mit dem neuen Kernel klar und gerecht zwischen allen vServern verteilt.

Hatte ein vServer in der Vergangenheit extrem viele Festplattenzugriffe, konnte er diese fast alle absetzen und dadurch andere vServer einschränken. Dieses ist jetzt nicht mehr möglich, was natürlich besonders bei kleineren vServern bemerkbar sein kann. Große vServer sollten eine spürbare Leistungssteigerung bemerken, was die Festplattenzugriffe anbelangt.

Natürlich wird eine Grundfunktionalität bei jedem vServer gewährleistet sein. Alle garantierten Leistungen stehen selbstverständlich zur Verfügung.

Da hier vermehrt von einem "einfrieren" gesprochen wird, haben wir dieses versucht letzte Nacht nachzuvollziehen. Wir haben kleine vServer aufgesetzt und diese mit gängiger Software ausgestattet. Leider ist dieses "Einfrieren" nicht bei uns aufgetreten.

Wir bitten daher um folgendes:

Sollten Sie dieses "Einfrieren" erneut feststellen, wären wir Ihnen sehr dankbar wenn Sie uns eine eMail an vserver at netcup _ de senden die wie folgt aufgebaut ist:

Zeitpunkt:
vServername:
Dauer des "Einfrierens" in Sekunden:
Letzter Befehl vor dem "Einfrieren":
Ausgabe von ps -ef direkt nach dem "Auftauen":

Letzte Angabe ist optional. Prozesse die uns nichts anzugehen haben, dürfen Sie gerne unkenntlich machen.

Wir bedanken uns an dieser Stelle für Ihre Mithilfe die vServer weiter hinsichtlich Stabilität zu optimieren.

Vielen Dank!

Zitat von [netcup] Felix;16773

Da hier vermehrt von einem "einfrieren" gesprochen wird, haben wir dieses versucht letzte Nacht nachzuvollziehen. Wir haben kleine vServer aufgesetzt und diese mit gängiger Software ausgestattet. Leider ist dieses "Einfrieren" nicht bei uns aufgetreten.

Heute ist es mir noch nicht aufgefallen. Mir kam da aber ein Verdacht: Könnte es an einer ziemlich stark belegten HDD (vom vServer) liegen? Denn gestern, als ich die Probleme erstmals beobachten konnte, war die HDD zu 80% belegt, da ich diverse temporäre Backupdateien und MySQL Files rumliegen hatte. Diese hatte ich am Ende des gestrigen Tages dann gelöscht und siehe da, keine Probleme mehr heute.

Ich werde das Problem auf jeden Fall noch weiter beobachten und mich melden, falls es nochmals so extrem auftritt.

MfG Christian

Eventuell liegt es an zu wenigen Inodes. Diese setzen wir nach einer Support-Mail kostenlos hoch.

Zitat von dani4u;16846

Bei "richte rsync ein" blieb er stehen, und nach einer halben stunde kaffee schlürfen und warten.... hab ichs mit STRG+C abgebrochen.

Wurden Tastatureingaben noch angenommen und angezeigt? Wenn Nein, ist vllt. nur die Verbindung unterbrochen worden und apt (?) lief noch weiter. Du könntest dir das Log von apt einmal ansehen, sofern du apt-get oder aptitude verwendet hast.

MfG Christian

Oh, sorry. Ich hätte genauer lesen sollen. Tut mir Leid!

MfG Christian

Zitat von dani4u;16849

ps: weisst du vllt ein schlüsselwort, nachdem ich googeln kann, dass die umlaute funktionieren?

Putty? Window => Translation und dort UTF-8 einstellen.

Endlich wieder nen Kernelupdate.
Kam eben per Mail:

Zitat

wir haben die Software auf dem Node Ihres vServers weiter optimiert. Es gab seit dem neuem Kernel vereinzelt Beschwerden, dass vServer seit dem neuen Kernel an Performance verloren hätten. Dieses war besonders dann der Fall, wenn ein vServer den gebuchten RAM verbraucht hatte und auf den SWAP zugreifen musste. Die Aktualisierung optimiert die Zugriffe auf den SWAP / Flexi-RAM, um die Performance zu erhöhen.

Damit die neuen Änderungen wirksam werden, müssen alle vServer auf dem Node neu gestartet werden.

Auf dem von Ihnen genutzten Node wurde folgender Termin für den Neustart festgelegt:

15.04.2010 ca. 22:15 Uhr.

Ihr vServer wird zu dem Termin herunter gefahren und anschließend neu gestartet. Wir rechnen mit einem dadurch verbundenen Ausfall vom ca. 10 Minuten.

Alles anzeigen