ZFS Geschwindigkeiten normal?

hitman22

Experte
Thread Starter
Mitglied seit
14.05.2015
Beiträge
58
Hallo zusammen,

ich hab bei mir einen Solaris 11.4 Server mit 8 HDD's mit je 2TB und eine NVME SSD mit 256GB als Cache. Das ZFS Filesystem ist bereits auf der letzen Version von Solaris 11.4. Mir kommt es allerdings so vor, dass dies von der Geschwindigkeit nicht korrekt läuft. Ich hatte davor ein RaidZ2 und dort bin ich mit den 8 HDD's nur auf 40MB/s gekommen und habe es dann umgestellt, wie unten zu sehen ist.

Der Server hat folgende Austattung:
CPU: Intel Xeon 1220 V5
RAM: 16GB

Die Hosts die auf den Server zugreifen sind direkt verbunden mit 10Gbit/s und die MTU ist auf 9000 gesetzt.

Der ZFS Pool ist folgendermaßen konfiguriert (Ausgabe von zpool stauts -v):

Code:
 NAME                       STATE      READ WRITE CKSUM
        tank                       ONLINE        0     0     0
          mirror-0                 ONLINE        0     0     0
            c0t5000C500A2654DBCd0  ONLINE        0     0     0
            c0t5000C500B0BE1ADCd0  ONLINE        0     0     0
          mirror-1                 ONLINE        0     0     0
            c0t5000C50090B5A3CBd0  ONLINE        0     0     0
            c0t5000C50090B5AA92d0  ONLINE        0     0     0
          mirror-2                 ONLINE        0     0     0
            c0t5000C50090B59493d0  ONLINE        0     0     0
            c0t5000C50090D02978d0  ONLINE        0     0     0
          mirror-3                 ONLINE        0     0     0
            c0t5000C5007989D094d0  ONLINE        0     0     0
            c0t5000CCA37DC3318Dd0  ONLINE        0     0     0
        cache
          c3t1d0                   ONLINE        0     0     0

Ich habe dann mal einen Test gemacht wenn ich von einem Windows Server 2016 auf ein iSCSI Share kopiere bekomme ich ca. knapp 700MB/s und zwischendurch sinkt es dann mal 0MB/s und macht dann wieder weiter und stürzt nach ein paar Sek wieder auf 0MB/s.

Mach ich das selbe auf ein SMB Share, bekomme ich ca. 250MB/s aber auch nicht konstant und die Geschwindigkeit fällt dann und der Kopiervorgang bleibt dann auch mal stehen. Die SMB Version zwischen Windows Server und Solaris ist jeweils 3.1.1.

Kann der Unterschied zwischen iSCSI und SMB noch daherkommen, weil iSCSI block baisert ist und SMB nicht, oder sollte dort der Kopiervorgang ähnliche Geschwindigkeiten bekommen?

Die Netzwerkkaten sind in beiden Hosts Mellanox Netzwerkkarten.

Gibt es dort noch Möglichkeiten, dies etwas von der Performance besser zu machen oder ist dies normal bei der Konstellation?

Gruß

hitman22
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was sind das für Plattenmodelle?
Wie (also welcher Port oder Controller ) hängen die in der Maschine ?
Tritt das Problem auch ohne Cache auf?
Wie voll ist der Pool?

Zum Vergleich: Mein Raidz2 (6*6TB HGST Deskstar NAS) liest und schreibt sequentiell etwa mit 800 MiB/s, wenn der Pool leer ist. Ist er natürlich aktuell nicht mehr, daher aktuell eher bei 600 MiB/s. Bei 12 GB zugewiesenem Ram an die VM (FreeBSD 11.x, das ganze ist virtualisiert unter ESXI mit Passthrough der Controller). Diese Leistung wird auch problemfrei über mein 10Gbase-T (MTU auch durchgehend auf 9000) erzielt.
 
Zuletzt bearbeitet:
Von den 8 Platten müssten 6 Stück Seagate Barracuda 2TB ST2000DM001 sein, eine Seagate Exos 7E2 ST2000NM0008 und eine Seagate Exos 7E2 ST2000NM0008. Als Gehäuse habe ich das Chenbro RM23608 und von der Backplane des Gehäuses gehen diese dann auf einen LSI 1015, der mit IT Mode geflashed ist. Als Kabel verwende ich zwei Startech 1M SFF-8087 TO SFF-8643 Kabel.

