FreeBSD8, 64bit, ZFS und Tuning
- Thread starter -Nuke-
- Start date
Also, ich bin den Snapshot nun losgeworden.
Ich musste den Pool dazu unmounten. Danach hats funktioniert.
An dem Snapshot war nichts besonderes. Mit clones arbeite ich nicht. Er hat auf ca. 5 TB referiert.
Hat jemand nen Vorschlag wie ich feststellen kann was die Problemursache war? Es kann ja nicht sein dass ich jeden Tag einmal den Pool unmounten muss. Und mit dem Risiko, dass sich irgendwann der Server aufhängt, wenn zfs-snapshot-mgmt versucht nen Snapshot zu löschen kann ich mich gerade nicht so richtig anfreunden, weil der Server seit nem guten Jahr ohne Probleme durchlief. Wenn er sich in Zukunft öfter weghängt würde das admininistrieren für mich ja schon fast in Arbeit ausarten :-)
Wo könnt ich denn noch Informationen zu dem Fehler finden? Es gibt weder Einträge in den Logfiles noch nen Coredump.
Ich musste den Pool dazu unmounten. Danach hats funktioniert.
An dem Snapshot war nichts besonderes. Mit clones arbeite ich nicht. Er hat auf ca. 5 TB referiert.
Hat jemand nen Vorschlag wie ich feststellen kann was die Problemursache war? Es kann ja nicht sein dass ich jeden Tag einmal den Pool unmounten muss. Und mit dem Risiko, dass sich irgendwann der Server aufhängt, wenn zfs-snapshot-mgmt versucht nen Snapshot zu löschen kann ich mich gerade nicht so richtig anfreunden, weil der Server seit nem guten Jahr ohne Probleme durchlief. Wenn er sich in Zukunft öfter weghängt würde das admininistrieren für mich ja schon fast in Arbeit ausarten :-)
Wo könnt ich denn noch Informationen zu dem Fehler finden? Es gibt weder Einträge in den Logfiles noch nen Coredump.
Mal eine grundsätzliche Frage? Nicht böse gemeint. Du hast schon sowohl ZPool als auch ZFS aktualisiert, nachdem du auf 8.0 aktualisiert hattest? Wenn du das nicht gemacht hast, läuft noch immer die doch noch recht fehlerhafte Version 6 und nicht die neue 13. Die macht unter FreeBSD 8.0 zwar schon deutlich weniger Probleme als bei 7.2, aber hat dennoch Macken, die nur durch ein vollständiges Upgrade beseitigt werden können...
Wie meinst du das? zfs upgrade -a upgradet meines Wissens nach alle pools. Alternativ zu -a kann man einen poolname angeben. Aber die ZFS - Systeme innerhalb des Pools? Sorry, ich glaube ich steh grad auf der Leitung. :-(
Hier mal zur Info:
Hier mal zur Info:
Code:
[root@h8srv /usr/local/etc]# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 4,29T 1,00T 4,15T /var/ftp/
tank@28112009 2,85M - 4,15T -
tank/backup 140G 1,00T 140G /backup
tank/backup@28112009 0 - 140G -
[root@h8srv /usr/local/etc]# zpool upgrade tank
This system is currently running ZFS pool version 13.
Pool 'tank' is already formatted using the current version.Oh mein mein Gott,
ihr glaubt nicht wie peinlich mir die ganze Sache hier ist.
Ich habe tatsächlich das zfs upgrade vergessen.
Ich habe vor einem Jahr mal das ZFS Administrationshandbuch gelesen. Und bevor ich ich nun das Upgrade durchgeführt habe, habe ich das aktuelle Handbuch runtergeladen und nach "upgrade" gesucht. Ich bin dann bei zpool upgrade gelandet und habe die Prozedur wie dort beschrieben durchgeführt. zfs upgrade habe ich völlig übersehen.
Das Problem saß also wieder mal vorm Computer.
Sollte nun behoben sein:
Ich bitte um einen
für mich, ich hab ihn verdient.
Sorry :-((((
Gruß
Flo
ihr glaubt nicht wie peinlich mir die ganze Sache hier ist.
Ich habe tatsächlich das zfs upgrade vergessen.
Ich habe vor einem Jahr mal das ZFS Administrationshandbuch gelesen. Und bevor ich ich nun das Upgrade durchgeführt habe, habe ich das aktuelle Handbuch runtergeladen und nach "upgrade" gesucht. Ich bin dann bei zpool upgrade gelandet und habe die Prozedur wie dort beschrieben durchgeführt. zfs upgrade habe ich völlig übersehen.
Das Problem saß also wieder mal vorm Computer.
Sollte nun behoben sein:
Code:
[root@h8srv /home/admin]# zpool upgrade
This system is currently running ZFS pool version 13.
All pools are formatted using this version.
[root@h8srv /home/admin]# zfs upgrade
This system is currently running ZFS filesystem version 3.
All filesystems are formatted with the current version.Ich bitte um einen
für mich, ich hab ihn verdient.Sorry :-((((
Gruß
Flo
reakktor
Well-Known Member
Eine sehr interessante Diskussion über ZFS und Schreiben gibts hier: http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg26485.html
bzw:
http://mail.opensolaris.org/pipermail/cifs-discuss/2009-January/001310.html
"The new code keeps track of the amount of data accepted in a TXG and
the time it takes to sync. It dynamically adjusts that amount so that
each TXG sync takes about 5 seconds (txg_time variable). It also
clamps the limit to no more than 1/8th of physical memory. "
Wenn ich das recht verstehe, löst das ungewöhnliche ZFS-Schreibverhalten das ganze aus. ZFS hat wohl einen fixen Schreib-Zyklus - es sammelt alle Daten, bis ein interner Timeout anspringt (bis >=5 Sek, wenn ich den Source richtig lese). Stichwort TXG. Es werden alle Änderungen an einer Datei gesammelt bzw. der Puffer gefüllt. Dann werden alle Daten in einem Rutsch geschrieben. Ist wohl auch der Grund, warum ZFS gerne so viel Speicher braucht...
Beeinflussen kann man das im Augenblick unter FreeBSD nich wirklich, drum zweifle ich die ganzen obigen Posts an und folge Yamagi: Unter FreeBSD 7.2 und 8.0 mit aktuellem Source braucht man nix einzustellen per loader.conf oder sysctl Variablen.
ZFS ist "self-tuning" - ohne Parameter sollte es sich selbst einstellen auf RAM/CPU usw.
Weitere Lektüre:
http://blogs.sun.com/roch/entry/the_new_zfs_write_throttle
http://blogs.sun.com/roch/date/20080514
http://mail.opensolaris.org/pipermail/cifs-discuss/2009-January/001310.html
http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg29624.html
Last edited:
Halt, halt. Unter FreeBSD 7.2 muss man sehr wohl etwas ändern. Das liegt aber nicht an ZFS, stattdessen ist hier FreeBSD der Schuldige. ZFS lebt komplett im Kernel und untersteht damit der Kernel-Speicherverwaltung, was in diesem Fall der UMA Zone Allocator ist. ZFS nutzt nun ein Konstrukt namens Adaptive Replacement Cache oder ARC, der wie gesagt nur ab und an mal wirklich mit der Platte synchronisiert wird. Unter FreeBSD/amd64 7.2 ist der Kernelspeicher maximal 2GB groß, zumindest in Standardeinstellung. Die "kmem_map", aus welcher UMA seinen Speicher holt, ist sogar noch kleiner und nicht nur ZFS nutzt diese. Wenn jetzt ZFS lustig arbeitet, konsumiert es immer mehr aus der UMA und irgendwann erreicht es unter Umständen den Punkt, dass sie schlicht voll ist. Weil der Kernel aber seinen eigenen Speicher nur begrenzt ausswappen kann, hat er nun ein Problem. Der einzige sinnvolle Ausweg ist der Aufruf von panic(). Verschlimmert wird dies durch Fragemntierung. UMA muss zusammenhängende Blöcke Speicher mappen können. ZFS fordert Blöcke unterschiedlicher Länge an, bis hoch zu 128KB. Nun kann es passieren, dass in der kmem_map zwar massig Speicher frei ist, aber kein Fragment mehr groß genug. Auch in diesem Fall kann er keinen Speicher finden.
Aus dieser Situation gibt es mehrere Auswege. Einerseits warten, dies nutzt FreeBSD 7.2 mit zweifelhaftem Erfolg. Wenn ZFS vom UMA nichts mehr bekommt, wird nicht sofort panic() aufgerufen. Stattdessen wartet man einen Moment, versucht es noch mal und hofft darauf, dass Speicher frei geworden ist. Wenn nicht, springt man erst dann in die Panic. Der Nutzer merkte, dass das nicht wirklich funktioniert, da ZFS selbst der größte UMA-Konsument ist. Daher senkte er die Größe der ARC, ZFS konsumierte unter dem Opfern einiger Leistung weniger Speicher und alles war gut. Oder aber er vergrößerte die kmem_map, was zumindest unter amd64 problemlos war.
FreeBSD 8 bietet nun ein deutlich besseres Ressourcenmanagement. Einmal ist unter amd64 die kmem_map deutlich größer, bis zu 60% des Speichers oder 6GB. Sie kann außerdem zur Laufzeit wachsen oder schrumpfen. Außerdem hat ZFS "Back Pressuring" bekommen. Wenn jemand anders viel Kernelspeicher will, wird ZFS dies mitgeteilt und senkt die Größe seines ARC von allein, um somit Speicher freizugeben. Alles in allem muss man ZFS hier entsprechend in keinster Weise mehr tunen, das geht von allein. Hier erklärt sich auch das allgemeine Problem von ZFS mit 32 Bit Systemen. Ihr Adressraum ist zu klein, die kmem_map damit zu beschränkt, es kommt wieder zu besagten Problemen und die Kiste wird instabil.
Aus dieser Situation gibt es mehrere Auswege. Einerseits warten, dies nutzt FreeBSD 7.2 mit zweifelhaftem Erfolg. Wenn ZFS vom UMA nichts mehr bekommt, wird nicht sofort panic() aufgerufen. Stattdessen wartet man einen Moment, versucht es noch mal und hofft darauf, dass Speicher frei geworden ist. Wenn nicht, springt man erst dann in die Panic. Der Nutzer merkte, dass das nicht wirklich funktioniert, da ZFS selbst der größte UMA-Konsument ist. Daher senkte er die Größe der ARC, ZFS konsumierte unter dem Opfern einiger Leistung weniger Speicher und alles war gut. Oder aber er vergrößerte die kmem_map, was zumindest unter amd64 problemlos war.
FreeBSD 8 bietet nun ein deutlich besseres Ressourcenmanagement. Einmal ist unter amd64 die kmem_map deutlich größer, bis zu 60% des Speichers oder 6GB. Sie kann außerdem zur Laufzeit wachsen oder schrumpfen. Außerdem hat ZFS "Back Pressuring" bekommen. Wenn jemand anders viel Kernelspeicher will, wird ZFS dies mitgeteilt und senkt die Größe seines ARC von allein, um somit Speicher freizugeben. Alles in allem muss man ZFS hier entsprechend in keinster Weise mehr tunen, das geht von allein. Hier erklärt sich auch das allgemeine Problem von ZFS mit 32 Bit Systemen. Ihr Adressraum ist zu klein, die kmem_map damit zu beschränkt, es kommt wieder zu besagten Problemen und die Kiste wird instabil.
-Nuke-
Well-Known Member
Ich habe momentan ein ähnliches Problem, auch unter FreeBSD 8 RELEASE noch, wie ich in einem anderen Thread (oder hier?
) mal mitgeteilt habe.ZFS konzentriert die die Schreiblast immer auf bestimmte Zeitpunkte, die dann (ob Bug in FreeBSD, kA) das ganze System für eine Zeit KOMPLETT lahmlegen.
Wenn dann mein Notebook mit einem rsync anfängt, dann stockt selbst Musik, die ja nun wirklich nicht viel Bandbreite braucht.
Ich hoffe das wird irgendwann noch mal behoben. Weil wenn ich entspannt eine DVD oder ein Hörbuch hören will, muss ich immer die Backups ausschalten, da ich sonst immer stündlich für ein paar Sekunden ne Zwangspause einlegen muss...
Last edited:
reakktor
Well-Known Member
@Yamagi: thnx für den informativen Input!
Allerdings habe ich etwas gemischte Gefühle mit ZFS - zur Situation:
Hauptserver IBM Quad Xeon mit FreeBSD 8 amd64 und 8GB RAM
SAN IBM mit 5x1TB Raid5 (ufs)
Allnet 6600 iSCSI 5x1TB für Backups Raid5 (ufs)
Auf dem main-Server läuft Hosting von 850.000 Bildern und 28.000 Videos, Gesamtvolumen ca. 2,5 TB. Es wird täglich ein rsync vom main-Server auf den Backup-Würfel gefahren.
Ich habe nun testweise mal einen zusätzlichen rsync auf ein Test-ZFS-RAID mit normalen SATA-Platten eingerichtet. Hardware: intel Quad 6600, 8GB RAM, AMCC/3Ware 9650-8LP Raid Controller, 5x1TB Platte
Symptom:
Am Anfang ist alles sehr flott, 'gstat' und 'zpool iostat' melden normale Transferraten für 1GB-Link (~80MB/s).
Es kommt dabei immer zum bekannten ZFS-write-hole - Backup-Maschine dreht Däumchen, es gibt lange Pausen beim Schreiben. Ingesamt ist die Performance am Anfang noch gut.
Mit der Zeit verschlechtert sich das ganze jedoch - Schreib-Performance auf dem Test-Server ist nach ca. 20 Tagen Uptime im Keller, nur noch ~5MB/s. CPU und Platten sind quasi idle, rsync bricht sogar ab und zu ab mit Timeouts. Nach einem Reboot der Test-Maschine ist wieder alles in Ordnung, nur ich kann zuschauen, wie die Performance jeden Tag wieder sinkt.
Ich bin mir nicht sicher, ob ZFS auf FreeBSD wirklich schon als "stable" einzustufen ist... Für den Heimgebrauch sicher, aber für Business-Betrieb habe ich da Zweifel.
Habe *einiges* an Tweaks aus den opensolaris- und freebsd-zfs-Mailinglisten versucht, aber bis jetzt ohne Erfolg.
'vfs.zfs.*' Einstellungen hin oder her, am Gesamtverhalten ädert sich da wenig.
Ich werde das weiter verfolgen, da ZFS von den Features her eigentlich perfekt für unsere Bedürfnisse hier geeignet ist, aber irgendwie rennt das noch nicht so wie es sollte...
Edit zur fortgeschrittenen Zeit: o.g. rsync läuft gerade
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-June/029076.html
Darauf bin ich auch gestossen - für mich ein Flaw-By-Design - solange nicht behoben ist ZFS nicht unbedingt interessant für Fileserver und On-Demand-Backup/Restore...
Allerdings habe ich etwas gemischte Gefühle mit ZFS - zur Situation:
Hauptserver IBM Quad Xeon mit FreeBSD 8 amd64 und 8GB RAM
SAN IBM mit 5x1TB Raid5 (ufs)
Allnet 6600 iSCSI 5x1TB für Backups Raid5 (ufs)
Auf dem main-Server läuft Hosting von 850.000 Bildern und 28.000 Videos, Gesamtvolumen ca. 2,5 TB. Es wird täglich ein rsync vom main-Server auf den Backup-Würfel gefahren.
Ich habe nun testweise mal einen zusätzlichen rsync auf ein Test-ZFS-RAID mit normalen SATA-Platten eingerichtet. Hardware: intel Quad 6600, 8GB RAM, AMCC/3Ware 9650-8LP Raid Controller, 5x1TB Platte
Symptom:
Am Anfang ist alles sehr flott, 'gstat' und 'zpool iostat' melden normale Transferraten für 1GB-Link (~80MB/s).
Es kommt dabei immer zum bekannten ZFS-write-hole - Backup-Maschine dreht Däumchen, es gibt lange Pausen beim Schreiben. Ingesamt ist die Performance am Anfang noch gut.
Mit der Zeit verschlechtert sich das ganze jedoch - Schreib-Performance auf dem Test-Server ist nach ca. 20 Tagen Uptime im Keller, nur noch ~5MB/s. CPU und Platten sind quasi idle, rsync bricht sogar ab und zu ab mit Timeouts. Nach einem Reboot der Test-Maschine ist wieder alles in Ordnung, nur ich kann zuschauen, wie die Performance jeden Tag wieder sinkt.
Ich bin mir nicht sicher, ob ZFS auf FreeBSD wirklich schon als "stable" einzustufen ist... Für den Heimgebrauch sicher, aber für Business-Betrieb habe ich da Zweifel.
Habe *einiges* an Tweaks aus den opensolaris- und freebsd-zfs-Mailinglisten versucht, aber bis jetzt ohne Erfolg.
'vfs.zfs.*' Einstellungen hin oder her, am Gesamtverhalten ädert sich da wenig.
Ich werde das weiter verfolgen, da ZFS von den Features her eigentlich perfekt für unsere Bedürfnisse hier geeignet ist, aber irgendwie rennt das noch nicht so wie es sollte...
Edit zur fortgeschrittenen Zeit: o.g. rsync läuft gerade
Lesender Zugriff per SCP oder SMB-Share auf den test-Server ist kaum möglich, wenn ZFS loslegt - wenn ZFS schreibt, geht mit Lesen kaum mehr was - kann Nuke's Beobachtung nur bestätigen...
http://mail.opensolaris.org/pipermail/zfs-discuss/2009-June/029076.html
Darauf bin ich auch gestossen - für mich ein Flaw-By-Design - solange nicht behoben ist ZFS nicht unbedingt interessant für Fileserver und On-Demand-Backup/Restore...
Last edited:
Wenn du mich persönlich fragst, ob du ZFS einsetzen solltest, ist die Antwort sowohl unter Solaris als auch unter FreeBSD im Moment "Nein". Es mag natürlich daran liegen, dass ich ein konservativer BSDler bin, aber wenn ich mir so anschaue was für Bugs Sun teilweise noch korrigieren muss, sehe ich das Dateisystem inzwischen mit sehr gemischten Gefühlen. ZFS ist hochkomplex, allein die Implementierung in etwa zehn Mal so groß wie UFS2. Das Ding ist einfach komplett überentwickelt. Nach fast 5 Jahren traut man sich nun, es als stabil zu kennzeichnen. Aber so wirklich stabil ist es noch immer nicht, zumindest nicht stabil in dem Sinne, dass man nicht monatlich noch kritische Fehler findet. Darunter auch so schöne Dinge wie, dass unter Umständen integrale Systemdatei plötzlich 0777 als Berechtigung haben.
Meine eigene Erfahrung mit ZFS geht dahin, dass es dank 8 Gigabyte RAM zwar cached wie nichts Gutes, aber am Ende nichts dabei rumkommt. Es ist subjektiv einfach merklich langsamer gewesen als UFS2 und hat ein massives Problem mit Überlastsituationen. Dabei bricht es völlig ein, ist auch noch Minuten später kaum ansprechbar, rasselt wie blöd auf der Platte rum... Nach einigen Monaten mit ZFS wage ich zu sagen, dass es ein Spezialist ist. Ein Dateisystem, entwickelt für wirklich dicke Kisten mit brachialer IO-Leistung. Sprich, sündteure SPARC-Fileserver. Auf dem Desktop, auf x86-Kisten allgemein ist es so eine Sache.
Meine eigene Erfahrung mit ZFS geht dahin, dass es dank 8 Gigabyte RAM zwar cached wie nichts Gutes, aber am Ende nichts dabei rumkommt. Es ist subjektiv einfach merklich langsamer gewesen als UFS2 und hat ein massives Problem mit Überlastsituationen. Dabei bricht es völlig ein, ist auch noch Minuten später kaum ansprechbar, rasselt wie blöd auf der Platte rum... Nach einigen Monaten mit ZFS wage ich zu sagen, dass es ein Spezialist ist. Ein Dateisystem, entwickelt für wirklich dicke Kisten mit brachialer IO-Leistung. Sprich, sündteure SPARC-Fileserver. Auf dem Desktop, auf x86-Kisten allgemein ist es so eine Sache.