[Suche] 4port PCIe Sata-3 Controller Card

Hab ma schon gewundert ueber die hardware.

Irgendwo hatte ich gelesen das sich bei geli AES 128 und 256 nichts nehmen.
ZIL brauch ich doch nur fuer NFS soweit ich weiss. Der wird erstmal nicht genutzt, darum denke ich, kuemmer ich mich mal lieber um den l2arc.
lg
 
root> time cp ap18.mkv ap18_2.mkv

real 4m17.238s
user 0m0.016s
sys 0m7.002s

Ich hab die CPU jetzt mal auf 3.6Ghz getaktet und erreiche damit beim kopieren der knapp 10GB Datei aus dem Pool auf die SSD 2min36sec.
Die Daten auf dem Pool habe ich alle einmal neu kopiert damit sie gleichmaessig auf den 4 mirrorn sitzen
Die Datei ist jetzt auch laut zpool iostat -v 1 annaehrend gleichmaessig auf allen 4 mirrorn verteilt.
Das bottleneck ist auch nicht die SSD, da ich innerhalb der SSD noch schneller kopieren kann.
Neu ist, dass die cpu nicht mehr zu 100% ausgelastet wird. und cp erreicht jetzt in top ca. 6.5% cpu nutztung.

Das ist leider immer noch nicht das gewuenschte Ergebniss.

Mein naechster Schritt waere jetzt die Blocksize von Geli von aktuell 4096 zu erhoehen. Leider finde ich dazu keine aussagekraeftigen Benchmarks im net. Haette Jemand einen Tipp bei welcher Groesse die Blocksize noch "sicher" waere und fuer guten Durchsatz sorgen koennte?
 
hi

ich kann mir nicht vorstellen das eine blocksize vergroesserung was bringt da
die cpu noch mehr daten am stueck rechnen musss.

hinzukommt das bei neuen platten die sektor size nicht groesser als 4 k ist.

ich wuerde eher versuchen kleine bloecke zu machen damit die cpu mehr mit
dem multi core , threading arbeitet.

aber das ist nur eine vermutung.

holger
 
Vor allem sind größere Blöcke in Hinblick auf Datensicherheit so eine Sache. Ist ein Block futsch, ist er futsch. Und wenn 4k verloren gehen, ist das im Zweifel noch ertragbarer als 8k oder 16k...

Man sollte diese Top-Angaben auch nicht zu ernst nehmen. Top bildet Mittelwerte und selbst wenn man sich die rohen Werte anzeigen lässt, ist er sehr träge. Spitzenwerte erwischt man nicht. Das fällt beispielsweise bei Datenbanken auf, wo sehr kurzzeitige Spitzen limitieren. Top zeigt dann 20% Last an, da die Spitzen aber den Prozessor komplett auslasten, ist man dennoch am CPU-Limit. Bei GELI ist es nicht ganz so extrem, aber auch es hat gerade bei Metadatenoperationen eine Tendenz zu Spitzen.

Dennoch würde ich erstmal anderweitig suchen und nicht am CPU-Limit.
 
Habe ich dich missverstanden? Ich ging nun davon aus, dass die CPU nicht mehr zu 100% ausgelastet ist. Da du sie übertaktest hattest.
 
Habe ich dich missverstanden? .

Upps, Sorry mein Fehler, jetzt hab ich mich selbst verwirrt. Die Muehle laeuft wieder im Normal-zustand, da der CPU-Luefter zu laut war und das Viech steht unterm Hochbett und muss dementsprechend leise sein.
Dann hab ich jetzt dein Post im falschen Kontext gelesen.

Ich werd mir wohl demnaechst ne Wasserkuehlung holen, damit es uebertaktet laufen kann.

Aber abgesehen davon, was waeren die naechsten Schwachpunkte (ausser der CPU) die ich noch evtl. eleminieren koennte?
 
Hi,
Du könntest in die "Mühle" au oifach nen AES Crypto Beschleunigbär neistecken der von FreeBSD unterstützt wird und den dann "ackern" lassen.
Gruß Bummibär
 
Aber solche Beschleuniger sind sehr teuer und spätestens seit AES-NI ihr Geld nicht mehr wert. Auch bei Wasserkühlungen bin ich mir nicht so sicher. Die Dinger sind recht teuer und irgendwie widerstrebt mir der Gedanke an Wasser in meinem Gehäuse. Selbst wenn es in Schläuchen ist. Sinnvoller ist es vielleicht gleich einen Monat länger zu sparen und die ganze Kiste aufzurüsten. Ein modernes Mainboard mit einer Quadcore-CPU mit AES-NI und 16GB RAM. Fertig ist der kleine Rennwagen...

Aber lassen wir die CPU erst einmal außen vor. Du hast ja bereits eine SSD für ZIL und L2ARC, wenn ich es jetzt richtig im Kopf habe. Die Festplatten sind sicherlich auch hinsichtlich eines korrekten 4k-Alignement eingerichtet. Wobei das keine Auswirkungen auf die CPU-Last haben sollte. Bleibt das leidige Thema Interrupts und CCC. Beides kann man aber bei dem mvs(4) Treiber gut steuern, die Werte kommen jeweils in die /boot/loader.conf:

hint.mvs.0.msi: Kontrolliert, ob der Controller Message Signaled Interrupts nutzt. Wenn der Wert nicht auf "1" steht, auf jeden Fall einschalten. Kann aber sein, dass der Kernel danach nicht mehr bootet, wenn dein BIOS oder die Controllerfirmware spackt. In dem Fall musst du den Wert am Loader-Prompt manuell zurück auf "0" setzen.

hint.mvs.0.ccc: Schaltet "Command Completion Coalescing". Anstatt jedes fertige ATA-Kommando zu bearbeiten, werden diese erst gesammelt und dann in größeren Mengen verarbeitet. Spart Kontextwechsel und damit CPU-Leistung. Kann andererseits aber auch Dinge verzögern. Der Wert gibt die Anzahl Mikrosekunden an, die gesammelt wird. Den optimalen Wert muss man selbst austesten.

hint.mvs.0.cccc: Gibt an, wie viele Befehle maximal gesammelt werden, bis sie zur Abarbeitung geschickt werden. Dafür gilt das gleiche wie beim Hint hier drüber.

hint.mvs.0.pm_level: Aktiviert das Powermanagement. Steht auf "0" (abgeschaltet) und sollte auch dort bleiben.
 
Hi,
gibts zum LSI SAS 9211-8i schon Erfahrungswerte zwischenzeitlich auf FreeBSD 9 ?
Gruß Bummibär


also er wir andstandslos erkant und verwendet.

die platten sind via camcontrol alle ansprechbar.
die performace schein auch ok zu sein jedoch habe ich nur sata1 platten
drann die eh nicht das maximum des controllers nutzen koennen.

aber er laeuft mit zfs sauber incl gpt .

holger
 
So ich habe nun noch ein wenig Zeit gefunden an der ZFS Performance zu arbeiten. Leider haben alle Hinweise zu keinem Erfolg gefuehrt.

Ich habe jetzt mal fuer jede einzelne Platte (Samsung Spinpoint F3 HD103SJ) folgendes laufen lassen
Code:
root> diskinfo -t <device>

Dabei kommt jede HDD zu einem aehnlichem Ergebnis:
Code:
Transfer rates:
        outside:       102400 kbytes in   0.704289 sec =   145395 kbytes/sec
        middle:        102400 kbytes in   0.839586 sec =   121965 kbytes/sec
        inside:        102400 kbytes in   1.422071 sec =    72008 kbytes/sec
Das sind ca. 140MBytes/sec im Bestfall und 70MByes/sec im worst case. Alle Benchmarks im Internet liefern das selbe Ergebnis.

Dementsprechend kann ich die Festplatte an sich und den Controller als Bottleneck komplett ausschliessen.

Nun habe ich auch gelesen, dass diese Festplatten wirklich 512Byte Sektoren haben, also keine 4k drives sind.



Q.1: Die Frage ist (angenommen ich goenne dem Setup einen CPU mit AES Instruction Set): macht es Sinn die Geli Sektor Size auf 512 zu reduzieren?


Q.2: Ich habe jetzt noch gesehen, dass die HDD's nicht exakt gleich gross sind. Ich besitze einen mirror aus ada2 der auf ada4 mirrored.
Code:
ada2: 953868MB (1953523055 512 byte sectors: 16H 63S/T 16383C)
ada4: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C)
Macht es hier evtl. doch sind vorher mit gpart jeweils eine Partition auf der HDD anzulegen die exakt auf das letzte bit gleich sind und dann erst in den Pool zu packen?


Q.3: Insgesamt soll der Pool auf 6 Mirros und eine Spare HDD ausgebaut werden, alle vollverschluesselt. Koenntet ihr mir eine AMD CPU (im Desktop-Bereich) mit AES Instruction Set empfehlen, die der Aufgabe gewachsen ist.
 
Zuletzt bearbeitet:
Guten Morgen :)

lockdoc schrieb:
Die Frage ist (angenommen ich goenne dem Setup einen CPU mit AES Instruction Set): macht es Sinn die Geli Sektor Size auf 512 zu reduzieren?
Das macht zumindest auf einem Core i7 2600k keinen messbaren Unterschied. Als eher nicht.

lockdock schrieb:
Macht es hier evtl. doch sind vorher mit gpart jeweils eine Partition auf der HDD anzulegen die exakt auf das letzte bit gleich sind und dann erst in den Pool zu packen?
Nein, denn ZFS orientiert sich schon von allein an der kleinsten Platte. Das Festplatten gleich groß sein müssen, oder sogar exakt das gleiche Modell, ist bei den meisten RAID-Systemen schon seit 15 Jahren nicht mehr wahr. Du kannst es also gern so lassen.

lockdoc schrieb:
Koenntet ihr mir eine AMD CPU (im Desktop-Bereich) mit AES Instruction Set empfehlen, die der Aufgabe gewachsen ist.
Derzeit können von AMD nur die Bulldozer-Prozessoren AES-NI, sowohl als Opteron als auch als "FX". Ein Modell mit 6 Threads (BUlldozer hat keine Kerne im klassischen Sinne mehr) müsste es dann schon sein. Empfehlen ist aber so eine Sache. Einerseits bin ich AMD-Fanboy und halte den Bulldozer wesentlich besser als seinen Ruf. Gerade, wenn man anstelle schlecht parallelisierter Spiele - die leider den Kern fast aller Benchmarks bilden - richtige Software und ein Betriebssystem nutzt, was nicht mit der CPU überfordert ist. GELI ist so eine Software; FreeBSD, Linux (und eingeschränkt Windows 7 mit Patch) sind solche Betriebssysteme. Man erreicht in etwa die gleiche Leistung von mit Intel-CPUs, aber zu einem günstigeren Preis. Also wie gehabt.
Andererseits habe ich mich selbst gegen Bulldozer entschieden. Einmal, da er gerade unter Last ein Schluckspecht ist (solange man keine Untervolting-Abenteuer unternimmt) und das er eine Zicke ist. Er mag keine schlecht parallelisierte Software. Entscheident war aber, dass mein System einfach mal funktionieren sollte und ich keine Lust hatte an der Software zu hacken. amdtem(4) unterstützt den Bulldozer inzwischen, aber cpufreq(4) wohl noch nicht so wirklich.
 
Danke,
ich tendiere derzeit auch eher zu AMD, da dort die Preise wesentlich entspannter sind als bei Intel.
 
dd (/dev/zero)
Code:
root> dd bs=1M count=4096 if=/dev/zero of=test
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 61.024558 secs (70380965 bytes/sec)
Beim uebertakten auf 4Ghz halbiert sich die Zeit auf 32 Sekunden, was mich allerdings wundert is, dass die CPU nicht voll ausgelastet wird.
 
Zurück
Oben