I/O wait sehr hoch, Server praktisch unbenutzbar

[roi]

Hallo zusammen,

habe hier ein seltsames Problem auf einem Hetzner EQ4 Server (i7, 8 GB RAM, 750 GB Software RAID1).

Starte ich einen simplen chown auf ein Verzeichnis oder entpacke ein Tarball, schnellt der I/O Wait massivst in die Hoehe, liegt laut "top" dann bei 30-70%. Der Server wird dann praktisch unbenutzbar, Webseiten brauchen mehrere Sekunden zum laden, auch auf der Console geht praktisch nichts mehr.

Habe mal ein iostat gemacht, siehe unten.

Der Server laeuft auf Debian amd64 mit dem Kernel linux-image-2.6.32-5-amd64 2.6.32-21, die Installation habe ich mit dem "installimage" von Hetzner aus dem Rescuesystem gemacht. Die beiden 750 GB Platten sind ein Software RAID1. Ausser einer 8 GB Swap gibt es nur noch eine Partition, wo der Rest liegt.

Gerne liefere ich weitere Informationen.

Hat jemand eine Idee, was die Ursache sein koennte bzw wo ich weiterforschen koennte?

Danke und Gruss,
Martin

Code: Select all

servername:/home/roi# iostat -x 3 10

Linux 2.6.32-5-amd64 (servername)    08/30/2010      _x86_64_

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.70    0.33    0.52   20.18    0.00   78.28

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda              17.56   604.80   25.92  156.84  4452.21  6095.08    57.71     0.90    4.90   2.08  38.05
sda1              3.78    23.44    1.71    0.25    43.92   189.96   119.45     0.13   64.81  13.18   2.58
sda2             13.77   581.36   24.21  156.59  4408.28  5905.12    57.04     0.77    4.25   2.08  37.65
sdb               4.06   620.49    7.22  174.08   234.26 10310.92    58.17     6.12   33.71   2.17  39.29
sdb1              3.78    23.45    1.80    0.24    44.63   189.96   115.38     0.26  126.66  15.25   3.10
sdb2              0.28   597.04    5.42  173.84   189.63 10120.96    57.52     5.86   32.66   2.17  38.93
md0               0.00     0.00   11.07   23.73    88.55   189.81     8.00     0.00    0.00   0.00   0.00
md1               0.00     0.00   10.74  737.87   382.07  5902.93     8.40     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.10   29.49    0.00   70.41

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     2.00    0.00  366.33     0.00  2949.33     8.05   105.56  289.54   2.73 100.00
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     2.00    0.00  366.33     0.00  2949.33     8.05   105.56  289.54   2.73 100.00
sdb               0.00     5.00    0.00  357.33     0.00  2904.00     8.13   146.94  397.40   2.80 100.00
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00     5.00    0.00  357.33     0.00  2904.00     8.13   146.94  397.40   2.80 100.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00   30.40    0.00   69.60

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     1.67    0.00  291.67     0.00  2346.67     8.05    83.99  292.29   3.43 100.00
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     1.67    0.00  291.67     0.00  2346.67     8.05    83.99  292.29   3.43 100.00
sdb               0.00     3.67    0.00  281.00     0.00  2277.33     8.10   143.77  501.11   3.56 100.00
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00     3.67    0.00  281.00     0.00  2277.33     8.10   143.77  501.11   3.56 100.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.33     0.00     2.67     8.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.18   53.85    0.00   45.97

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     3.67    0.00  297.33     0.00  2408.00     8.10   118.29  395.45   3.36 100.00
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     3.67    0.00  297.33     0.00  2408.00     8.10   118.29  395.45   3.36 100.00
sdb               0.00     4.67    0.00  292.67     0.00  2376.00     8.12   149.21  510.98   3.42 100.00
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00     4.67    0.00  292.67     0.00  2376.00     8.12   149.21  510.98   3.42 100.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.08    0.00    0.66   26.51    0.00   72.74

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00  2717.67    0.00  366.00     0.00 24669.33    67.40    86.17  228.50   2.59  94.67
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00  2717.67    0.00  366.00     0.00 24669.33    67.40    86.17  228.50   2.59  94.67
sdb               0.00  2718.00    0.00  386.67     0.00 24842.67    64.25   114.01  313.40   2.45  94.80
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00  2718.00    0.00  386.67     0.00 24842.67    64.25   114.01  313.40   2.45  94.80
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00 3809.33     0.00 30474.67     8.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.08   25.08    0.00   74.83

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     4.00    0.00  368.33     0.00  2978.67     8.09   135.55  360.16   2.71 100.00
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     4.00    0.00  368.33     0.00  2978.67     8.09   135.55  360.16   2.71 100.00
sdb               0.00     3.67    0.00  369.67     0.00  2986.67     8.08   140.38  373.22   2.71 100.00
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00     3.67    0.00  369.67     0.00  2986.67     8.08   140.38  373.22   2.71 100.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.33     0.00     2.67     8.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.07    0.00    0.00   44.46    0.00   55.47

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     1.33    0.00  314.67     0.00  2525.33     8.03   146.40  447.89   3.18 100.00
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     1.33    0.00  314.67     0.00  2525.33     8.03   146.40  447.89   3.18 100.00
sdb               0.00     2.67    0.33  315.00     2.67  2536.00     8.05   135.53  434.85   3.17 100.00
sdb1              0.00     0.00    0.33    0.00     2.67     0.00     8.00     0.02   60.00  60.00   2.00
sdb2              0.00     2.67    0.00  315.00     0.00  2536.00     8.05   135.51  435.25   3.17 100.00
md0               0.00     0.00    0.33    0.00     2.67     0.00     8.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.68    0.00    2.03   31.14    0.00   66.15

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00  2716.67    0.00  311.67     0.00 24232.00    77.75    97.48  334.31   3.04  94.67
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00  2716.67    0.00  311.67     0.00 24232.00    77.75    97.48  334.31   3.04  94.67
sdb               0.00  2716.33    0.00  302.00     0.00 24149.33    79.96   116.28  373.48   3.25  98.27
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00  2716.33    0.00  302.00     0.00 24149.33    79.96   116.28  373.48   3.25  98.27
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00 3824.00     0.00 30592.00     8.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.08    0.00    0.08   24.05    0.00   75.80

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     4.00    0.67  310.33     5.33  2512.00     8.09   124.88  390.39   3.22 100.00
sda1              0.00     0.00    0.67    0.00     5.33     0.00     8.00     0.03   48.00  48.00   3.20
sda2              0.00     4.00    0.00  310.33     0.00  2512.00     8.09   124.84  391.12   3.22 100.00
sdb               0.00     4.33    0.33  321.33     2.67  2605.33     8.11   145.44  450.44   3.11 100.00
sdb1              0.00     0.00    0.33    0.00     2.67     0.00     8.00     0.02   68.00  68.00   2.27
sdb2              0.00     4.33    0.00  321.33     0.00  2605.33     8.11   145.42  450.83   3.11 100.00
md0               0.00     0.00    1.00    0.00     8.00     0.00     8.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00    0.33     0.00     2.67     8.00     0.00    0.00   0.00   0.00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.09   52.09    0.00   47.83

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     3.67    0.00  300.67     0.00  2429.33     8.08   135.81  441.12   3.33 100.00
sda1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00     3.67    0.00  300.67     0.00  2429.33     8.08   135.81  441.12   3.33 100.00
sdb               0.00     3.00    0.00  326.33     0.00  2634.67     8.07   122.59  417.01   3.06 100.00
sdb1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00     3.00    0.00  326.33     0.00  2634.67     8.07   122.59  417.01   3.06 100.00
md0               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
md1               0.00     0.00    0.00   25.67     0.00   205.33     8.00     0.00    0.00   0.00   0.00

