Bottleneck und Netatalk

minimike

minimike

Berufsrevolutionär
Hallo liebe Gemeinde

Ich suche gerade mal Tips um Netatalk zu debuggen.
Das Setup besteht aus samba36 der die User aus Active Directory holt und mittels PAM systemweit bereitstellt. Via PAM authtifizieren sich die User gegen den Winbind an Netatalk.
OS ist FreeBSD 9.1-RC1
Die Kiste hat 16x 3000 GB Platten im RaidZ3, 96 GB Ram und zwei fette Xeons. Am Switch ist die Box mit einer 10 GBit Nic angebunden. Die Clients mit je 1 GBit
Bis 50 Apple Systeme mit MacOSX sollen darauf ihre TimeMachine Backups machen. Alle anderen Backups macht Bacula. Das wiederum die TimeMachine Backups einmal die Woche auf Band sichert.
Im ersten Test habe ich 160 GB in einer guten Stunde via AFS von meinem Dienst-Laptop mit MacBook Pro mit OSX Lion an den Server geschaufelt. Wir testen das zur Zeit mit 5 Mann im kleinen Kreis bevor wir das an die Belegschaft ausliefern.

Wenn wir aber TimeMachine Backups machen, dauert es bei durchschnittlich 200 GB pro Client bis zu 20 Stunden! Die Geschwindigkeit ist nicht reproduzierbar. Mal geht es flott. Mal schnarcht das so vor sich hin.

Das ist so mein erster Kontakt mit FreeBSD als File-Server. Und ebenso mit Netatalk.

Für Tips wo nach ich alles gucken und woran es liegen könnte würde ich mich freuen.
Wenn ich es schaffe mit diesem Projekt FreeBSD zu etablieren haben weitere FreeBSD Installationen in meiner Firma bis hin zur Ablösung diverser Windows und Linuxsysteme eine Zukunft.
 
Zuletzt bearbeitet:
Crest schrieb:
Bitte sag mir das die 16 Platten nicht ein RAID-Z3 VDEV sind. Bist du dir sicher das du Andrew FS meinst?
Zum Vergrößern anklicken....

Zum ersten Teil was meinst du damit? Die Platten werden direkt vom Raidcontroller durchgeschliffen und ZFS übernimmt dann ab da alles. Vom Raid bis zum Volumemanagement.

Zum zweite Teil ich habe mich verschrieben. Es wir AFP gemeint. Kurz für Apple Filling Protocol.

edit das ZFS Setup habe ich ähnlich wie hier realisiert
http://www.bsdforen.de/showthread.php?t=28070&highlight=zfs

cheers Darko
 
Außerdem schreibst du nichts zu deinen Log-Devices. Dazu ein wenig Erklärung: Eigentlich alle Netzwerkdateisysteme arbeiten synchron, d.h. sie schieben direkt nach jedem "write" ein "sync" hinterher. Nur so können sie über verschiedene Rechner hinweg die u.a. von POSIX verlangten Konsistenzeigenschaften sicherstellen. Für ZFS ist dies Verhalten aber tödlich, denn jeder "sync" erzwingt einen Abbruch aller laufenden Transaktionen, inklusive Rollback, schreibt die Änderung ins ZIL und startet die Transaktionen anschließend neu. Was bei lokalem Einsatz mit ein paar "sync" pro Minute problemlos ist, ist im Netzwerkeinsatz mit hundertausenden "sync" natürlich tödlich. Daher sollte jeder über das Netzwerk exportierte Pool (und eigentlich auch jeder lokale Pool ab einer gewissen Größe und Last) zwei gespiegelte Log-Devices haben. Auf schnellen SSD, am besten die teuren SLC-SSD, mit möglichst vielen IOPS. Denn in ein separates Log-Device kann der Pool schreiben, ohne laufende Transaktionen zu unterbrechen.
 
kann ich dafür eine 100GB Partition auf zwei SSD's gespiegelt mit gmirror hierfür abzwacken?
Das System ist auf zwei SSD's mit Slices via gmirror. Ich habe für Datenbanken 100 GB dadrauf eingeplant. Notfalls könnte man die woanders Betreiben.
Und reichen 100 GB für das Log aus? Bzw wie kalkuliert man die richtige Größe?
 