Ohne Cache ist das Ergebnis bei iSCSI immer noch ähnlich wie ich bereits geschrieben habe. Bei SMB komme ich dann nur noch auf ca. 100 MB/s.
 
Die Werte sind natürlich viel zu schlecht. Selbst die alten Platten sollten ca 150 MB/s sequentiell können. Bei 4 x Mirror sollte da schon 500-600 MB/s schreiben drin sein (lokal wie übers Netz bei 10G). SMB und iSCSI sollten sich nicht so sehr unterscheiden.

Ich würde als erstes zum Vergleich einen Pool auf der NVMe anlegen und den testen.

Dann würde ich einen lokalen Benschmark laufen lassen, z.B. napp-it Menü Pool > Benchmark oder ein einfaches dd. Dabei per iostat die Plattenlast beobachten, insbesondere ob eine davon deutlich schlechtere busy oder wait Werte zeigt. Eine schwache Platte ist die wahrscheinlichste Ursache eines besonders langsamen Pools.

Ich hatte auch schon Fälle wo RAM das Problem war. Dazu zwei Tests mit je der Hälfte RAM oder anderem RAM machen. Auch eine HBA Firmware 20.000 bis 20.004 gilt als fehlerhaft.

Die Schwnkungen der Performance kommen daher dass zunächst die Schreiblast in den RAM Schreibcache geht, dann bricht es ein weil der die Daten nicht auf Platte bekommt.

Ansonsten
Ein L2Arc sollte 5x RAM bis max 10x RAM haben. Mehr macht keinen Sinn weil ansonsten zuviel vom schnelleren RAM zur Verwaltung des Cache vergeudet wird.

siehe auch Oracle Solaris 11.4 | Page 4 | ServeTheHome and ServeThe.Biz Forums
 
Zuletzt bearbeitet:
Ich habe mit napp-it mal einen DD Benchmark laufen lassen mit den Default Werten.

Dies kam dabei heraus:

Code:
Memory size: 16207 Megabytes

write 12.8 GB via dd, please wait...
time dd if=/dev/zero of=/tank/dd.tst bs=2048000 count=6250

6250+0 records in
6250+0 records out

real       35.0
user        0.0
sys         2.7

12.8 GB in 35s = 365.71 MB/s Write

wait 40 s
read 12.8 GB via dd, please wait...
time dd if=/tank/dd.tst of=/dev/null bs=2048000

6250+0 records in
6250+0 records out

real       20.0
user        0.0
sys         3.0

12.8 GB in 20s = 640.00 MB/s Read

Bei iostat sah das teilweise auch so mal aus


Code:
                     extended device statistics
device     r/s    w/s   kr/s   kw/s wait actv wsvc_t asvc_t  %w  %b
blkdev0    0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0
sd0        6.9    0.0  289.9    0.0  0.0  0.1    3.0   16.8   2  12
sd2       15.9  156.8 1330.1 124290.8  0.0  1.5    0.0    8.4   0  68
sd3        8.9  171.7  540.0 140390.5  0.0  1.7    0.0    9.3   0  83
sd4        3.0  165.8  258.1 140933.4  0.0  1.3    0.0    7.9   0  68
sd5        4.0  152.9  635.3 126702.2  0.0  1.4    0.0    8.7   0  69
sd6        2.0  165.8  254.1 135178.3  0.0  1.4    0.0    8.6   0  72
sd7        7.9  185.6  655.1 134502.4  0.0  1.7    0.0    9.0   0  79
sd8        6.9  167.7  889.4 122439.3  0.0  1.6    0.0    9.3   0  80
sd9        6.0  164.8  524.1 131399.6  0.0  1.2    0.0    7.1   0  60
sd10       0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0
sd11       0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0


Benchmark NVME SSD

Code:
Memory size: 16207 Megabytes

write 12.8 GB via dd, please wait...
time dd if=/dev/zero of=/tank1/dd.tst bs=2048000 count=6250

6250+0 records in
6250+0 records out

real       33.6
user        0.0
sys         4.5

12.8 GB in 33.6s = 380.95 MB/s Write

wait 40 s
read 12.8 GB via dd, please wait...
time dd if=/tank1/dd.tst of=/dev/null bs=2048000

6250+0 records in
6250+0 records out

real        7.7
user        0.0
sys         2.9

12.8 GB in 7.7s = 1662.34 MB/s Read

Von den Schreibwerten unterscheiden sich die NVME und die HDD's nicht groß. Sollte die NVME dort nicht mehr Geschwindigkeit bringen?


Kann es vielleicht sein, dass die 16GB RAM einfach zu wenig sind?
Ich habe mal über iSCSI auf die NVME SSD geschrieben und dort bekomme ich ca. 700MB/s bis 800MB/s.

@Trambahner

Auf dem Pool liegen momentan 687,5 GB von 6TB.
 
Zuletzt bearbeitet:
Ich würde auch mal zum lokalisieren des Fehlers mal ein dateisystem mit compression (lz4) erstellen und da Daten aus /dev/null reinkopieren, am besten große Blöcke. Geht die Transferrate da nicht in die höhe würde ich mir Speicher und CPU mal genauer ansehen.

Ups gerade erst gesehen, dass du kein Z2 sondern striped Mirrors fährst. Das erklärt natürlich warum iostat ca. 2x deine netto datenrate schreibt.
 
Zuletzt bearbeitet:
Wenn man das Ergebnis auf die vdev(Platten verteilt, landet man bei ca 90 MB/s pro Platte. Das ist ok für alte Platten. Lesen geht doppelt so schnell da ZFS von beiden Mirrors gleichzeitig liest. Auch die Plattenauslastung ist ausreichend gleichmäßig. Der Pool ist also soweit ok obwohl man sieht dass die Platten nicht gleichschnell sind und immer die langsamste die Performance bestimmt. Unklar bleibt warum der Zugriff über iSCSI/SMB so viel langsamer ist.

Lese/ Schreibraten von Windows sollten damit (iSCSI und SMB) mit 10G zwar geringer aber nicht extrem darunter liegen so wie man das mit der NVMe sieht. Die iSCSI Werte von der NVMe lassen auch den Schluß zu, dass die Netzseite nicht das Problem ist.

Insgesamt kann man jetzt folgendes machen
- neue Platten. Die guten NVMe Werte zeigen, dass die alten Platten das Hauptproblem sind

- mehr RAM. Da RAM bei ZFS als Schreib und Lesecache genutzt wird, kann man mit mehr RAM langsame Platten ausgleichen
Die extrem schlechten Werte des Plattenpools lassen sich aber nicht ausbügeln

- Ich gehe davon aus dass sync deaktiviert is. Ansonsten wären Schreibraten um 40MB/s völlig normal
Wenn man wegen der besseren Datensicherheit sync aktivieren möchte, hilft ein Slog - vor allem eine Intel Optane ab 800P

- Dedup ikann auch eine Performancebremse sein wenn der RAM nicht ausreicht. Mit 16GB immer deaktivieren. Mit Open-ZFS gibt es kaum ein sinnvolles Anwendungsszenario für dedup. Solaris 11.4 mit dedup2 soll da zwar erheblich besser sein, dennoch meist auschalten.

- Bei Windows die neuesten Treiber benutzen (die Windows beiliegenden sind oft veraltet). Bei Intel habe ich mit neueren Netzwerk-Treibern teils erheblich bessere Werte gesehen. Auch brachte bei mir int_throtteling=off in den Windows Netzwerkeinstellungen erheblich bessere Werte bei 10G.


zur NVMe
Eine NVMe hat eine sehr schnelle Anbindung an das System. Dennoch ist es Flashspeicher (bis auf Optane) mit allen damit zusammenhängenden Problemen wie sektorweises Löschen vor Schreibem, Notwendigkeit von Trim/ Garbage Collection und sinkende Performance mit Füllgrad und Schreibdauer. Vor allem billige Desktop NVMe erreichen da bei weitem nicjht das Potential guter NVMe (hier wieder Intel Optane ab 800P als Maßstab)


Hilfreich wäre ein Screenshot des napp-it Menüs Pools > Benchnarks
Das ist ein Mix aus sequentiellen und random Filebench Tests jeweils mit und ohne sync. Damit läßt sich der Pool besser beurteilen als mit dd. Vielleicht mal diese Benchmarkserie durchlaufen lassen und das Ergebnis als Screenshot posten.

Zum Einordnen der Ergebnisse kann man das mit https://napp-it.org/doc/downloads/optane_slog_pool_performane.pdf vergleichen. Da habe ich meine Ergebnisse dieser Benchmarkserie mit verschiedener Plattenarten, mit unterschiedlich RAM und mit verschiedenen Slog Platten von einfacher SSD über Enterprise SSD bis zu Optane zusammengefaßt. Wichtigster Basiswert ist da Singlestreamwrite mit und ohne Sync weil da der Lesecache nicht so stark verfälscht.

Die meisten Test sind mit OmniOS (freier Solaris Fork) erstellt. Die Solaris Werte waren durchgängig besser, kann ich aber nicht beifügen wegen Oracles Lizenzbedingungen.
 
Zuletzt bearbeitet:
Ich hatte mal das gleiche Phänomen bei einem RaidZ, weil eine Platte einen Hardware-Fehler hatte (mehrere defekte Sektoren). Mein Tipp: Mach mal einen SMART-Test (short self test sollte reichen) und prüfe, ob die Platten alle ok sind.
 
Ich habe den Pool jetzt mal mit den Benchmarktest nochmal getestet.

Code:
Bennchmark filesystem: /tank/_Pool_Benchmark
begin test 3 ..randomwrite.f ..
begin test 3sync ..randomwrite.f ..
begin test 4 ..singlestreamwrite.f ..
begin test 4sync ..singlestreamwrite.f ..

set sync=disabled
begin test 7 randomread.f ..
begin test 8 randomrw.f ..
begin test 9 singlestreamread.f ..
pool: tank

	NAME                       STATE      READ WRITE CKSUM
	tank                       ONLINE        0     0     0
	  mirror-0                 ONLINE        0     0     0
	    c0t5000C500A2654DBCd0  ONLINE        0     0     0
	    c0t5000C500B0BE1ADCd0  ONLINE        0     0     0
	  mirror-1                 ONLINE        0     0     0
	    c0t5000C50090B5A3CBd0  ONLINE        0     0     0
	    c0t5000C50090B5AA92d0  ONLINE        0     0     0
	  mirror-2                 ONLINE        0     0     0
	    c0t5000C50090B59493d0  ONLINE        0     0     0
	    c0t5000C50090D02978d0  ONLINE        0     0     0
	  mirror-3                 ONLINE        0     0     0
	    c0t5000C5007989D094d0  ONLINE        0     0     0
	    c0t5000CCA37DC3318Dd0  ONLINE        0     0     0


hostname                        SVLST01  Memory size: 16207 Megabytes
pool                            tank (recsize=128k, compr=off, readcache=all)
slog                            -
remark                           


Fb3 randomwrite.f               sync=always                     sync=disabled                   
                                172 ops                         433 ops
                                34.399 ops/s                    86.595 ops/s
                                10664us cpu/op                  4079us cpu/op
                                28.9ms latency                  11.5ms latency
                                0.2 MB/s                        0.6 MB/s

Fb4 singlestreamwrite.f         sync=always                     sync=disabled                   
                                188 ops                         1546 ops
                                37.598 ops/s                    309.184 ops/s
                                21892us cpu/op                  2090us cpu/op
                                26.1ms latency                  2.5ms latency
                                37.4 MB/s                       309.0 MB/s
________________________________________________________________________________________
 
read fb 7-9 + dd (opt)          randomread.f     randomrw.f     singlestreamr
pri/sec cache=all               471.2 MB/s       2.0 MB/s       217.6 MB/s                    
________________________________________________________________________________________

Würde es hier sonst vielleicht auch Sinn machen, die NVME SSD durch eine Optane 800 zu ersetzen und diese dann als Cache zu benutzen und eventuell noch ein 8 GB RAM Riegel dazu?

Ich habe auch mal einen Short Selftest gemacht, aber es scheint so als ob sich dieser nie beendet. Unter Smart Health steht bei allen Platten PASSED. Dedub und Sync habe ich deaktiviert.
 
Die Hauptfrage ist doch was du damit vorhast.

Der Pool aus vier Mirrors und 10G legt nahe dass es etwas mit Performance werden soll. Das wird aber mit den Platten nix. Sowohl deren sequentielle Performance (ca 75 MB/s je Platte schreibend) wie auch die iops (40 iops) und random Werte sind schlecht.

Man könnte den RAM erhöhem. Dadurch würden mehr Lesezugriffe aus dem Ramchache bedient werden und auch ein größerer Ram-Schreibcache zur Verfügung stehen. Richtig schnell wird es aber nicht werden. Mehr RAM ist aber immer gut.

Der Pool wäre gut geeignet für ein Backupsystem oder einen einfachen Filer, dann aber eher als Raid-Z2 wegen der besseren Kapazität. Das 10G Netz kann mad damit aber nicht auslasten.

Was soll den genau damit gemacht werden?
 
Ich lasse auf dem System hauptsächlich VM's laufen mit XCP-ng. Mit dem RAIDZ2 kam mir nur die Geschwindigkeit von 40MB/s komisch vor, aber wenn mit den HDD's nicht mehr möglich ist, dann ist das halt so. Kannst Du mir Platten empfehlen, die einigermaßen Performance geben oder zu mindestens besser sind als meine jetzigen? Mit dem jetzigen RAID war ich halt der Meinung, dass dies etwas mehr Performance gibt, als das RAIDZ2.
 
Das stimmt ja auch.
Während sequentiell der Multi-Mirror und ein Z2 ähnlich schnell sind, sieht es bei den für VMs so wichtigen iops ganz anders aus. Ein Z2 hat die iops einer Platte da für jedes i/o alle Platten positioniert werden müssen. So hat das Z2 z.B. beim Schreiben ca 40 iops. Ein 4 fach Raid-10 dagegen 160 iops (4 vdev x 40 iops).

Für VMs kommt erschwerend dazu, dass da sync write unabdingbar ist wenn man nichr möchte dass ein Gast-Dateisystem bei einem Absturz beim Schreiben korrupt wird. ESXi über NFS möchte per default sync write. Ich vermute dass Xen das ähnlich möchte. Das Multi Raid-10 macht 37 MB/s sync write. Ein Z2 wird da eher bei unter 10 MB/s landen. Eine Optane 800P als Slog würde dafür sorgen dass der Einbruch zu nonsync (309 MB) gering wird. Ein L2Arc Cachelaufwerk dagegen bringt eher viel weniger als mehr RAM.

Man muss aber sehen dass eine der Platten 40 iops hat, eine Desktop SSD bei Dauerschreiben ca 5000 iops, eine Enterprise SSD vielleicht dabei 40000, eine NVMe dann bis zu 100000, die Intel Optane ab 800P sogar 500000.

Da wird schnell klar dass ohne SSD keine Performance für VM Storage möglich ist. Wenn 256 GB für VMs reichen, würde ich einen NVMe Mirror Pool für VMs machen (die gleiche nochmal kaufen) und den Diskpool für Backup und Filerdienste nehmen.
 
Kannst du mal die Smart-Infos von allen Platten posten? Z.B. für /dev/sdc:
Code:
sudo smartctl -a /dev/sdc

Vielleicht ist auch die Platte ok und ein Kabel hat ein Problem (hatte ich auch schon).
 
Ich habe die SMART Werte der Platten mal als .txt Datei angehangen. Die Kabel selber sind erst ca. 2 Wochen alt, die von der Backplane zum LSI 1015 gehen, im alten Gehäuse mit anderen Kabeln, war die Performance aber auch nicht besser, damit müssten die Kabel nicht schuld sein.

Ich habe in napp-it auch nochmal einen SMART Test gemacht und dort ist eine Platte auf Error. Das Ergebnis ist auch in der txt Datei ganz unten zu finden.

@gea

Die NVME SSD wäre zu klein für die VM's da diese schon fast die ganzen 600GB allein wegnehmen auf dem Pool, deswegen liegen diese auch auf den HDD's. Ich denke das wahrscheinlich hauptsächlich die Desktop Platten das verlangsamen, weil diese ja eigentlich nicht für sowas ausgelegt sind. Sync habe ich dort immer ausgemacht, weil das dann schon bei einer Installation z.B. von Debian deutlich spürbar gewesen ist, wenn das lief, dass die Installation wesentlich länger gedauert hat, obwohl die normalerweise in vielleicht 5 - 10 Min fertig ist.
 

Anhänge

  • smart.txt
    47,5 KB · Aufrufe: 159
Da haben wir doch den Übeltäter... 20 Fehler sind schon heftig... UNC weist (für mein Laienverständnis) auf einen UNCORRECTABLE Plattenerror hin, siehe https://techoverflow.net/2016/07/25/how-to-interpret-smartctl-messages-like-error-unc-at-lba/:
The error message now tells us than an error called UNC occured at this LBA. UNC is shorthand for UNCorrectable, which means the data which has been read from the hard drive at this LBA was damaged and could not be corrected.

Mein Rat: Tausch die defekte Platte aus. ZFS ist sehr empfindlich bei sowas. Ich bin ziemlich sicher, das du nach dem Austausch diese "Schwankungen" der Performance nicht mehr hast. Schau ob du noch Garantie hast, dann gibts Gratis-Ersatz bei Seagate unter Angabe der Seriennummer, aber es sieht bei dem Alter (30000 Stunden) nicht so aus als wäre das noch möglich.

Code:
Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST2000DM001-1ER164
LU WWN Device Id: 5 000c50 07989d094
Firmware Version: CC25
User Capacity:    2,000,398,934,016 bytes [2.00 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ACS-3 T13/2161-D revision 3b
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Sep 15 13:04:34 2018 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
...
Error 20 occurred at disk power-on lifetime: 29134 hours (1213 days + 22 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 d8 5a dd 01  Error: UNC at LBA = 0x01dd5ad8 = 31283928
 
Zuletzt bearbeitet:
Dann werde ich mir mal eine neue Platte bestellen und diese mal tauschen. Kannst Du mir dort ein bestimmtes Modell empfehlen oder soll ich mir dann wieder eine Seagate Enterprise Platte holen, wie ich schon eine habe?

Danke.
 
Kommt darauf an. Es sollte auf jeden Fall eine 7200er sein, da die vorhandenen auch 7200er sind. Ich persönlich bin ein Fan von HGST Ultrastar Platten, aber die werden recht warm - wenn dein System ohnehin keine Hitzeprobleme hat, macht das nix, aber ein Restrisiko bleibt. Ich würde vermutlich einfach die gleiche bestellen, sofern verfügbar... eine 2TB-Platte neu mit Garantie zu bekommen, dürfte aber nicht so einfach sein, bei Amazon gibt es schon viele Rezensionen wo eine gebrauchte Platte als neu verkauft wurde.

Falls du gebraucht kaufen solltest, achte auf mindestens noch 6 Monate Garantie und verlass dich nicht auf diese Crystal Disk Mark Screenshots mit "Zustand: Gut"... die einzig verlässlichen Werte liefert ein Smart-Test, z.B. über GSmartControl für Windows oder den schon besprochenen Short Self Test unter Posix-Systemen.
 
Zuletzt bearbeitet:
Ich werde wahrscheinlich dann wieder eine Seagate Exos 2TB ST2000NM0008 Festplatte holen oder kannst Du mir von der HGST eine bestimmte Festplatte empfehlen? Bei Google bin ich immer auf eine HGST Ultrastar 7K3000 gestoßen, wenn ich eine mit 2TB gesucht habe.
 
Wie gesagt: Ich bin kein Experte für Platten aber ich denke die HGST Ultrastar 7K3000 kann man bedenkenlos kaufen, wenn sie neu ist oder gebraucht noch Garantie hat. Es ist ja auch nicht zu 100% klar, ob der Austausch dein Problem löst, daher wäre eine Option auf Rückversand innerhalb von 14 Tagen sicher nicht schlecht.

Das Preis-Leistungs-Verhältnis ist bei so kleinen Platten leider grausig, aber da kann man nix dran machen, du willst ja sicher nicht alle tauschen.
 
Tauschen möchte ich jetzt nicht alle, ist jetzt nur mal zum Test, ob das was bringt oder nicht. Habe mir mal eine Hitachi HGST Ultrastar 7K6000 mit 2TB bestellt für 40€. Die ist zwar mit SAS angegeben aber die Backplane und der Controller sollten dies wohl können. Allerdings wird dort der Controller mit 6 Gb/s limitieren und die Platte soll wohl 12Gb/s können.
 
Ich habe die neue Platte heute erhalten und eingebaut. Ich habe auch nochmal einen normalen DD Benchmark gemacht und diese Ergebnisse erhalten:

Code:
Memory size: 16207 Megabytes

write 12.8 GB via dd, please wait...
time dd if=/dev/zero of=/tank/dd.tst bs=2048000 count=6250

6250+0 records in
6250+0 records out

real        3.8
user        0.0
sys         2.1

12.8 GB in 3.8s = 3368.42 MB/s Write

wait 40 s
read 12.8 GB via dd, please wait...
time dd if=/tank/dd.tst of=/dev/null bs=2048000

6250+0 records in
6250+0 records out

real        0.9
user        0.0
sys         0.9

12.8 GB in 0.9s = 14222.22 MB/s Read

Ich denke mal dass die Werte nun so in Ordnung sind?
 
Platten machen bestenfalls (aktuelle POlatten hoher Dichte, nicht die alten 2TB Platten)
ca 250 MB/s. Für eine einzelne Platte ist es fast egal ob 3G, 6G oder 12 (bis auf Plattencache).

Beim Schreiben auf einen Mirror kann man höchstens diesen Wert erreichen.
Bei 4 Mirrors im Raid-0 also bestenfalls 1 GB/s, realistischerweise eher gut die Hälfte.
Beim Lesen kann der Wert theoretisch doppelt so groß sein (ZFS liest von beiden Mirrorhälften)

Die Werte zeigen nun
- es ist toll was Solaris und ZFS mit seinem rambasierten Schreib-Lesecache erreicht
(zumindest wenn die Daten nicht erheblich größer sind als der RAM).

Schreibwert ist wohl ein Mix aus Cache und Plattenperformance.
Lesewert iist weitgehend Ramcache.

- es gibt aber kein Problem mehr wie vorher als die Performance massiv eingebrochen ist.
Vielleicht nochmal Pools > Benschmark posten. Vor allem der sequentielle sync-Wert zeigt wirklich was Sache ist.
 
Irgendwie scheint bei mir der Benchmark test nicht korrekt zu laufen bzw. der Browser scheint dann bei processing, please wait stehen zu bleiben. Im Google Chrome kommt er bis zu Schritt 4 und macht dann nichts mehr und im Edge bleibt er nur bei processing, please wait zu stehen. Im Hintergrund scheint aber wohl doch irgendwie etwas zu passieren. Ich habe mal einen Screenshot aus Grafana angehängt, was dort über SNMP aufgezeichnet wurde. Weiß aber nicht, inwiefern das vergleichbar ist. Die Aufzeichnung ist von den letzten 15 Min.
 

Anhänge

  • disk_graf.PNG
    disk_graf.PNG
    39,1 KB · Aufrufe: 107
Die Ergebnisse werden angezeigt wenn alle Tests durchgelaufen sind. Bei etwas langsameren Systemen kann es vorher zu einem Webserver/CGI Timeout kommen. Da der wichtigste Resr Sequentielles Schreiben ist, kann man den Read-test auf einen der schnelleren micro Varianten setzen und basic und dd auf jeden Fall weglassen.

Die Test-Dafaults sind für schnelle Systeme.
 
@gea

Warum bricht eigentlich bei ZFS die Performance derart ein (nahezu 0 Übertragung), schon wenn nur eine Platte einen SMART-Fehler aufweist (bei mir war es tatsächlich nur ein Error, der zu einem kompletten Einbruch der Performance geführt hat)?

Von anderen Dateisystemen kenne ich das so nicht (was ja aber auch klar ist...)
 
Zuletzt bearbeitet:
Mein Tipp, beim Controller schauen ob du Write Back oder Write Through aktiviert hast.
Beim Write Through wird direkt auf die Platten geschrieben, während es beim Write Back erst in den Cache (sprich Speicher deines NAS/SAN/PC) geschrieben wird und dann davon auf die Platten verteilt geschrieben wird.
Also auf Write Back einstellen... und es sollte funzen...


Hab ein ähnliches Model des LSI Controllers und hatte mich auch gewundert, als er los legte mit knapp 800 Mbit/s und kurz danach runter auf 1Kbit/s daher zu wackeln.
Bis ich diese Einstellung fand hatte ich mir beinahe ne Glatze gerauft... ;)
 
@BadBigBen: Der LSI Controller läuft bei mir im IT Mode und dort konnte ich keine solche Einstellung finden. Diese Einstellungen kenne ich nur, von einem richtigen RAID Controller, aber danke für den Hinweis.

@gea:

Ich habe den Benchmark Test nochmal ausgeführt und andere Einstellungen genommen, aber es läuft wohl wieder auf einen Timeout:
Das war die letzte Meldung die mir angezeigt wurde:
Bennchmark filesystem: /tank/_Pool_Benchmark
begin test 3 ..randomwrite.f ..
begin test 3sync ..randomwrite.f ..

Die Einstellungen die ich gemacht habe, habe ich mal als Screenshot angehängt.
 

Anhänge

  • benchmark.PNG
    benchmark.PNG
    29,7 KB · Aufrufe: 105
@BadBigBen: Der LSI Controller läuft bei mir im IT Mode und dort konnte ich keine solche Einstellung finden. Diese Einstellungen kenne ich nur, von einem richtigen RAID Controller, aber danke für den Hinweis.

@gea:

Ich habe den Benchmark Test nochmal ausgeführt und andere Einstellungen genommen, aber es läuft wohl wieder auf einen Timeout:
Das war die letzte Meldung die mir angezeigt wurde:
Bennchmark filesystem: /tank/_Pool_Benchmark
begin test 3 ..randomwrite.f ..
begin test 3sync ..randomwrite.f ..

Die Einstellungen die ich gemacht habe, habe ich mal als Screenshot angehängt.

Wenn das System langsamer ist, lediglich den Singlestreamwrite belassen, alle anderen auf einen schnellen filemicro setzen (Ich werde eine skip Option bei den Tests einbauen). Insbesondere die Sync Write Tests können bei einem normalen Plattenpool zu lange dauern (Die sind aber gerade wichtig um die random Performance zu beurteilen)
 
Jetzt hat der Benchmarktest funktioniert. Danke für den Hinweis mit den Tests.

Code:
Bennchmark filesystem: /tank/_Pool_Benchmark
begin test 3 ..singlestreamwrite.f ..
begin test 3sync ..singlestreamwrite.f ..
begin test 4 ..singlestreamwrite.f ..
begin test 4sync ..singlestreamwrite.f ..

set sync=disabled
begin test 7 filemicro_rread.f ..
begin test 8 filemicro_seqread.f ..
begin test 9 filemicro_statfile.f ..
pool: tank

	NAME                        STATE      READ WRITE CKSUM
	tank                        ONLINE        0     0     0
	  mirror-0                  ONLINE        0     0     0
	    c0t5000C500A2654DBCd0   ONLINE        0     0     0
	    c0t5000C500B0BE1ADCd0   ONLINE        0     0     0
	  mirror-1                  ONLINE        0     0     0
	    c0t5000C50090B5A3CBd0   ONLINE        0     0     0
	    c0t5000C50090B5AA92d0   ONLINE        0     0     0
	  mirror-2                  ONLINE        0     0     0
	    c0t5000C50090B59493d0   ONLINE        0     0     0
	    c0t5000C50090D02978d0   ONLINE        0     0     0
	  mirror-3                  ONLINE        0     0     0
	    c12t5000CCA25E3D8B1Dd0  ONLINE        0     0     0
	    c0t5000CCA37DC3318Dd0   ONLINE        0     0     0


hostname                        SVLST01  Memory size: 16207 Megabytes
pool                            tank (recsize=128k, compr=off, readcache=all)
slog                            -
remark                           


Fb3 singlestreamwrite.f         sync=always                     sync=disabled                   
                                155 ops                         3503 ops
                                30.998 ops/s                    700.565 ops/s
                                12883us cpu/op                  1317us cpu/op
                                31.9ms latency                  1.0ms latency
                                30.8 MB/s                       700.4 MB/s

Fb4 singlestreamwrite.f         sync=always                     sync=disabled                   
                                155 ops                         2231 ops
                                30.998 ops/s                    446.177 ops/s
                                7783us cpu/op                   1058us cpu/op
                                32.1ms latency                  0.2ms latency
                                30.8 MB/s                       446.0 MB/s
________________________________________________________________________________________
 
read fb 7-9 + dd (opt)          filemicro_rread. filemicro_seqr filemicro_sta
pri/sec cache=all               64.0 MB/s        6.2 GB/s       0.0 MB/s                      
________________________________________________________________________________________

Ich denke jetzt sieht es bei den Werten ohne Sync etwas besser aus als beim letzten mal. Allerdings habe ich den Benchmark laufen lassen, als die VM's liefen, vielleicht sollte ich die auch mal auschalten und dann nochmal testen.
 
Die anderen VMs (sofern die nicht massiv CPU abziehen, sind egal).
Mit Pass-through hat man ja eine feste RAM-Zuordnung. Da können die anderen VMs nichts wegnehmen.

Die Werte sind wie zu erwarten. Solange das nicht im Realbetrieb einbricht ist das ok. 30 MB/s sync sind natürlich wenig. Da würde ein gutes Slog deutlich was bringen. Man könnte die NVMe (sofern die powerloss protection hat oder wenigstens unkritisch ist) als Slog nutzen. Eine Optane NVMe ab 800P wäre so gut, dass man die sogar als Slog + L2Arc + Bootlaufwerk + VMs nutzen kann.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh