Bottleneck und Netatalk

[minimike]

Zitat von Kamikaze

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?

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.

[Elwood]

Zitat von Kamikaze

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?

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

[crotchmaster]

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.

[Yamagi]

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.

[minimike]

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.

[Crest]

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.

[kira12]

Hallo Crest,

schreibst du mit am ZFS Code?

Gruß ré

[Yamagi]

Zitat von minimike

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.

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.

[minimike]

Hi

Ich habe das jetzt so am laufen.

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

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.

[Yamagi]

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!

[minimike]

OK Danke die Yamagi

Ich habe jetzt bis auf vfs.zfs.arc_max RAM Parameter wieder draussen.

um die 200 € für die mSATA sind in der Verhandlung. Neben diverser anderer Hardware.

[peterle]

Zitat von minimike

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.

Ohne deinen Plan umschmeißen zu wollen - behalte AMANDA zumindest im Hinterkopf bei deinen Testereien.