Zu den Log-Devices: Ja, zwei Partitionen der SSD sind völlig ausreichend. gmirror brauchst du dort natürlich nicht, ZFS spiegelt sie für dich. "zpool add $poolname log mirror $dev_a $dev_b". Sie sollten gespiegelt sein, damit eine ausgefallene SSD nicht zu Datenverlust führt. Die Größe der Log-Devices fällt kaum mehr ins Gewicht. Sun empfahl "X * 10", wobei X der Durchsatz pro Sekunde in Megabyte ist. Um also 100MB/s synchroner Schreiboperationen bearbeiten zu können, bräuchtest du ein 1GB Log-Device.

Aber ein Log-Device allein wird wahrscheinlich keine Wunder vollbringen, solange deine Pool-Einteilung suboptimal ist. Wie Crest schon sagte, wird RAID-Z (wie jedes RAID-System) mit steigender Festplattenanzahl langsamer. Sinnvoller als ein RAID-Z3 über 16 Platten könnten z.B. 4 RAID-Z1 Gruppen mit jeweils 4 Platten sein, die zusammen dann zusammen den Pool bilden.
 
Yamagi schrieb:
Aber ein Log-Device allein wird wahrscheinlich keine Wunder vollbringen, solange deine Pool-Einteilung suboptimal ist. Wie Crest schon sagte, wird RAID-Z (wie jedes RAID-System) mit steigender Festplattenanzahl langsamer. Sinnvoller als ein RAID-Z3 über 16 Platten könnten z.B. 4 RAID-Z1 Gruppen mit jeweils 4 Platten sein, die zusammen dann zusammen den Pool bilden.
Zum Vergrößern anklicken....

Könntest du mir dann noch beschreiben wie ich diesen Pool anlegen kann?

zpool create raidz1 da0 da1 da2 da3
zpool create raidz1 da4 da5 da6 da7
zpool create raidz1 da8 da9 da10 da11
zpool create raidz1 da12 da13 da14 da15

Dann hätte ich ja die vier pools aber wie bekomme ich die dann zum großen zusammen? Oder denke ich da wieder falsch?

zu gmirror, ich habe die ganzen SSD's daran verfüttert. Wenn ich also eine Partition darin verfüttere muss es ohne Neuinstallation mit gmirror gehen. Das gibt keine Probleme?

lg Darko
 
minimike schrieb:
Könntest du mir dann noch beschreiben wie ich diesen Pool anlegen kann?

zpool create raidz1 da0 da1 da2 da3
zpool create raidz1 da4 da5 da6 da7
zpool create raidz1 da8 da9 da10 da11
zpool create raidz1 da12 da13 da14 da15

Dann hätte ich ja die vier pools aber wie bekomme ich die dann zum großen zusammen? Oder denke ich da wieder falsch?
Zum Vergrößern anklicken....

$ man zpool (EXAMPLES)

# zpool create NAME raidz1 da0 da1 da2 da3 raidz1 da4 da5 da6 da7 raidz1 da8 da9 da10 da11 raidz1 da12 da13 da14 da15

Alternativ kannste auch
# zpool create NAME raidz1 da0 da1 da2 da3

und dann:
# zpool add NAME raidz1 da4 da5 da6 da7
# zpool add NAME raidz1 da8 da9 da10 da11
# zpool add NAME raidz1 da12 da13 da14 da15
 
Zuletzt bearbeitet:
Yamagi schrieb:
Zu den Log-Devices: Ja, zwei Partitionen der SSD sind völlig ausreichend. gmirror brauchst du dort natürlich nicht, ZFS spiegelt sie für dich. "zpool add $poolname log mirror $dev_a $dev_b". Sie sollten gespiegelt sein, damit eine ausgefallene SSD nicht zu Datenverlust führt. Die Größe der Log-Devices fällt kaum mehr ins Gewicht. Sun empfahl "X * 10", wobei X der Durchsatz pro Sekunde in Megabyte ist. Um also 100MB/s synchroner Schreiboperationen bearbeiten zu können, bräuchtest du ein 1GB Log-Device.
Zum Vergrößern anklicken....

hmm was hälst du von 2 mSATA Drives?

Ich habe dieses hier im Auge.

http://www.alternate.de/html/product/ADATA/SX300_mSATA_SSD_64_GB/1016713/?

lesen / schr.: 485 / 550 MB/s

Passende PCIe Aufnehmer kosten ca 70 €. Also wenig. Weitere Platten passen nicht mehr ins Gehäuse.
 
Also zu dem Gerät selbst kann ich nichts sagen, aber von den technischen Daten her klingt es gut. 65.000 IOPS (und die sind beim Log-Device wesentlich wichtiger als stumpfer Datendurchsatz) sind schon eine Hausnummer. Selbst, wenn man nur zweidrittel des Wertes erreicht.
 
Der Durchsatz des Logdevices ist durchs Bandbreitelatenzprodukt begrenzt. Deswegen machen auch SLC SSDs sinn. Das ZIL schreibt immer mit leider Queuelänge von 1 d.h. es erreicht nur dann die Peak IOPS, wenn genug nebenläufige Writer zur Verfügung stehen um die Blocksize des ZIL groß genug zu machen die Bandbreite der SSD aus zu schöpfen. IIRC kommt eine Intel 520 120GiB nicht über 8k IOPS als ZIL, wegen der Latenz der sync writes.
 
Normalerweise habe ich keine Probleme dem Forum zu folgen. Aber bei dem ZFS Zeug steige ich vollkommen aus.

Ist es wirklich wert sich mit all dem Voodoo zu beschäftigen?
 
Wäre dann eine 20 GB Intel 311series mSATA SSD der anderen SSD dann überlegen?

Random Write (4KB) 3300 IOPS
Random read (4KB) 37000 IOPS
 
Kamikaze schrieb:
Normalerweise habe ich keine Probleme dem Forum zu folgen. Aber bei dem ZFS Zeug steige ich vollkommen aus.

Ist es wirklich wert sich mit all dem Voodoo zu beschäftigen?
Zum Vergrößern anklicken....

Ja mein Budget ist klein. Aber ich bin überzeugt das ich mit weniger wie 15000 € ein Enterprise Class Backup-System aufbauen kann und ich habe mir fest vorgenommen das auch zu tun.
Zudem habe ich einen Windows Dienstleister dem ich regelmässig aus meinem Budget bezahlen muss. Wenn ich das Projekt erfolgreich verwirkliche habe so hoffe ich jedenfalls genug Munition um aus stabieler Position diesen Zustand zu ändern.
Dann laufen nur noch die Faktura ein paar kleine Dienste und einige Clients mit Windows. Es wird mehr InHouse gemacht was meine Position weiter festigt und der Budgetdruck sinkt weil dann ein fünfstelliger Betrag übers Jahr besser verwendet werden kann.
 
Kamikaze schrieb:
Normalerweise habe ich keine Probleme dem Forum zu folgen. Aber bei dem ZFS Zeug steige ich vollkommen aus.

Ist es wirklich wert sich mit all dem Voodoo zu beschäftigen?
Zum Vergrößern anklicken....

Danke Kamikaze :) mir geht es nicht anders: Vermutlich muß man sich den Zauber antun, wenn man es mit sehr vielen Daten und Clients zu tun hat. Ich glücklicherweise nicht :)
 
Wie Kamikaze auch, bin ich bei dem ganzen ZFS-Geraffel ausgestiegen. Ich will nur kurz anmerken, das TimeMachine übers Netzwerk auch nicht gerade eine Ausgeburt an Geschwindigkeit ist.
Es ist lahm, da beißt die Maus keinen Faden ab.

c.
 
Man kann ZFS auf zwei verschiedene Weisen sehen:

1. ZFS ist einfach ein Dateisystem. Das ist die Sichtweise, die sich für die meisten Nutzer anbietet. Sie haben ihre Platte, machen "zpool create" und sind glücklich. Sie müssen lediglich beachten, dass sie bei 4k-Platten das korrekte Alignement nutzen und das sie genügend RAM haben. Wobei da 4GB für den normalen Einsatz schon ausreichend sind, mehr schadet aber nicht.

2. ZFS als Storage-System für wirklich große Datenmengen. Das ist das, was minimike macht. Dort spielt dann, wie bei jedem großen Storage-Pool, die interne Funktionsweise mit hinein. Man muss das nicht im Detail verstehen, kann es ohne wirklich tiefgehendes Hintergrundwissen über Datenlagerung und die dort eingesetzten Algorithmen auch nicht. Aber man sollte sich klarmachen, wie ZFS grob aufgebaut ist und wie es die Daten organisiert. Dann werden Dinge wie Log-Devices, Cache-Device und so weiter recht klar. Um auch für Personen, die nicht die Zeit oder den Willen haben sich dort einzulesen, aus der Alchemie etwas Koordiniertes zu machen, hat die Solaris-Fraktion den "Best Practices Guide" geschrieben: solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide Leider lässt er sich gerade in Detailfragen nicht 1:1 auf FreeBSD übertragen. Es wäre daher schön, wenn irgendjemand mal eine FreeBSD-Version schreiben würde. :)

Aber um das Problem zurückzukommen: Die 311 Serie von Intel kenne ich persönlich nicht. Ich verbaue allerdings in ZFS-Servern die Intel 313 20GB. Darauf liegen jeweils 4GB Log-Device und der Rest ist Cache-Device. Diese Server sind aber kleiner als dein Projekt, mit maximal 8 Platten.
 
Hallo Yamagi

Die Intel 313 hat dann MLC Chips? Weil mit geringen Verständniss erscheint mir dann das Modell von Adata doch performanter als die Intel 311.

Alternate ist unser Hausdealer. Der Erwerb woanders oder ein neues Kundenkonto ist zumindest bei mir immer ein gewisser Workflow. Darum kaufe ich am liebsten dort weil es für mich schnell und einfach geht. Zumindest ich will das beste für meine Firma.
 
Also Stell dir das ZIL so vor: In einer Endlosschleife werden die (Meta-)Datenänderungen erfasst und synchron weg geschrieben. Dies geschieht ohne Optimierungen die NCQ und der gleichen zulassen. Somit die Anzahl der Operationen begrenzt durch die Laufzeit dieser blockierenden I/O. Dies zu optimieren würde den Code noch komplizierter machen und anfälliger für verlogene Hardware und Firmware. Mehr als mirrored ZIL VDEV pro Pool macht nur dann Sinn, wenn der sync write throughput der SSDs des ZILs erreicht wird, weil zwischen den ZIL VDEVs round-robin Scheduling betrieben wird. Das einzige was man machen kann um diese Schleife zu beschleunigen d.h. mehr effektive IOPS zu bekommen ist stable Storage mit geringerer Latenz zu nehmen. Mögliche Lösungen wären hier geeignete SLC SSDs statt MLC SSDs oder gar RAM Disks.
 
minimike schrieb:
Die Intel 313 hat dann MLC Chips? Weil mit geringen Verständniss erscheint mir dann das Modell von Adata doch performanter als die Intel 311.
Zum Vergrößern anklicken....
Nein, es sind SLC-Chips. Ein Bit pro Zelle.Daher haben die Chips relativ geringe Kapazität, was die SSD teuer macht. Zur AData kann ich leider nichts sagen.
 
Hi

Ich habe das jetzt so am laufen.


Code: 
mightychicken# zpool status
  pool: brainpool
 state: ONLINE
  scan: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	brainpool   ONLINE       0     0     0
	  raidz1-0  ONLINE       0     0     0
	    da0     ONLINE       0     0     0
	    da1     ONLINE       0     0     0
	    da2     ONLINE       0     0     0
	    da3     ONLINE       0     0     0
	  raidz1-1  ONLINE       0     0     0
	    da4     ONLINE       0     0     0
	    da5     ONLINE       0     0     0
	    da6     ONLINE       0     0     0
	    da7     ONLINE       0     0     0
	  raidz1-2  ONLINE       0     0     0
	    da8     ONLINE       0     0     0
	    da9     ONLINE       0     0     0
	    da10    ONLINE       0     0     0
	    da11    ONLINE       0     0     0
	  raidz1-3  ONLINE       0     0     0
	    da12    ONLINE       0     0     0
	    da13    ONLINE       0     0     0
	    da14    ONLINE       0     0     0
	    da15    ONLINE       0     0     0

errors: No known data errors


In der loader.conf habe ich noch folgendes Eingetragen

Code: 
hint.sio.1.flags="0x30"
boot_multicons="YES"
boot_serial="YES"
comconsole_speed="57600"
console="comconsole,vidconsole"

kern.ipc.semmni=4096
kern.ipc.semmns=8192
kern.ipc.semmnu=4096
kern.maxfiles=102400
kern.maxfilesperproc=65536
net.inet.tcp.sendspace=65536
net.inet.tcp.recvspace=65536

geom_mirror_load="YES"
geom_nop_load="YES"
# ipmi_load="YES"
fdescfs_load="YES"
linprocfs_load="YES"
linsysfs_load="YES"
tmpfs_load="YES"
linux_load="YES"


vfs.zfs.prefetch_disable=0
# available memory divided by eight
vfs.zfs.arc_min="12288M"
# available memory multiplied with 1.5 subtracts 512
vfs.zfs.arc_max="48640M"
# available memory multiplied with 2
vfs.zfs.arc_max="192G"
# available memory multiplied with 1.5
vm.kmem_size="144G"

Die Files schaufeln jetzt deutlich schneller von A nach B.

Allerdings bin ich nicht so versiert im Kernel Tunen. Habt ihr da noch Anregungen dazu? Ob ich Budget für ein ZIL bekomme kläre ich morgen mit meinem Chef ab.
 
Zuletzt bearbeitet:
Grundsätzlich muss man nichts "tunen", denn FreeBSDs Autotuning funktioniert gut. Man sollte also nur an Knöpfen drehen, wenn es konkrete Probleme gibt und nicht blind angeblich gute Werte aus Google übernehmen:

- Der "ipc"-Kram ist dennoch nie verkehrt, gerade wenn man große Konsumenten wie z.B. PostgreSQL hat.

- "maxfiles" zu erhöhen ist dann notwendig, wenn der automatisch gewählte und recht konservative Wert nicht reicht. Schadet aber auch nicht wirklich.

- Die "tcp"-Optionen sind auch eine gute Idee, denn FreeBSDs Standardwerte sind recht gering. Gerade für sehr netzwerklastige Anwendungen.

- Der "arc" ist so eine Sache. Grundsätzlich verwaltet FreeBSD den ARC selbst und seit 8.3 und 9.0 auch ohne lange Diskussion ausreichend gut. "vfs.zfs.arc_min" macht daher keinen Sinn, das System weiß selbst am besten wie groß der ARC minimal sein muss. "vfs.zfs.arc_max" setzt du doppelt, der letzte Wert zählt. Wenn die Maschine ausschließlich als ZFS-Server dient, sollte man kein Maximum setzen und dem ARC den ganzen RAM überlassen. Wenn andere Dienste laufen, kann man dem "Back Pressure"-Algo mit einem forcierten Maximum unter die Arme greifen. Ein guter Wert ist "Zweidrittel des RAM", allerdings sind es bei dir dann schon 32 ungenutzte Gigabyte. Von daher würde ich mir in deiner Stelle überlegen, wie viel RAM deine Anwendungen im Durchschnitt brauchen, diesen Wert halbieren und von den 92 Gigabyte abziehen. Das ist dann dein "vfs.zfs.arc_max".

- Die "kmem_size" ist eine der am meisten missverstandenen Optionen im ganzen System. Sie legt fest, wie groß der virtuelle Adressraum des Kernels ist, also wie viele virtuelle Adressen Kernelsubsysteme nutzen dürfen. Unter FreeBSD/amd64 wird der Wert automatisch bestimmt und ist so groß, dass unter keinen Umständen ein Rumfummeln notwendig ist! Wenn du dort bei nur 92 Gigabyte RAM mal eben 144 Gigabyte setzt, kannst du schon jetzt Tschüß zu deinem Kernel sagen und dich auf Panics freuen. Eingreifen sollte man dort erst, wenn es konkrete Probleme gibt. Und wenn, dann bitte "vm.kmem_size_max".

Was du grundsätzlich noch mal anschauen könntest, ist die Nummer an Vnodes. "vfs.numvnodes" gibt die derzeit aktive Nummer an Vnodes an, wenn sie "kern.maxvnodes" sehr nahe kommt (weniger als 10% frei), solltest du letzteren Wert sanft erhöhen. Auf keinen Fall sollte man es präventiv machen, denn jede weitere Vnode macht das System etwas langsamer!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben