Hallo, > > > > Dazu noch eine kleine Erläuterung: > > Ich habe 3 Haupt-HDs. Auf jeder Platte befinden sich rd. 7GB Swap, eine > > Partition für RAID5 (root) und eine weitere Partition für RAID5, die > > zusammen ein PV bilden. > > Zusätzlich gibt es nich ein weiteres Array mit 2 Platten (auch Level 5, > > damit ich's ggf leicht erweitern kann), die das zusammen als statische > > Partition das Backup zur Verfügung stellen. Auf den Backup Platten ist > > KEIN Swap vorgesehen. Es gibt noch eine kleine IDE Platte aus alten > > Zeiten, die auch noch ein GB Swap oder so hat. > > Wie arbeitest du auf dem Raid5 weiter? LVM und dann die LV's als > Blockdevice an die domU's weiter reichen? Oder Machst du immagedateien für > die domU's? Wie sich Raid5 von der Perfomance verhält kann ich nicht > sagen. damit habe ich keine Erfahrung. Momentan ist es so, dass ich im RAID ein großes md Device als PV einsetze, auf dem einige LVs sitzen, die für die Dom0 zur Verfügung stehen. Bisher war das ja ohne XEN und daher ist die Ordnerstruktur so entstanden. Die DomUs bekommen ihr root-fs von image Dateien, da werde ich aber ggf noch mal was ändern. Ist aber (denke ich) nicht extrem problematisch, da die "Arbeits-Devices" wie /home direkt in eine DomU geführt wird. Danach gehts per NFS weiter auf die anderen DomUs (Gibt's da was besseres? FS: Ext4). > Eine Lösung mit der ich seit Jahren gut fahre ist die (stark > zusammengefasst): - Keine dienste auf der dom0. Alles in domu's Wie steht's mit postfix & Co? Wie machst du das mit der USB Hardware (ich habe einen USB Drucker)? > - von allen Platten die ich habe, kommen zwei Gleich große in die ersten > beiden Slots, der Rest dahinter. > - auf den ersten beiden Platten kommt ein Raid1 mit vielleicht 20GB für die > Dom0. Der rest wird für LVM partitioniert. > - Je nachdem wieviel Plattenplatz wofür man braucht, kann man die LVM > Partitionen zu einem großen PV zusammen fassen oder eben unterteilen. > - Die einzelnen LV's als Blockdevice direckt an die DomU weiter geben. Das > ist auf jeden Fall performanter als ein Immage. > > > Ich weiß, dass eine der beiden Backup Platten nicht mehr richtig mag. Sie > > ist mal zu heiß geworden und zeigt seither im SMART einen Fehler. Daher > > wäre meine Vermutung dass es genau diese Platte ist, die Probleme macht. > > Wenn du diese Platte weg lassen kannst dann tu das mal und schau wie sich > das System dann verhält. Ich werde mal das Backup deaktivieren. Ich vermute aber, dass es nicht das Problem ist. Werde es nacher mal auf einen weiteren Neustart ankommen lassen... > > > Wenn ich das richtig verstehe, müsste doch dann aber die anderen Platten > > trotzdem laufen, oder nicht? Der Swap wäer weiterhin erreichbar. > > Jain. wenn das System zuerst auf eine Platte swappen will die gerade > schlechte Performance auf weist, dann kann es schon sein das sich alles > verhäddert. IO ist nunmal ein übler Lasterzeuger und wenn es Prozesse gibt > die Speicher allocieren wolle, hinten drann aber gerade das Swappen harkt, > dann kommt das System schnell ins stocken. > > > Gibt es eine Möglichkeit, nachzuweisen, dass das das Problem ist? > > Was kann ich dagegen machen? > > Indirekt. Wenn du eine Platte her nimmst, von der du weißt das sie ok ist, > und diese nur zum Swappen benutzt und alle anderen Swappartitionen weg > lässt, dann sollte Swappen kein Problem mehr sein. Aber auch hier muss man > auf passen. Wenn z.B. so viele Prozesse auch IO warten, das alle CPU Kerne > damit beschäftigt sind, dann muss u.U. auch das Swappen warten und es geht > wieder alles in die Knie. Müsste ich erst eine neue einbauen. > > > PS: Was bedeutet, "das der RAM ausgeht"? Wie ist das mit dem Cache? Kann > > der nicht genutzt werden? Laut atop war noch ein oder zwei Minuten vor > > dem Crash 400MB Cache frei und Er hat auch keine HD aktivitäten davor > > (1-2% höchstens). Da müsste also schon einiges kommen, dass das sich so > > schnell hochschaukelt. > > Der Cache ist für Platten IO. Der wird nach bedarf frei gemacht und auf die > Platte geschrieben. Kann aber nicht, oder nicht so schnell auf die Platte > geschrieben werden, dann verschwindet der Cach auch nicht. > Könnte ein Indiz darauf sein das was mit den Platten nicht stimmt. > > Konntest du im Fehlerfall den dmesg aufrufen? was hat der gezeigt? Im dmesg stand nichts neues. Die letzten Meldungen waren noch vom Systemstart. Syslog und free: http://paste.debian.net/14562/ und http://paste.debian.net/14563/ nach dem "Crash" vor dem Neustart. Ich habe den php Dienst auch gleich noch deaktiviert (hatte ich vergessen beim Umzug in die DomUs) > > > Kann das mit XEN zu tun haben? Ich habe wie gesagt bisher immer auf bare > > Hardware gearbeitet und nie derartige Probleme gehabt. > > Glaub ich nicht. Von allen Virtualisierungen finde ich Xen die > performanteste. (subjektiver Eindruck). > Ich denke eher das hier eine Fehlerhafte Platte alles in den Tod reißt. > Zumindest weisen für mich die indizien darauf hin die du genannt hast. > > Wie viele CPU's weißt du den DomU's zu? Bisher haben alle DomUs eine VCPU. > Kannst du im Fehlerfall noch xm top aufrufen? > Wenn ja, was zieht die meiste CPU-Last? Beim nächsten Crash werde ich es machen. Ich habe jetzt beim letzten Crash die Meldung bekommen, dass der wartende Task xenwatch war. Ich könnte das Programm mal deinstallieren, aber das ist ja nicht Sinn der Sache, oder? Christian
Attachment:
signature.asc
Description: This is a digitally signed message part.