Langsame Lese/Schreibraten nach ZFS update

R

reh

Member
Hallo,

ich habe lokal ein FreeBSD 7.0 System mit 16x1TB HDD auf ein FreeBSD 8.1 mit 16x2TB HDD aktualisiert (Update durch Neuinstallation, kein freebsd-update)

Davor waren die HDD per Hardwareraid auf 2x 6 Disk Raid5, darüber dann ein ZFS. Lese- und Schreibraten waren problemlos bei ca 200 - 250MB/s gewesen.

Nach dem Umstieg habe ich den best practices von solaris folgend alle 16 Festplatten als singe drive durchgereicht und dann 2 raid5 im mirror erstellt zum Testen:
zpool create tank raidz da0 da2 da4 da6 da8 da10 da12 da14 raidz da1 da3 da5 da7 da9 da11 da13 da15

darüber erreiche ich jetzt bei meinen Tests nur sehr geringe Lese- und Schreibraten, ca 60MB/s schreibend und 20-30MB/s lesend.

Die theoretischen Werte sind auch deutlich niedriger,siehe z.B. bonnie++:
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
opteron.reh 8G 65 99 151755 62 58447 25 190 99 84794 14 317.8 7
Latency 263ms 1026ms 1144ms 46243us 365ms 785ms
Version 1.96 ------Sequential Create------ --------Random Create--------
opteron.reh -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 15671 99 +++++ +++ 14022 99 15321 97 +++++ +++ 13329 99
Zum Vergrößern anklicken....

Testweise den Pool wieder zerstören und nur über eine einzige HDD anlegen brachte keine Geschwindigkeitsunterschiede. Kopieren von und auf Ramdisk über mdconfig erreichte auch nur die ~80MB/s schreiben und ~30MB/s lesen.

Hardware ist ein Dual Opteron Dual Core System, mit aktuell 4GB Ram. Dazu werkelt ein 16 Port 3Ware Controller (läuft also auch AMD64).

Laut top ist immer 500mb-1,5gb Ram frei und die CPUs feiern Party wegen Urlaub und Nichtstun.

Hauptnutzen von dem Server ist ein Zwischenspeicher für Video- und Bildbearbeitung, es sind also hauptsächlich Daten von 5-50GB Größe zu erwarten, nahezu kein Kleinkram. Zugriff über FTP und Samba.

Hat jemand Vorschläge/Hinweise wie ich FreeBSD/ZFS überrede, das ganz zu beschleunigen? Am Hardware Raid liegt es hoffentlich nicht, die Build und Rebuild Zeiten in der Größe sind absolut uninteressant zum testen, das dauert gute 1-2 Tage um den testweise aufzusetzen.

Falls weitere Details zum System gebraucht werden, bitte fragen.
 
Also wenn ich das richtig Lese nutzt du einen hardware Raid?
Wenn du den Best Practices Guide verfolgst, dann solltest du den erstmal auflösen und das über RaidZ lösen.Das dürfte dir schonmal ca. 10% mehr bringen. Wenn du unbedingt bei deinem Hardware Raid bleiben möchtest, dann lade auf jeden Fall mal ahci.ko in den Kernel und spiele mal mit
Code: 
vfs.zfs.vdev.min_pending=4 #default=4
vfs.zfs.vdev.max_pending=8 #default = 35
in der /boot/loader.conf rum. Diese Variablen sind da um die Request Zahl auf LUNs zu reguliere, könnte also helfen.

Ansonsten sind 4GB Ram eigentlich wirklich eher wenig für das, was du da tust bzw. tun willst. Daher mal
Code: 
vfs.zfs.txg.synctime="1"
setzen. Damit reduzierst du die Sync-Zeit des ARC und er fängt früher an auf die Platte zu schreiben. Könnte dir durchaus helfen. Ich würde an deiner Stelle mal mit der Variable zwischen 1 und 5 rumspielen was passiert.
 
Vorher hatte ich ein hardware raid, jetzt nicht mehr. Von dem hardware raid möchte ich gerne weg :)

Nach dem Umstieg habe ich den best practices von solaris folgend alle 16 Festplatten als singe drive durchgereicht und dann 2 raid5 im mirror erstellt zum Testen:
zpool create tank raidz da0 da2 da4 da6 da8 da10 da12 da14 raidz da1 da3 da5 da7 da9 da11 da13 da15
Zum Vergrößern anklicken....

am ARC habe ich bisher nicht probiert, weil laut top durchgängig noch RAM übrig war. Kann ich aber mal ausprobieren.
 
Zuletzt bearbeitet:
MuffiXXL schrieb:
Also wenn ich das richtig Lese nutzt du einen hardware Raid?
Wenn du den Best Practices Guide verfolgst, dann solltest du den erstmal auflösen und das über RaidZ lösen.Das dürfte dir schonmal ca. 10% mehr bringen.
Zum Vergrößern anklicken....

Bist du sicher über diese Aussage? Also ein 3ware-Controller ist schon was edles und skaliert fast linear in der Geschwindigkeit zur Plattenzahl. Ich habe auch noch nie erlebt, dass irgendeine Software-RAID-Konfiguration einen Hardware-RAID übertrumpft hat. Meistens geht die Geschwindigkeit nämlich wegen verdoppelter Control-I/O noch einmal runter.

Zur Zeit meckern alle auf current@ über verschiedene Geschwindigkeitsprobleme mit ZFS. Das liegt wohl an der Hardware, die sie einsetzen. Ich glaube da ist irgendwo ein Wurm drin. Nur keiner kann den so recht finden.
 
Also ich habe mit 4GB RAM auf einem AM3 Board unter FreeBSD 8.2-RC1. Einen Pool für Daten und Jails bestehend aus 4 2TB WD20EADS mit 4kiByte Sektoren als RAID-Z1. Die Platten sind GPT partitioniert mit korrektem Alignment. Auf der jeweils einzigen Partition ist GELI mit 4kB Blöcken und AES-128-XTS im Einsatz. Ich erreiche auf dem RAID-Z1 ca. 220 MiByte/s lesend und schreibend trotz geli. Auf der Box läuft sonst ein X.org + NVidia Blob, xmonad, nen paar xterms und Firefox 3.6 mit Vimperator. Zusammen ca. 200MiBytes rsize.

Das Hostsystem ist auf ner eigenen 1TB Platte in einem eigenen zpool. 8GB Swap sind eingerichtet nach einigen Tagen Uptime stabilisiert sich die swap Nutzung bei <50MByte. Wahrscheinlich Prozesse die >24h geschlafen haben. Die Swappartition dient nur dazu um notfalls Coredumps zu haben.

Welche Prozesse stehen denn unter den Top 16, wenn du `top -Sores` ausführst? Swapped dein System (pagein, pageout)? Was für eine CPU verwendest du?
 
Crest schrieb:
Also ich habe mit 4GB RAM auf einem AM3 Board unter FreeBSD 8.2-RC1. Einen Pool für Daten und Jails bestehend aus 4 2TB WD20EADS mit 4kiByte Sektoren als RAID-Z1. Die Platten sind GPT partitioniert mit korrektem Alignment. Auf der jeweils einzigen Partition ist GELI mit 4kB Blöcken und AES-128-XTS im Einsatz. Ich erreiche auf dem RAID-Z1 ca. 220 MiByte/s lesend und schreibend trotz geli. Auf der Box läuft sonst ein X.org + NVidia Blob, xmonad, nen paar xterms und Firefox 3.6 mit Vimperator. Zusammen ca. 200MiBytes rsize.

Das Hostsystem ist auf ner eigenen 1TB Platte in einem eigenen zpool. 8GB Swap sind eingerichtet nach einigen Tagen Uptime stabilisiert sich die swap Nutzung bei <50MByte. Wahrscheinlich Prozesse die >24h geschlafen haben. Die Swappartition dient nur dazu um notfalls Coredumps zu haben.

Welche Prozesse stehen denn unter den Top 16, wenn du `top -Sores` ausführst? Swapped dein System (pagein, pageout)? Was für eine CPU verwendest du?
Zum Vergrößern anklicken....

Ich vergaß zu erwähnen, dass ich ISO Präfixfoo nur außnahmsweise mal formal korrekt aufgeschrieben habe.
 
cla schrieb:
Welche Festplatten vorher und jetzt nacher?
Zum Vergrößern anklicken....

Vorher: Samsung HD103UJ
Jetzt: Sasmung HD2040UI

nakal schrieb:
Bist du sicher über diese Aussage? Also ein 3ware-Controller ist schon was edles und skaliert fast linear in der Geschwindigkeit zur Plattenzahl. Ich habe auch noch nie erlebt, dass irgendeine Software-RAID-Konfiguration einen Hardware-RAID übertrumpft hat. Meistens geht die Geschwindigkeit nämlich wegen verdoppelter Control-I/O noch einmal runter.
Zum Vergrößern anklicken....
Wenn ich ein Hardware Raid darunter habe und dann ein pool darüber anlege, können z.b. die self healing Funktonen nicht genutzt werden, ich könnte da sogar dann ein UFS drüberlegen weil auch das device Handling allein beim Controller liegt.
Das Hardware Raid aufzubauen wird einige Stunden (Tag?) kosten, das kann ich nicht auf die schnelle ausprobieren.

nakal schrieb:
Zur Zeit meckern alle auf current@ über verschiedene Geschwindigkeitsprobleme mit ZFS. Das liegt wohl an der Hardware, die sie einsetzen. Ich glaube da ist irgendwo ein Wurm drin. Nur keiner kann den so recht finden.
Zum Vergrößern anklicken....
Soweit ich Mailinglisten und foren jetzt verfolgt und gelesen habe, habe ich auch den Eindruck. Anscheinend benötigt es noch eine gewisse Reifezeit, sowohl Software, als auch Hardwareseitig. Und natürlich auch auf der Bedienerseite. ZFS ist ja immer noch sehr frisch. Was mich bei meinem Fall hauptsächlich stört, dass es damals unter FreeBSD 7 schneller war.

Was für eine CPU verwendest du?
Zum Vergrößern anklicken....
2 x Opteron 270, also 2x2x2GHZ
Ein neben Kopiertests laufendes top zeigte keine Swap Nutzung und meistens 500-1500MB freien Ram an.

Danke schon mal für die Tipps und Anmerkungen, ich werde die Sachen mal ausprobieren. Mehr Ram kann ich gerade nicht reinstecken weil grad keinen herumliegen. Da hoffe ich aber top vertrauen zu können, dass wirklich noch frei ist.
 
nakal schrieb:
Bist du sicher über diese Aussage? Also ein 3ware-Controller ist schon was edles und skaliert fast linear in der Geschwindigkeit zur Plattenzahl. Ich habe auch noch nie erlebt, dass irgendeine Software-RAID-Konfiguration einen Hardware-RAID übertrumpft hat. Meistens geht die Geschwindigkeit nämlich wegen verdoppelter Control-I/O noch einmal runter.

Zur Zeit meckern alle auf current@ über verschiedene Geschwindigkeitsprobleme mit ZFS. Das liegt wohl an der Hardware, die sie einsetzen. Ich glaube da ist irgendwo ein Wurm drin. Nur keiner kann den so recht finden.
Zum Vergrößern anklicken....

Ziemlich, denn ein RaidZ ist ja nicht "einfach" ein Raid 5, sondern ein recht stark optimierender Algorithmus, der einige Randbedingungen und tricksereien nutzt, die man in einen Hardware Raid-Controller eben nicht so einfach giessen kann. Dadurch ist der Spaß in der Regel (vorausgesetzt natürlich CPU und Ram stellen hier keinen Flaschenhals dar) tatsächlich an die 10% schneller als ein Hardware Raid.
 
Kann es sein, dass du mit ZFS den Buffercache des Controllers nicht nutzt? Was sagt gstat zu deinen Platten unter Last?
 
MuffiXXL schrieb:
Ziemlich, denn ein RaidZ ist ja nicht "einfach" ein Raid 5, sondern ein recht stark optimierender Algorithmus, der einige Randbedingungen und tricksereien nutzt, die man in einen Hardware Raid-Controller eben nicht so einfach giessen kann. Dadurch ist der Spaß in der Regel (vorausgesetzt natürlich CPU und Ram stellen hier keinen Flaschenhals dar) tatsächlich an die 10% schneller als ein Hardware Raid.
Zum Vergrößern anklicken....

Ich habe bei mir 670MB/s auf dem 3ware-Controller. Der RAID5 darauf kann sich auch selbst gut heilen. Das ist mit UFS auf jeden Fall kein Problem. Vor allem ist der Cache Batterie-gepuffert und kann ziemlich gut bis zum letzten Schritt so weit wie möglich noch die Daten retten.

Auf den RAID-Karten ist selbst eine CPU drauf, die alles ballanciert und die Hardware genau kennt. Sie "weiß" wo gerade am günstigsten die Köpfe jeder Platte stehen und sorgt für reduzierte Latenzzeiten. Zudem werden noch mehr Optimierungen gemacht, die die CPU gar nicht belasten und den Bus optimieren.

