• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

SSF Server eingefroren

Thorsten

SSF Facilitymanagement
Staff member
Hallo!
Heute, am 23. Juli ist gegen 19:30 etwas sehr merkwürdiges passiert. Ich habe versucht auf das Forum zuzugreifen. Seite lädt und lädt. Anmeldung per SSH - extrem langsam. Vom Starten der session bis zur Eingabe des Benutzernamens vergingen circa 5 Minuten.
Rebootversuch über das Strato-Admininterface. Nach 20 Minuten keine Reaktion.
Anruf beim Strato Support. Versuch eines reboots durch den Techniker. Kein Erfolg. Einzige Möglichkeit Stromabschaltung. Nach weiteren 20 Minuten kam der Server wieder hoch. Ich hatte mich schon von sämtlichen aktuellen Daten verabschiedet - aber siehe da, auf den ersten Blick noch alles vorhanden.
Ich habe mir danach mal die Logfiles angesehen. Bis auf eine Sache nichts auffälliges. In /var/log/warn steht
Code:
process /usr/lib/postfix/pickup pid 14926 exit status 1
Jul 23 19:10:12 h1632 kernel: VM: killing process httpd2
Jul 23 19:10:12 h1632 kernel: VM: killing process httpd2
Jul 23 19:10:12 h1632 kernel: VM: killing process mysqld
Jul 23 19:10:23 h1632 postfix/master[11623]: warning: process /usr/lib/postfix/qmgr pid 11627 killed by signal 9
Jul 23 19:10:58 h1632 kernel: VM: killing process httpd2
Jul 23 19:11:02 h1632 kernel: VM: killing process qmgr
Jul 23 19:11:02 h1632 kernel: VM: killing process cron
Jul 23 19:11:02 h1632 kernel: VM: killing process httpd2
Jul 23 19:11:35 h1632 kernel: VM: killing process confixx_counter
Jul 23 19:14:05 h1632 postfix/pickup[19874]: fatal: watchdog timeout
Jul 23 19:15:50 h1632 kernel: VM: killing process httpd2
Jul 23 19:15:50 h1632 kernel: VM: killing process mrtg
Jul 23 19:16:23 h1632 kernel: VM: killing process httpd2
Jul 23 19:16:25 h1632 kernel: VM: killing process vnstat
Jul 23 19:16:25 h1632 kernel: VM: killing process httpd2
Wie habe ich die kernel VM Meldungen zu deuten?

Die Datenbanken sind nun aktuell - Stand vor diesem Artikel - gesichert.
Morgen soll im Laufe des Tages ein Hardwarecheck durch einen Stratotechniker erfolgen. Das nur als Vorwarnung, falls das Forum morgen nicht erreichbar ist.

mfG
Thorsten
 
Thorsten said:
Wie habe ich die kernel VM Meldungen zu deuten?
VM == Virtualmemory-Manager
Der Speicher war voll!
Der VM kann aber nicht zwischen wichtigen weniger wichtigen oder dauerlauf-Prozessen unterscheiden. Daher beendet er ein Prozess nach dem anderen, bis es den richtigen gefunden hat.
Falls Du keine weitere Einträge über seltsame Fehler in der messages oder warn hast, dann wirst Du nie erfahren, welcher Prozess der Ausschlaggebende war.
Es bleibt nur 'raten', welcher Prozess nicht beendet wurde... mysql? xinetd? webmin? confixx? ;)

PS:
Es hat, soweit ich das weiß, nichts mit einem Hardware-Fehler zu tun.

huschi.
 
Hallo!
Habe nun nochmals etwas intensiver gesucht.
Die erste(n) Meldung(en) die ich finden konnte:
Code:
Jul 23 19:11:02 h1632 last message repeated 2 times
Jul 23 19:11:02 h1632 kernel: VM: killing process qmgr
Jul 23 19:11:02 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:11:02 h1632 kernel: VM: killing process cron
Jul 23 19:11:02 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:11:02 h1632 last message repeated 3 times
Jul 23 19:11:02 h1632 kernel: VM: killing process httpd2
Jul 23 19:11:22 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:11:35 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:11:35 h1632 kernel: VM: killing process confixx_counter
Jul 23 19:14:20 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:15:50 h1632 last message repeated 7 times
Jul 23 19:15:50 h1632 kernel: VM: killing process httpd2
Jul 23 19:15:50 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:15:50 h1632 kernel: VM: killing process mrtg
Jul 23 19:15:50 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:16:23 h1632 last message repeated 2 times
Jul 23 19:16:23 h1632 kernel: VM: killing process httpd2
Jul 23 19:16:23 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0xf0/0)
Jul 23 19:16:25 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:16:25 h1632 kernel: VM: killing process vnstat
Jul 23 19:16:25 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:16:25 h1632 kernel: VM: killing process httpd2
Jul 23 19:23:25 h1632 sshd[20361]: fatal: Timeout before authentication for ::ffff:80.185.238.36
Jul 23 19:39:53 h1632 -- MARK --
Jul 23 19:39:54 h1632 init: Switching to runlevel: 6
Jul 23 19:40:07 h1632 sshd[20903]: fatal: Timeout before authentication for ::ffff:80.185.238.36
Jul 23 19:42:59 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:45:54 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:45:54 h1632 kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)
Jul 23 19:58:04 h1632 syslogd 1.4.1: restart.
Jul 23 19:58:05 h1632 saslauthd[639]: detach_tty      : master pid is: 639
Jul 23 19:58:05 h1632 saslauthd[639]: ipc_init        : listening on socket: /var/run/sasl2//mux
Sieht für mich aber auch mehr nach 'Folgefehler' und weniger nach Auslöser aus.

mfG
Thorsten
 
Hallo Timdubi!
Also die 'Lösung' des Problems war damals ein reboot und die Überprüfung der Hardware durch die Strato-Technik.
Ich weiss allerdings nicht, ob Hardware getauscht wurde. Der Fehler kam seidem nicht mehr vor.

mfG
Thorsten
 
Ahhh - die liebe Hardware!

Hallo Thorsten,
tja, wenn die Maschine in der letzen Zeit eins mitgemacht hat, dann warens Reboots ;)

Mein Kiste steht bei Hetzner - und da ansich auch nichts an der Konfiguration verändert wurde, bin ich auch schon davon ausgegangen, dass es evtl. an der Hardware liegen könnte. Die Hetzner Leute meinten allerdings, dass die Hinweise in /var/log/Messages nicht unbedingt darauf hin deuten würden.

Muss ich hier nochmal ein Hebel ansetzen.

Vielen Dank,
das war ein wichtiger Hinweis,

Gruß,
Tim
 
Wobei du auch nochmal ein Auge auf den zur Verfügung stehenden Speicher richten solltest. Wenn mehr RAM benötigt wird als vorhanden nützt der beste memory manager nichts. Was hast du denn für eine Konfiguration? Wie sieht die Speicherauslastung aus?

mfG
Thorsten
 
Naja, in der Kiste steckt ein GB an RAM und Speicherauslastung liegt ansich im grünen Bereich. TOP zeigt z.B. nur bei dieser Domainanlageaktion in Visas fast 100% Systemauslastung - dann geht natürlich nichts mehr. Schaust Du dann in die Messages, findest sich der dezente Eintrag "Sep 16 15:23:03 linux kernel: VM: killing process useradd" dort. Das ganze dauert dann etwa 5 min. bis sich alles wieder gefangen hat und es kann weitergehen. Wenn sich das ganze allerdings mehrfach wiederholt, kommen schon mal mehr "killing process" dran (also nicht nur useradd, sondern auch visasd und andere) - und dann hilft auch nur noch ein Reboot.

tim
 
Hast du dir schon mal Gedanken darüber gemacht dich von ViSAS zu trennen? :)

mfG
Thorsten
 
Also bisher hat alles wunderbar geklappt - das System ist ausserdem eines der "bedienbarten" die ich kenne. Ich hab galub ich auch schon alle wichtgen durch, wie Sie auch alle heißen mögen - visas ist Funktionell klasse. Ausserdem gibts seit geraumer Zeit auch wieder Support. Die Schluffis sind scheinbar gegangen und es namen Profis dort Platz. Wie ansonsten würdest Du es interpretieren, dass ich gerade ein Angebot erhalten habe, das die Junx selbst amal auf meiner Kiste nach dem Rechten sehen - wenn das kein Support ist, was dann?

Ausserdem kannst ja tatsächlich auch ein Hardware-Defekt sein. Daum kümmert sich Hetzners Leute - auch Profis.

Was hast Du denn drauf, auf Deiner Maschine?
 
Also ich kenne ViSAS nur unter Führung der alten Mannschaft. Und da gab es doch den ein oder anderen Engpass beim Support. Besonders gestört haben mich Sachen wie die Manipulation von suExec.
Wenn sich der Support verbessert hat, ist das gut. An sich ist ViSAS ja kein schlechtes Produkt. Es waren - wie bereits erwähnt - mehr die äußeren Umstände.
Ich setzte momentan Confixx 3.0.4 auf einem Strato Server ein. Meiner Meinung nach einfach das kleinere Übel.

mfG
Thorsten
 
Wie siehts denn mit Strato aus? Was im Visas Umfeld mit Support mißlang, dass kann man doch eigentlich auch bei Strato weiterlesen. Erreichbarkeit hin und her - der Support was Visas anbelngt ist z.Z. Spitze. Was sagt Strato dazu? Bist Du zufrieden? Wie lange hast Du den Account schon und wenn ich fragen darf, wielviele Accounts laufen drauf?
Die Preise sind ja unschlagbar.

Gruß,
Tim
 
Zum Thema Strato:
Über den technischen Support kann ich nicht all zuviel berichten. Den Server habe ich jetzt knapp ein Jahr. Ich hatte circa 3 bis 4 mal Kontakt mit dem Support. Darunter war ein dringendes Problem (Server eingefroren :)) und ein Ausfall im Rechenzentrum. Mein Eindruck ist der, dass es scheinbar keine Callcenter Mitarbeiter sind. Das technische Verständnis ist auf der Gegenseite vorhanden.
Strato's Ruf hat in der Vergangenheit wohl erheblich gelitten. Ich kann das so nicht bestätigen. Wahrscheinlich würde sich das bei häufig auftretenden Fehlern allerdings ändern. Ist aber ein Anbieterunabhängiges Problem - welcher zufriedene Kunde beschwert sich schon.

Zum den Preisen:

Klar Strato, Server4You, Netdirect & Hetzner liefern sich direkte Preiskämpfe. Irgenwann wird es in diesem Segment wahrscheinlich einen (guten) Rootserver für 9,99 € geben. Der Anbieter bringt was der Markt verlangt.
Auf der anderen Seite macht man sich - bei wachsenden Projekten - schon Gedanken über ein 'Was wäre wenn..' Szenario. Dann kommen Anbieter wie Schlund+Partner, Plusserver oder Hosteurope ins Spiel. Nur, ob der höhere Preis dann auch im Falle eines Ausfalls gerechtfertigt ist, weisst du erst, wenn du diesen Fall erlebt hast. Mir ist kein Provider bekannt, bei dem ich Backup und Recovery testen kann. Schade eigentlich.

Zu den Confixx-Accounts:
Hier läuft eigentlich nur das Forum und ein paar mirror Seiten. Alles andere (zwei, drei statische Homepages) ist belastungstechnisch zu Vernachlässigen.

mfG
Thorsten
 
Auf der anderen Seite macht man sich - bei wachsenden Projekten - schon Gedanken über ein 'Was wäre wenn..' Szenario.

Ja, genau, managed services oder Admin-Support sind ne schöne Sache - nur eben nicht kalkulierbar. Die Investition in einen zusätzlichen Mitarbeiter bringt auch nichts, wenn der Server nicht gerade im eigenen Büro steht und an einer T3 Leitung hängt. Dann wäre uns Sache mit den Euronen aber ohnhin gleich ...

Managend Server sind auch nicht das richtige, da i.d.R. kein root-Zugriff mehr möglich ist - und den hätte ich schon ganz gern.

Tja, womit man wieder beim Anfang wäre. Aber ich muss da einen Weg finden - auch wegen dem ruhigen Schlaf. So langsam sind einiges an kritischen Anwendungen auf der Maschine aktiv und ich möchte davor schützen mit einem System zu arbeiten, dass in eben diese Situation wie gerade jetzt verfällt. Fragt sich eben nur wie.

Tim
 
Es müsste nicht einmal managed sein. Folgende Konfiguration würde mich persönlich besser schlafen lassen:
  • PIV um die 2GHz / Kein Celeron
  • 1 GB RAM
  • 120 GB Harddisk (Nutzkapazität) 2 x 60 GB SCSI
  • Tägliches Full-Backup (ideal extern (außerhalb des eigenen Servers))
  • 150-200 GByte inklusiv Traffic bzw. sehr gutes Preis/GB Verhältnis
  • Gute Verfügbarkeit der Anbindung
  • Garantierte Wiederherstellung der Hardware (in Stunden)
  • Möglichkeit zur Aufrüstung der Hardware
Eigentlich ist das gar kein so großer Aufwand. Nur die Preise dafür befinden sich bei einigen Anbietern im illusorischen Bereich. Vielleicht überzeugt mich aber der ein oder andere Anbieter ;) .

mfG
Thorsten
 
Ja, sowas wünscht man sich zu Weihnachten - dann kann man nämlich auch mal Urlaub machen :D

Naja, vielleicht ereilt uns ja dieser Wunsch früher als wir denken - es lebe der Preiskamp (Hauptsache die Qualität bleibt nicht auf der Strecke).

Gruß,
Tim
 
Back
Top