[Joe User]

Das sieht sehr nach kaputtem Filesystem oder sterbender Harddisk aus.
Welches Filesystem? SMART-Werte?

BTW: fsck kann bei ~740GB sehr lange dauern, da ist eine Neuinstallation manchmal schneller erledigt.

[roi]

Hallo,

und danke schon einmal für die Antworten.

Der Server ist nagelneu (gut, natuerlich k.A. wie lange die Hardware bei Hetzner schon im Einsatz ist...) und erst am Donnerstag letzte Woche frisch aufgesetzt worden. Insofern waere es aergerlich, hier nochmal ran zu muessen.

Als Dateisystem wird ext3 verwendet mit folgenden Parametern: defaults,noatime,data=writeback,acl

Die Platten schauen laut smartctl gut aus, jede Platte wirft PASSED aus als Status.

mdadm erzaehlt mir folgendes:

Code: Select all

servername:/home/roi# mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90
  Creation Time : Thu Aug 26 08:51:59 2010
     Raid Level : raid1
     Array Size : 724177984 (690.63 GiB 741.56 GB)
  Used Dev Size : 724177984 (690.63 GiB 741.56 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Mon Aug 30 11:19:23 2010
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           UUID : 66a3dd0b:7018cd9b:776c2c25:004bd7b2
         Events : 0.42

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2

Sieht also eigentlich auch klasse aus, oder?

Speicherverbrauch:

Code: Select all

servername:/home/roi# top
top - 11:27:45 up 4 days,  1:37,  3 users,  load average: 1.01, 0.62, 0.27
Tasks: 131 total,   2 running, 129 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  0.5%sy,  0.3%ni, 78.7%id, 19.8%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   8191796k total,  2174580k used,  6017216k free,   187104k buffers
Swap:  8391928k total,   253236k used,  8138692k free,   949040k cached

Eigentlich auch nichts schlimmes.

Der I/O Wait Wert aber wieder auffaellig, gell? Momentan laeuft logcheck, siehe unten, sonst nur die ueblicherweise laufenden Dienste eines Webservers (Apache, MySQL und bissle Krimskrams). Der Server duempelt eigentlich vor sich hin, denn das Projekt, das drauf laeuft, ist noch nicht wirklich in Live-Betrieb.

Das syslog schaue ich eben durch, lasse mir das aber im Moment von logcheck filtern, da jede Menge iptables Meldungen hier auflaufen z.Zt...

Viele Gruesse,
Roi

[Joe User]

writeback? Also eher kaputtes Filesystem...
Wie matze schon schrieb ist ordered mit vernünftigem btree zu bevorzugen, insbesondere wenn noch Datenbanken darauf laufen. Besser wäre natürlich XFS statt EXT[234] ;)

[Joe User]

http://www.rootforum.org/wiki/Gentoo_Ha ... artitionen

[roi]

Hallo zusammen,

danke wieder fuer die Antworten. :-)

Bin nun hergegangen und habe writeback entfernt, auch ordered nehme ich (erstmal) nicht. Oder macht es Sinn, anstatt dem Standard fuer das Journal ordered zu nehmen auf heutigen Systemen? Die writeback-Geschichte ist noch aus Celeron-Rootserver-Zeiten. ;-)

Habe auch die anderen ext3-Optimierungen aus o.g. Link angewendet.

logcheck lief inzwischen durch und hat mir fuer den heuten Tag keinerlei spannenden Infos liefern koennen bezueglich Platten oder Filesystem. Schweigen im Walde.

Um auf Nummer Sicher zu gehen werde ich die Kiste asap in den Recovery Modus booten und einen check des Filesystems fahren. Wie lange dauert so etwas denn Pi mal Daumen bei so ner Groesse, 50GB belegt? Hab da keine Erfahrungen...

Ansonsten faellt mir nichts mehr ein warum das Problem sich so darstellt. Habt Ihr noch Ideen, weg von einem defekten Filesystem oder schwaechelnden Platten?

Danke und Gruss,
Roi

/EDIT: XFS waere natuerlich eine Idee, aber das artet natuerlich auch erst einmal in Arbeit aus. Serverneuinstallation naemlich... Deswegen steht das momentan nicht ganz oben auf der Wunschliste.

[Joe User]

Die Menge der Daten auf dem Filesystem hat keinen Einfluss auf die Dauer des fsck, lediglich die Grösse der Partition. Bei Deiner Partitionsgrösse würde ich eine gute Kanne Kaffee, sprich >1 Stunde, einrechnen ;)

[roi]

Hallo zusammen,

habe eben auf einem identischen Server mit identischer Konfiguration einen Check gemacht. War nach ~15 Minuten durch.

Morgen kann ich den Server neu starten, also in den Rescue Mode gehen. Werde mich danach melden bezueglich den Ergebnissen.

Falls es nicht daran liegt, wird es lustig. Mir faellt gar nichts ein, was da sonst sein koennte...

Viele Gruesse,
Roi

[roi]

Also wie es aussieht ist das Dateisystem clean:

Code: Select all

root@rescue ~ # e2fsck -f -p -D /dev/md1
/dev/md1: 1471485/45268992 files (0.5% non-contiguous), 27488003/181044496 blocks

Hm...

[roi]

Hallo zusammen,

ich muss diesen Thread nochmal aufwärmen, denn das Problem existiert immer noch. Und das auf 5 Servern, die wir bei Hetzner gemietet haben. Zwei EQ6, drei EQ4. Auf allen Kisten, die ansonsten sehr performant sind, ziehen Operationen (chown, entpacken Tarball, MySQL Operationen...), wo die Festplatten ins Spiel kommen, die Performance sowas von dermaßen runter, das ist unglaublich.

Alle Server sind ähnlich konfiguriert.

Entweder haben wir überall den gleichen Fehler gemacht oder es gibt ein grundsätzliches Problem mit diesen Kisten.

Hat jemand ähnliche Probleme oder ne Idee, wo ich gucken/tunen/ändern kann?

Danke und Gruß,
Martin

[ddm3ve]

Hi,

hast Du die Mountoptionen von damals gesetzt?
Stichwort ordered oder ggf. mal xfs statt ext3 verwendet?
Da ich das "gleiche" Blech bei Hetzner habe, ich konnte bisher solche Probleme nicht feststellen, allerdings sind dort meines Wissens keine Nearline SATA Platten verbaut, dies kann bei hoher Last durchaus Probleme bereiten. Die Platten erholen sich dann u.U. nur sehr langsam.

Wichtig wären hierbei eine Betrachtung / monitoring, wieviel IO auf der platte tatsächlich entsteht. Sofern eine Maschine "verzichtbar" ist und ausgelöst werden kann, immer beide Platten einzeln testen und nicht das Raid1. So lassen sich dann Engpässe z.B. bei einer Platte ermitteln.

[roi]

Danke für Deine Antwort.

Die SoftRAIDs sind auf allen Servern so gemountet:

/dev/md1 / ext3 defaults,noatime,acl 0 0

Bei zwei servern kommt noch usrquota,grpquota dazu. Da diese Geschichte aber alle Server betrifft, kann es nicht wirklich daran liegen.

Gibt's da Verbesserungspotential?

XFS fällt erstmal aus, dazu müsste ich ja jeden einzelnen Server neu machen... :-/ Und ja, es laufen alle 5 Maschinen im Livebetrieb, ein "Verzicht" ist mit großem Aufwand verbunden.

Ich bekomme folgendes, wenn ich hdparm -Tt /dev/sda (oder sdb) mache:

Code: Select all

top - 12:05:18 up 12 days, 11:51,  3 users,  load average: 2.55, 1.29, 0.76
Tasks: 307 total,   1 running, 305 sleeping,   0 stopped,   1 zombie
Cpu(s):  1.7%us,  3.2%sy,  0.0%ni, 51.0%id, 43.9%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:  12328792k total, 11823292k used,   505500k free,   988148k buffers
Swap: 12584892k total,    85688k used, 12499204k free,  5708324k cached

Der IOWait Wert pendelt zwischen 15 und 50%...

Den gleichen Effekt habe ich, wenn ich das System mit Lesezugriffen beschäftige, z.B. mit:

Code: Select all

find . -maxdepth 1 -mindepth 1 -print0 | xargs -0 -n1 du -ks | sort -rn | head -16 | cut -f2 | xargs -i du -hs {}

Dazu sind die hdparm Werte nicht wirklich der Brüller, verglichen mit nem Bekannten, der auch nen EQ4 hat. Da dieser kommt auf 9800/98 MB/sec.

Einer meiner EQ4:

Code: Select all

Timing cached reads:   14862 MB in  2.00 seconds = 7440.36 MB/sec
Timing buffered disk reads: 322 MB in  3.01 seconds = 107.11 MB/sec

Einer meiner EQ6:

Code: Select all

Timing cached reads:   13732 MB in  2.00 seconds = 6872.79 MB/sec
Timing buffered disk reads: 300 MB in  3.00 seconds =  99.94 MB/sec

Im EQ4 sind zwei Samsung HD753LJ drinnen, im EQ6 zwei Seagate ST31500341AS.

Viele Grüße,
Martin

[ddm3ve]

Das Bild zeigt sich auf allen Maschinen?

Welches Os setzt Du ein und welches exakte Release?

Mit obiger Mountoption, solltest Du ebenfalls 100MB /sec schreibend erreichen.

Kann mir nur vorstellen, dass es hoher IOPs liegt.

[roi]

Das Bild zeigt sich auf allen 5 Maschinen.

Auf allen Kisten läuft Debian amd64 5.0.6 bis 6.0, Kernel zwischen 2.6.32-5-amd64 und 3.0.0-1-amd64. Wir setzen, wo wir es brauchen / haben möchten, neuere unstable-Pakete ein, der Rest läuft auf stable. Da sich das Bild aber auf allen Servern zeigt, wird es ja nicht unbedingt an einer bestimmten Version eines Kernels oder eines installierten Pakets liegen können, oder?

[ddm3ve]

Naja, ich arbeite an so einer Stelle gerne an enem auschlussverfahren, Du hast unterschiedliche Systeme HW und auch unterschiedliche Software. Mir stellt sich die Frage, ob sich auch die ext3 libs entsprechend unterscheiden oder ob man hier ggf. einen gemeinsamen Nenner findet.

Aus effizienzgründen würde ich bei so einer grossen platte ohnehin nicht mehr auf ext3. setzen. Hier im forum wurde das schon mal diskutiert, wieviel verschnitt ein ext3 mit sich bringt und wieviel Nutzbarer Platz damit verloren geht.

[roi]

e2fslibs liegt in verschiedenen Versionen auf den Servern:

1.41.12-2
1.41.12-4stable1
1.41.3-1

Du empfielst wie viele anderen hier also auch XFS, richtig? Ich habe noch nicht gesucht und geguckt, aber gibt es eine Möglichkeit, eine bestehende ext3 Partition mit den Daten über das Rescue System in XFS zu konvertieren und das System so nicht neu machen zu müssen bzw ein Backup zurückzuspielen. Wäre ja beides deutlich aufwändiger. Dass für so etwas vorher ein aktuelles Backup vorliegen sollte, ist ja klar. ;-)

[ddm3ve]

Grundsätzlich ja,

hängt nun davon ab, wie Du die Partitionen aufgebaut hast.
Ist es eine "typische" Installation mit getrennter
/boot,
Swap und
/ Partition,

dann reicht es ja schon, ein Backup der Rootpartition zu erstellen, im rescue System das FS zu löschen 7 neu zu erstellen und später noch die /etc/fstab (auf der Rootpartition) an zu passen.

Im anderen Fall wirds ggf. etwas kompklizierter da hier der Bootloader ggf. neu installiert werden müsste.

Joe User, kann dir das sicherlich besser erklären, wie Du beim packen und wieder einspielen des Backus vorgehen solltest, damit hinterher auch alle Rechte wieder passen.

[roi]

Habe nur eine große Partition, in der sich alles befindet, plus natürlich eine Swap Partition.

Wenn ich das hier lese, dann scheint das nicht so schwierig zu sein:

http://buffalo.nas-central.org/wiki/Usi ... e_boost%29

[roi]

Ach ja, warum eigentlich XFS und nicht ext4?

[ddm3ve]

Man kann sich sicherlich ausgiebig "streiten".

Ich halte ext4 ebenfalls als gutes Performantes FS.
MKeine bisherige Erfahrung ext vs. xfs war, dass mir zwar öfters das XFS um die Ohren flog, ich aber immer in der Lage war, xfs wieder zu reparieren. In 2 Fällen in denen mir ext um die Ohren geflogen ist, war eine Rettung nicht merh möglich und die Daten "unwiederbringlich" verloren. Dafür hat man aber dann ein Backup.

Bei mehreren Kunden, die auf grosse Datenmengen und stabilen Betrieb auf Linux setzen, wird seit jeher auf xfs gesetzt, die Erfahrungen waren trotz marodem Blech, sehr gut.
Es wird sicherlich jemand geben, der auch min. gleich gute Erfahrung mit ext4 gemacht hat. Auch ich bin bisher mit ext4 FS gut gefahren hatte selbst Jahrelang auf ext3 gesetzt.

[roi]

Ich übertrage grad mal aktuelle Vollbackups von einem der Server auf einen der anderen (um im Falle eines Problems schneller reagieren zu können). Dann werde ich heute abend entweder ext4 oder XFS ausprobieren. Ohne Neuinstallation... Bin ja mal gespannt.

Habe testweise mal acl rausgenommen bei den mount Optionen in der fstab und die betreffende Kiste neu gestartet. Hat nix geholfen. Dieser find/du Befehl erzeugt direkt mal wieder 30% iowait. Unfassbar... :-/

[Joe User]

Fullbackup anlegen (im Rescuesystem):

Code: Select all

cd /mnt/old && tar -cvSp --atime-preserve --numeric-owner --exclude=/{dev,proc,sys}/* -f /backup.tar .

Backup zurückspielen (im Rescuesystem):

Code: Select all

cd /mnt/new && tar -xvSp --atime-preserve --numeric-owner -f /backup.tar -C /mnt/new/

Der Pfad zum backup.tar muss natürlich auf einen ausreichend grossen Speicherplatz zeigen. Sollte lokal nicht genug Speicherplatz vorhanden sein, kann man das backup.tar auch per SSH remote anlegen:

Code: Select all

cd /mnt/old && tar -cvSp --atime-preserve --numeric-owner --exclude=/{dev,proc,sys}/* -f - . | ssh root@remote "( - > /backup.tar )"

BTW: noatime als Mountoption kann die I/O durchaus senken, hat aber auch Nebenwirkungen, also erst prüfen.

[roi]

Hallo zusammen,

danke für die Hilfe, auch Dir Joe für die tar Befehle.

Habe einen der Server inzwischen von ext3 auf ext4 umgestellt und kann sagen, dass dieser Server einen massiven Sprung nach vorne gemacht hat was die Performance des Filesystems anbelangt. Dadurch fällt es auch nicht mehr so sehr ins Gewicht bzw fällt nicht auf, wenn IOWAIT mal kurz nach oben geht, aber nicht minutenlang oben bleibt.

Würde also vermuten, dass ext3 (eventuell auch nur im Zusammenspiel mit anderen Faktoren) bei diesen Partitionsgrößen doch gravierende Probleme hat.

Viele Grüße,
Roi