Ich hatte da mal ZFS drauf. Ich erinnere mich nicht, dass es schneller war. Und das war nicht mal eben 10% sondern eher ~50% Verlust an Leistung mit ZFS. Aber nachdem sich ZFS selbst nicht mehr heilen konnte (zpool import hat einen panic() geschmissen), habe ich das Restore auf UFS2 gemacht. Seitdem habe ich keine Probleme mehr.
 
Leider bin ich noch nicht dazu gekommen, die Vorschläge oben auszuprobieren, da ich das System erst auseinandergebaut habe um sicherheitshalber die Hardware zu testen dass es nirgends auf der Ebene liegt. Vereinfachtes Ergebnis, unter einem Windows Server 2008 macht eine Festplatte als Single Unit ihre 130mb/s am 3ware controller. Ich bin gerade dabei, die FreeBSD Konfiguration wieder herzustellen.

MuffiXXL schrieb:
Was mir da grade noch einfällt.. Den ZFS Tuning Guide aus FreeBSD 7 Zeiten hast du nicht wieder angewendet, oder?
Zum Vergrößern anklicken....
den habe ich "angewendet", gemäß http://wiki.freebsd.org/ZFSTuningGuide:
amd64

FreeBSD 7.2+ has improved kernel memory allocation strategy and no tuning may be necessary on systems with more than 2 GB of RAM.
Zum Vergrößern anklicken....
habe ich nichts geändert.

@crest
Kann ZFS die Nutzung des Controllercaches beeinflußen? Ich hoffe doch nicht, dass er umgangen wird. Hätte aber ansonsten auch das Verständnis gehabt, dass es bei großen sequentiellen read/write keine dramatischen Auswirkungen hat.

@nakal:
zur Sache mit der BBU hätte ich eine Randfrage. Ich habe hier auch ein BBU Modul herumliegen für den Controller, nutze es aber nicht. Grund: Vor dem System hängt eine USV, unerwarteter Stromausfall kommt dann nicht. Netzteil war die ganze Zeit redundant, momentan zum Aufbau single. Wenn ich mich auf die BBU verlasse, cached die ja nur den Controller Ram, der HDD Cache ist weiterhin unsicher. Und ohne HDD Cache zu arbeiten macht sich stark negativ bemerkbar. Was sind da die Vorteile oder Gründe die BBU Einheit zu nutzen?
 
Der Vorteil der BBU ist, dass halt im Falle eines Stromausfalls die Konsistenz gesichert bleibt. Da FreeBSD nicht wissen kann, ob da eine USV zwischen hängt oder nicht, wird ohne BBU der Write Cache des Controllers deaktiviert. Die Auswirkungen sind dann eher miese Geschwindigkeit, vor allem aber nicht nur beim Schreiben. Du solltest ihn also erst einmal zwingen den Cache zu nutzen:
Code: 
/cx/ux set cache=on
in tw_cli. Sei dir aber vorher wirklich absolut sicher, dass du keinen Stromausfall haben wirst, denn sonst verwandeln sich deine Daten in Fleischsalat.
 
BBU _immer_ einsetzen. Sämtliche Raid-Ausfälle, die mir in meiner Vergangenheit bisher begegnet sind waren auf eine fehlende BBU und somit verlorener Daten zurückzuführen.

Bei ZFS sollte durch COW eigentlich nicht viel passieren...da aber der Raidcontroller (auch wenn er die Platten nur einzeln zur Verfügung stellt) eine Art "Blackbox" ist und die genaue Funktion nur der Hersteller kennt, sollte man da lieber nichts riskieren.

Und stimmt...was Yamagi da schreibt...ohne BBU erstmal kein Schreib-Cache aktiv im Controller; dadurch massive Performanceverluste.

Die USV ist natürlich weiterhin sinnvoll :-)
 
im Moment habe ich ein raidz2 über alle 16 drives aktiviert, da ich weder bei einem pool über eine einzelne HDD, noch bei 2xraidz über 8 HDDs Abweichungen/Verbesserungen feststellen konnte.

Welche Prozesse stehen denn unter den Top 16, wenn du `top -Sores` ausführst?
Zum Vergrößern anklicken....

Code: 
top -P -Sores
145 processes: 6 running, 117 sleeping, 22 waiting
CPU 0:  0.4% user,  0.0% nice,  9.4% system,  0.0% interrupt, 90.2% idle
CPU 1:  0.0% user,  0.0% nice, 22.2% system,  5.3% interrupt, 72.6% idle
CPU 2:  0.0% user,  0.0% nice,  7.9% system,  0.0% interrupt, 92.1% idle
CPU 3:  0.0% user,  0.0% nice,  1.9% system,  9.4% interrupt, 88.8% idle
Mem: 39M Active, 18M Inact, 1465M Wired, 428K Cache, 405M Buf, 2315M Free
Swap: 4096M Total, 24K Used, 4096M Free

  PID USERNAME  THR PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
 1681 root        1  44    0 36564K 14028K select  0   0:00  0.00% perl5.10.1
danach folgen mehrere sshd. Stand während laufendem bonnie++
Free Ram geht auch nicht wirklich unter 2000 während bonnie++ durchläuft oder ich von der System HDD/Netzwerk kopiere.

zu gstat während bonnie++:
Code: 
gstat
dT: 1.002s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
 5    249      0      0    0.0    249  26681    4.7   31.6| da0
    5    249      0      0    0.0    249  26681    4.6   31.6| da1
    5    247      0      0    0.0    247  26681    4.5   30.8| da2
    5    247      0      0    0.0    247  26681    4.5   30.9| da3
    5    247      1     64   34.8    246  26682    4.5   34.6| da4
... (keine Abweichungen von den Werten)

während kopieren von System HDD/Netzwerk:
Code: 
dT: 1.001s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
    0    198    198   1809    0.6      0      0    0.0   12.2| da0
    0    198    198   1809    0.6      0      0    0.0   11.8| da1
    0    197    197   1800    0.6      0      0    0.0   12.3| da2
    0    197    197   1800    0.6      0      0    0.0   12.1| da3
    0    198    198   1809    0.7      0      0    0.0   13.1| da4
... (keine Abweichungen von den Werten)


Zum cache:
also mittels /c0/ux greife ich doch auf die Platten zu und aktiviere den Plattencache. Wie ich den Cache des Controllers (die 256MB RAM, von denen ich nirgends Informationen gefunden habe ob ich sie z.B. auf 1GB erweitern kann) beeinflußen kann habe ich auch nach etwas studieren der 3ware docs und manuals nicht herausgefunden.

Für die units:
Code: 
Unit  UnitType  Status         %RCmpl  %V/I/M  Stripe  Size(GB)  Cache  AVrfy
u0    SINGLE    OK             -       -       -       1862.63   ON     OFF
u1    SINGLE    OK             -       -       -       1862.63   ON     OFF
...
u15   SINGLE    OK             -       -       -       1862.63   ON     OFF

ist immer Cache auf ON

und noch zfs iostat -v 5 während bonnie++:
Code: 
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        7.01T  22.0T    601      0  74.6M      0
  raidz2    7.01T  22.0T    601      0  74.6M      0
    da0         -      -    522      0  4.67M      0
    da1         -      -    522      0  4.67M      0
    da2         -      -    522      0  4.68M      0
    da3         -      -    522      0  4.68M      0
    da4         -      -    522      0  4.66M      0


Ich habe solangsam das Gefühl, ich muss mich doch dem Hardware Raid ergeben und ihn wieder am 3Ware Controller einrichten. Irgendwann verliert man auch die Lust :)
 
reh schrieb:
also mittels /c0/ux greife ich doch auf die Platten zu und aktiviere den Plattencache. Wie ich den Cache des Controllers (die 256MB RAM, von denen ich nirgends Informationen gefunden habe ob ich sie z.B. auf 1GB erweitern kann) beeinflußen kann habe ich auch nach etwas studieren der 3ware docs und manuals nicht herausgefunden.
Zum Vergrößern anklicken....
Kommt drauf an. Bei den meisten Controllern schaltet das Einschalten des Caches der Unit auch den Cache des Controllers ein. Damit wärst du glücklich und alles ist okay. Einige Controller - oder Firmware-Versionen? - müssen es noch einmal extra in ihrem Firmwaremenü gesagt bekommen. Probiere noch einmal:
Code: 
sysctl hw.ata.wc=1 # Sollte schon so stehen und nichts ändern, aber schadet auch nicht.
sysctl hw.pci.msi_enable=0 
sysctl hw.pci.msix_enable=0
sysctl vfs.read_max=128
sysctl vfs.hirunningspace=5MB
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben