Re: schlechte Performance bei Sicherung
Hallo Harald,
From: "Harald Weidner"
"Daniel Bauer" <mlist@dsb-gmbh.de>:
./testfs.sh mkfs.ext2
Gesamtzahl geschriebener Bytes: 1466245120 (1,4GiB, 128MiB/s)
./testfs.sh mkfs.ext3
Gesamtzahl geschriebener Bytes: 1466245120 (1,4GiB, 24MiB/s)
./testfs.sh mkfs.ext4
Gesamtzahl geschriebener Bytes: 1466245120 (1,4GiB, 19MiB/s)
Ich weiss nicht, was dein testfs.sh macht, aber ich bezweifle, dass in
praktisch relevanten Anwendungsfällen ext2 einen Vorteil gegenüber
ext3
oder ext4 hat.
Es legt das Filesystem mit Standardwerten auf der Testpartition an,
mounted es und schreibt mit tar darauf. Die Ausgabe von tar mit Volumen
und Geschwindigkeit ist jeweils die Zeile drunter.
Mein tar sieht so aus:
tar -cSpf /fstest.tar --atime-preserve --numeric-owner --totals /fstest
Wenn ext3/4 bei einem schreiblastigen Test schlecht performant, dann
liegt
das wahrscheinlich am Journal und/oder an den Write Barriers. Mit den
Mountoptionen data=writeback und barrier=0 erreicht man wahrscheinlich
Werte, die näher an ext2 liegen; aber auf Kosten einer verminderten
Datensicherheit, ebenfalls näher an ext2.
Soweit ich das sehe, liest tar die Daten nur und so sollte eigentlich
doch kein Schreibvorgang nötig sein, oder? Ich habe die Params noatime
und data=writeback schon gegooglet, es machte aber auch kein
nennenswerter Unterschied. barrier=0 habe ich noch nicht ausprobiert.
welche Performance Tips gibt es denn für ext2, oder wäre ein anderes
FS
noch besser?
Bei ext2 kann man fast gar nichts tunen.
Es gibt ein paar generelle Tipps, die für fast alle Filesysteme
gelten:
- Der in Linux per default eingestellte I/O Scheduler "cfq" ist bei
rein
sequentiellen Operationen oft nicht optimal. Probiere mal "deadline"
oder "noop".
http://www.thomas-krenn.com/de/wiki/Linux_I/O_Scheduler
Schau ich mir gleich mal an.
- Bei langsamen Festplatten mit kleinen Caches und Anwendungen, die
viel
synchron schreiben wollen, kann es hilfreich sein, das Tool
"eatmydata"
zu verwenden. Die erhöhte Performance geht allerdings auch hier zu
Lasten der Datensicherheit!
http://packages.debian.org/wheezy/eatmydata
Ab wann ist die Festplatte langsam? Wie bereits geschrieben mit hdparm
bekomme ich fast 200 MB/s.
- Bei Lesetests kann das Abschalten der atime hilfreich sein. Bei
aktuellen
Kerneln spielt das aber kaum noch eine Rolle.
Es ist ein Squeeze:
Linux backup 2.6.32-5-amd64 #1 SMP Fri May 10 08:43:19 UTC 2013 x86_64
GNU/Linux
ich gehe also davon aus, daß ich mich hier nicht schlau machen muß.
- Filesysteme nicht bis zum Anschlag füllen. Ab ca. 80% Füllstand
steigt die
Wahrscheinlich für Fragmentierung schlagartig an.
Selbst mit den Realdaten bin ich hier weit drunter (250 GB von 8 TB).
- Dem Rechner mehr RAM spendieren, damit größere Teile des Filesystems
im
Cache gehalten werden können. Vor dem Start einer zeitkritischen
Anwendung
Die Box hat schon 4 GB und langweilt sich - soweit ich das beurteilen
kann.
können mit "find /dir -ls" oder "ls -lR /dir" die Metadaten schonmal
in den Cache geladen werden.
Versuche ich noch.
- Falls du einen Hardware RAID-Controller hast, einen
batterie/flash-gepufferten Schreibcache nachrüsten.
- Einen schnelleren RAID-Level wählen. RAID-1 statt RAID-5/6, oder
sogar
RAID-10 über mehrere Plattenpaare.
Es ist ein externes Raidsystem mit Level 10 und mit hdparm und dd
bekomme ich ja auch super Werte.
Grüße
Daniel
Reply to: