Kniffeliges Problem, Server hat viele Aussetzer

[Phila]

Hallo liebes Forum,
ich habe mir einen Server auf einem Cloudhost "ElasticHosts" zugelegt. Der lief nun gut 1,5 Jahre ohne Probleme. Heute abend gingen allerdings die Probleme los und ich glaube schon eine Richtung zu haben, bin mir aber nicht sicher.

Brauche dringend Hilfe. Bin auch bereit per PM oder telefonisch das ganz zu klären. Wer Interesse hat, bitte melden. Ich stehe mit den Rücken zur Wand:

Server hat Starke Aussetzer, manchmal gehen 40 Pings nicht durch (am Stück) dann wieder 40 Pings gehen durch usw...

Erst dachte ich an DOS. Habe aber kurz in einer Lücke mir ein paar Logs laden können:

Folgender Block taucht ständig auf:

May 31 22:55:26 shared kernel: [  160.088130] hda: dma_timer_expiry: dma status == 0x21
May 31 22:55:46 shared kernel: [  180.360255] hda: dma_timer_expiry: dma status == 0x21
May 31 22:55:56 shared kernel: [  190.360124] hda: DMA timeout error
May 31 22:55:56 shared kernel: [  190.364081] hda: dma timeout error: status=0xd8 { Busy }
May 31 22:55:56 shared kernel: [  190.364081] ide: failed opcode was: unknown
May 31 22:55:56 shared kernel: [  190.364081] hda: DMA disabled
May 31 22:55:56 shared kernel: [  190.408194] ide0: reset: success
May 31 22:56:53 shared kernel: [  247.840079] hda: dma_timer_expiry: dma status == 0x21
May 31 22:57:07 shared kernel: [  257.840142] hda: DMA timeout error
May 31 22:57:07 shared kernel: [  257.844092] hda: dma timeout error: status=0xd8 { Busy }
May 31 22:57:07 shared kernel: [  257.844092] ide: failed opcode was: unknown
May 31 22:57:07 shared kernel: [  257.844092] hda: DMA disabled
May 31 22:57:07 shared kernel: [  261.524322] ide0: reset: success

Laut Google scheint das auf ein Festplattenproblem (Hardware) zu zielen was ja allein schon die Fehlermeldung sofort nahelegt, allerdings ist das System ja in einer Cloud. Das macht mich ratlos.

Eine Idee von mir: Ich hatte die Festplatte vor ca. 5 Monaten vergrößert und mit

resize2fs -p /dev/sda

die Partition "hineinwachsen" lassen. hier bekam ich dann nach ca. 60% einen Fehler. Aber die Partition war größer, wenn auch nicht die volle Größe. Ist da was schief gelaufen? Klar, bloß was? Und hängt es mit meinem aktuellen problem zusammen.

Habe die Fehlermeldung von damals natürlich nicht mehr...
Hat jemand eine Ahnung? Was braucht Ihr noch für Angaben.

Es handelt sich um ein Debian 5.0.8 System.
4GB RAM die nicht annähernd ausgelastet sind. Prozessorlast ist auch zwischen 4% und 12%.
Die Netzwerkaussetzer/Erreichbarkeitsaussetzer müssen woanders liegen...

Viele Grüße


Philip

 

[strowi]

hi,

sieht stark nach nem Hardware-Defekt aus. Vermutlich machts der Festplatten-Controller nicht mehr lange... Am besten sofort (bzw. natürlich vorgestern) ein backup machen und austauschen.

 

[PapaBaer]

DMA-Error ist Hardware. Festplatte oder Controller futsch. Das hat mit dem Dateisystem nix zu tun. Heute wird auch alles und nix Cloud genannt. Das ist oft genug nur etwas vServer, wo die VMs dynamisch über mehrere Hosts geschoben werden (oft genug nicht mal das).

 

[Phila]

Das Problem ist, dass es sich um ein "Cloud"-System handelt. Das liegt komplett virtuell auf einer Hardwareschicht bestehend aus vielen Rechnern...

Ich habe jetzt mal eine Supportmail geschcickt, warte aber noch auf Antwort...
Alles was ich bei Google finden kann ist Hardware bezogen. Aber wie kann das in einer Cloudumgebung sein? Ich vermute ganz stark einen anderen Hintergrund mit diesem Symptom als Nebeneffekt...

 

[d4f]

Das liegt komplett virtuell auf einer Hardwareschicht bestehend aus vielen Rechnern...

Wie bereits PapaBaer beschrieb ist dies eben meist wie es zwar vom Kunden wahrgenommen wird, aber NICHT wie es realisiert ist.
Aus Leistungsgruenden wird alles ausser shared-Speicher (zB bei Amazon der S2) auf eine lokale Instanz kopiert welche dann _ausschliesslich_ auf eben dieser Instanz liegen.
Wie ebenfalls von PapaBaer beschrieben, gibt es einige (insbesonders deutsche/deutschsprachige) Hoster welche unter Cloud nichts anders als ein vServer mit Upgrade- und manchmal Downgrade-Moeglichkeit verstehen; also ein 0815 vServer mit neumodischem Marketing-Begriff.

Es kann an einem Hardware-Defekt auf dem Host liegen, meist ist aber entweder die Containerdatei der Festplatte korrupt (mit qcow2 hatte ich bereits ein solches Problem) oder die I/O Auslastung auf dem Host liegt zu hoch.
Da der paravirtualisierte DomU nicht direkt mit den Datentraeger des Hosts sondern mit einer virtuellen Festplatte redet welche bei den oben genannten Probleme einige Zeit zum antworten braucht kann es sein dass der DomU von einem Speicherfehler ausgeht.