Vilken SSD som cache till raid?

Permalänk
Medlem
Skrivet av kai:

Synkron skrivning är långt ifrån lika snabbt som den asynkrona skrivningen i dessa tester. Jag kan tänka mig at dessa SSDer inte nyttjar sin DRAM-cache (då dessa konsument-SSD:er saknar power loss protection) när man ber de skriva synkront.

Aah.. bra poäng.
Är ju bara de som har kondensatorer som verkligen gör denna nivån.

Skrivet av kai:

Bättre att partitionera så lite som möjligt och nödvändigt när man inte har stöd för TRIM. Ju mer "spare" via over provisioning desto bättre wear leveling. Storleken för partitionen på en SLOG behöver i regel inte vara mer än dubbelt så stor som skriv-cache i RAM (FreeNAS default är 1/8 av RAM) eller så mycket som din pool hinner med att skriva på säg 10 sekunder.

Som sagt, disken klarar av det. Finns ingen poäng ur diskens synpunkt att göra göra så stor OP, när 50% garanterar att där är låg WAf och garanterat lediga celler. Det är ju därför jag länkade dig dessa tester som visar att även i extrema situationer, klarar den av detta.

På sämre SSDer, kan jag dock hålla med. Men då kommer ju nästan frågan om det verkligen är lönt att ens offra en 850 PRO för detta jobb, om du ändå ska ta till marginaler som hade gjort sämre TLC (850 EVO) diskar möjliga till det med 8GB/250GB.

Sen om du inte behöver mer... okej, då förstår jag poängen. Men sätt den största storleken du kan behöva, för den disken har inga problem med det.

Permalänk
Medlem
Skrivet av BerraBing:

Om jag förstår dig rätt så ska jag köra med "async" på eftersom det handlar om filservrar utan VM-trafik?
7,5TB med blandade filer mellan två st VMar, det är väl asynkront då va?

Hmm, så 50%-ish partitionering räcker?

Så alltså "async" enable för högst prestanda i mitt fall?
Om jag förstått det rätt så ska "atime" vara disable också?

Ja, "async" om det inte är extra kritiskt med dataintegriteten om det t.ex. skulle bli strömavbrott eller liknande. Om din överföring mellan VMar är synkron eller ej kan jag inte svara på. Testa att tvinga "sync"-läget för din datastore till på och av, och jämför.

50% partitionering räcker långt, men om du vill ha en SSD till endast SLOG finns det ingen anledning att skapa en så stor partition för just det. 8 GB räcker gott och väl. Ta i med 16 GB om du verkligen måste. Jag tänker att enhetens firmware, efter en secure erase, vet om hur mycket som inte är partitionerat, och kan använda detta för wear leveling. Om man har en partition på 50% så kommer i värsta fall 45% av cellerna förbli helt oanvända. Beror nog på hur data skrivs för en SLOG, och de detaljerna har jag inte koll på.

Stäng av "atime" om du inte behöver veta när filer senast lästes. Det tar bort ytterligare lite onödig overhead, speciellt när man jobbar mot många väldigt små filer.

Visa signatur

Speldator: Fractal Design Meshify C, Core i7-8700k @ 5,0 GHz (AVX -3) luftkyld med Cryorig R1 Universal, Asrock Z370 Fatal1ty Professional Gaming i7, 64 GB Corsair Dominator Platinum @ 3466 MHz CL16 (XMP), ASUS ROG Strix GeForce GTX 1080 Ti Gaming, Win10 Pro, Acer XB271HU (gamla bilder med GTX 970)
i7-8700k 5.0 GHz OC: CPU 50x, Vcore 1,310V, LLC 2 (1=max, 5=min), BCLK 100.0, AVX offset -3, Cache 45x
Server: Xeon E3-1226v3 3,3 GHz, 32 GB ECC DDR3, VMware ESXi 6, 10 Gbps fiber

Permalänk

Tackar hörni!

Skrivet av Paddanx:

Aah.. bra poäng.
Är ju bara de som har kondensatorer som verkligen gör denna nivån.

Som sagt, disken klarar av det. Finns ingen poäng ur diskens synpunkt att göra göra så stor OP, när 50% garanterar att där är låg WAf och garanterat lediga celler. Det är ju därför jag länkade dig dessa tester som visar att även i extrema situationer, klarar den av detta.

På sämre SSDer, kan jag dock hålla med. Men då kommer ju nästan frågan om det verkligen är lönt att ens offra en 850 PRO för detta jobb, om du ändå ska ta till marginaler som hade gjort sämre TLC (850 EVO) diskar möjliga till det med 8GB/250GB.

Sen om du inte behöver mer... okej, då förstår jag poängen. Men sätt den största storleken du kan behöva, för den disken har inga problem med det.

Tänkte att jag ska börja med att testa det jag skrev i mitt inlägg igår först, för att se skillanderna mellan raid5/6 -> raid10 och olika OS/filsystem.
Efter det, när jag har bestämt mig för vilken raid så ska jag hoppa på detta med slog/skriv-cache.
Det lutar helt klart mot BTRFS iaf, gillar inte freenas. Ja jag vet, FreeBSD med ZFS är bättre men även att jag oftast sitter och knackar i terminaler så gillar jag att ha ett smidigt GUI i vissa situationer.

Skrivet av kai:

Ja, "async" om det inte är extra kritiskt med dataintegriteten om det t.ex. skulle bli strömavbrott eller liknande. Om din överföring mellan VMar är synkron eller ej kan jag inte svara på. Testa att tvinga "sync"-läget för din datastore till på och av, och jämför.

50% partitionering räcker långt, men om du vill ha en SSD till endast SLOG finns det ingen anledning att skapa en så stor partition för just det. 8 GB räcker gott och väl. Ta i med 16 GB om du verkligen måste. Jag tänker att enhetens firmware, efter en secure erase, vet om hur mycket som inte är partitionerat, och kan använda detta för wear leveling. Om man har en partition på 50% så kommer i värsta fall 45% av cellerna förbli helt oanvända. Beror nog på hur data skrivs för en SLOG, och de detaljerna har jag inte koll på.

Stäng av "atime" om du inte behöver veta när filer senast lästes. Det tar bort ytterligare lite onödig overhead, speciellt när man jobbar mot många väldigt små filer.

Tack! Då har jag två inställningar klara för mig, alltså;
async on och atime off.

Strömavbrott oroar mig inte då överföringar inte kommer ske jätteofta. Det kommer vara schemalagda snapshots mellan VMar varje natt och överföringar från klient när jag sitter där. Men sitter jag där och strömmen går så vet jag ju vad jag skrev just då.
Plus att jag troligtvis snart får hem en UPS...

Har för mig att jag läst att man kan skapa en subshare för datastore mot esxi och sätta just den sharen med CoW off och kanske sync on?
Pratar BTRFS nu.

Som jag skrev till @Paddanx, ska testa lite i morgon.

När det är dags för test med slog/skriv-cache så kan "vi"/jag testa lite olika alternativ på diskar och partitionering. Har några SSDer som jag kan testa olika scenarion med.
Uppskattar er kunskap och input gällande detta, båda två @Paddanx och @kai

Och givetvis tack alla andra i tråden för input också!
ska bli spännande i morgon att testa lite!

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk
Medlem
Skrivet av BerraBing:

Tackar hörni!

Tänkte att jag ska börja med att testa det jag skrev i mitt inlägg igår först, för att se skillanderna mellan raid5/6 -> raid10 och olika OS/filsystem.
Efter det, när jag har bestämt mig för vilken raid så ska jag hoppa på detta med slog/skriv-cache.
Det lutar helt klart mot BTRFS iaf, gillar inte freenas. Ja jag vet, FreeBSD med ZFS är bättre men även att jag oftast sitter och knackar i terminaler så gillar jag att ha ett smidigt GUI i vissa situationer.

Tack! Då har jag två inställningar klara för mig, alltså;
async on och atime off.

Strömavbrott oroar mig inte då överföringar inte kommer ske jätteofta. Det kommer vara schemalagda snapshots mellan VMar varje natt och överföringar från klient när jag sitter där. Men sitter jag där och strömmen går så vet jag ju vad jag skrev just då.
Plus att jag troligtvis snart får hem en UPS...

Har för mig att jag läst att man kan skapa en subshare för datastore mot esxi och sätta just den sharen med CoW off och kanske sync on?
Pratar BTRFS nu.

Som jag skrev till @Paddanx, ska testa lite i morgon.

När det är dags för test med slog/skriv-cache så kan "vi"/jag testa lite olika alternativ på diskar och partitionering. Har några SSDer som jag kan testa olika scenarion med.
Uppskattar er kunskap och input gällande detta, båda två @Paddanx och @kai

Och givetvis tack alla andra i tråden för input också!
ska bli spännande i morgon att testa lite!

När det gäller ZFS (t.ex. FreeNAS) så tänk på att om du kör explicit "async" (sync=disabled), och även i de flesta fall med default-inställningar (sync=standard), så har du ingen nytta av en SLOG över huvud taget. Rent bortkastat. Den kommer praktiskt taget aldrig användas.

Det är bara vid synkron skrivning (sync=always, eller vid sync=standard och en skrivbegäran uttryckligen görs synkron) som en SLOG används för avlastning.

Att stänga av sync writes helt (sync=disabled) är inte att rekommendera, eftersom det även stänger av sync writes för ZFS egna metadata. Den vill du absolut inte ska bli korrupt.

Jag har inte speciellt bra koll på BTRFS, men där finns vad jag vet inget likt ZFSs SLOG, så det är nog inte ens ett alternativ att avlasta synkrona skrivningar där ens om man skulle vilja.

Visa signatur

Speldator: Fractal Design Meshify C, Core i7-8700k @ 5,0 GHz (AVX -3) luftkyld med Cryorig R1 Universal, Asrock Z370 Fatal1ty Professional Gaming i7, 64 GB Corsair Dominator Platinum @ 3466 MHz CL16 (XMP), ASUS ROG Strix GeForce GTX 1080 Ti Gaming, Win10 Pro, Acer XB271HU (gamla bilder med GTX 970)
i7-8700k 5.0 GHz OC: CPU 50x, Vcore 1,310V, LLC 2 (1=max, 5=min), BCLK 100.0, AVX offset -3, Cache 45x
Server: Xeon E3-1226v3 3,3 GHz, 32 GB ECC DDR3, VMware ESXi 6, 10 Gbps fiber

Permalänk

VM 1.1 4vcpu, 8GB RAM, 5x4TB WD Red BTRFS Raid6, Xpenology 6.1.4u5
VM 1.2 4vcpu, 16GB RAM, 4x4TB WD Red BTRFS Raid10, Rockstor
VM 2 4vcpu, 16GB RAM, 8x2TB WD Green BTRFS Raid6, Rockstor

Stora filer; 3st isofiler på mellan 7-8GB/st
Små filer; 96st filer på ca 47MB/st

Alla överföringar har gjorts mellan dessa två VMar.
Setup för VM 2 ändras inte, bara den för VM 1.

Test 1, NFS4
storafiler
VM 2 -> VM 1.1 150-180MB/s
småfiler
VM 2 -> VM 1.1 80-100MB/s

Test 2, NFS4, async on
storafiler
VM 2 -> VM 1.2 160-180MB/s
småfiler
VM 2 -> VM 1.2 hann-inte-seMB/s

Test 3, NFS4, sync on
storafiler
VM 2 -> VM 1.2 170-180MB/s
småfiler
VM 2 -> VM 1.2 hann-inte-seMB/s

Överföring av 6,5TB blandade filer, NFS4, raid6 -> raid10: runt 200MB/s upp till 240MB/s med mycket mycket jämnare överföring. Båda VMarna i detta sista test hade 90% av RAM fyllt av cache...
MEN, raid6 på VM 2var degraded när jag kom hem. hdd-ras på en 2TBare.

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk

Jag har i dagarna satt upp en ny server. Jag är duktig på Windows och och kunde inte ett skvatt om Linux men ville lära mig detta. Har tidigare kört hyper-v och storage spaces som fungerat utmärkt men ny kunskap är aldrig fel.

Severn kör nu Proxmox VE som hypervisor med ZFS på hosten.
Jag har filserver (samba) samt plex i 2 LXC containers.

Jag har 6st WD Red 4TB diskar som körs i Raidz2, dvs liknande raid 6.
Vid kopiering av filer från server till min windows 10 klient ligger jag på runt 600-600 mb / sec. Kopiering till server ligger på runt 300 - 400 mb/sec.

Jag kör alla diskar via de inbyggda sata-kontakterna på moderkortet.

Jag har 10GB Ethernet hela vägen.

Min poäng är att dina hastigheter verkar låga.
Jag är inte ens säker på att mina egna hastigheter är helt optimerade.

Håller fortfarande på att lära mig.

Visa signatur

-

Permalänk

Har beställt en WD Red 4TB till nu för att utöka raid10n till 6x4TB och ska hämta en WD Green 2TB i morgon för att göra om den andra poolen.
Resultatet blir då en raid10 på 6x4TB och en raid10 på 8x2TB.
Får göra lite nya tester när jag har dem nya diskarna och ny pool på den som var degraded.
Om allt stämmer så bör nuvarande raid10 med 4x4TB (som blir 6x4TB) öka från ca 220MB/s till ca 330MB/s i skrivning.

Skrivet av flummster:

Jag har i dagarna satt upp en ny server. Jag är duktig på Windows och och kunde inte ett skvatt om Linux men ville lära mig detta. Har tidigare kört hyper-v och storage spaces som fungerat utmärkt men ny kunskap är aldrig fel.

Severn kör nu Proxmox VE som hypervisor med ZFS på hosten.
Jag har filserver (samba) samt plex i 2 LXC containers.

Jag har 6st WD Red 4TB diskar som körs i Raidz2, dvs liknande raid 6.
Vid kopiering av filer från server till min windows 10 klient ligger jag på runt 600-600 mb / sec. Kopiering till server ligger på runt 300 - 400 mb/sec.

Jag kör alla diskar via de inbyggda sata-kontakterna på moderkortet.

Jag har 10GB Ethernet hela vägen.

Min poäng är att dina hastigheter verkar låga.
Jag är inte ens säker på att mina egna hastigheter är helt optimerade.

Håller fortfarande på att lära mig.

Okej, vilken hårdvara kör du med?
Har proxmox native stöd för ZFS? *edit: kollade och svaret var ju såklart ja.
Så du kör din filserver direkt på hosten/hypervisorn? Eller missförstod jag dig?
Vilken storlek på filerna och total datamängd när du skriver till raidz2-poolen i 300-400MB/s?
Tycker också mina hastigheter är väldigt låga, därför jag skapade tråden. något känns väldigt galet i min setup...

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk

@BerraBing: "Servern" är bestyckad med:
1st Intel Xeon E3-1245v5 CPU
64 GB Crucual DDR 4 ram (icke ECC, datorn har varit en workstation tidigare)
Asus P10S WS moderkort
6x 4TB WD Red
1x Kingston KC400 256gb ssd, bootdisk.
Intel X540T2 10Gb Ethernet

Jag har satt upp ZFS på själva proxmox hosten då det finns native stöd för detta.
Filservern (samba) körs som en Container ovanpå Proxmox, där jag i Proxmox mountat ett antal olika datastores från hostens ZFS till till mina containers.

Har en ZFS pool med alla 6 diskarna tillagda, ingen cache.

Samtliga datastores i denna pool har LZ4 compression och 1mb block size.
Det bör dock tilläggas att jag ändrade från standard block size till 1mb efter jag flyttat in allt data, så detta gäller bara det som jag lägger till nu i efterhand.
Ökade från 128kb till 1Mb då större delen av filerna är filmer och musik som jag rippat från sånt jag köpt genom åren.

Kommer skapa en ny datastore med mindre block size om jag ska köra databas på någon av dem

Samtliga tester jag gjort med kopieringar hit och dit är med mkv-filer runt 15-31 Gb i storlek som kommer från mina blu-ray filmer som nu förpassats till vinden. Har även testat med en 31Gb stor .tar fil.

Jag är ingen expert på detta utan nybörjare. Men som du ser är det ganska enkel hårdvara med mycket standard. Värt att tänka på är att alla mina tester gjorts mellan maskiner som faktiskt inte sitter i samma host, utan via ett 10GBE nätverk.

I ditt fall tolkar jag det som att du skyfflar data "mellan" maskiner som sitter i samma host och som jobbar mot samma underliggande datastore.

Skulle detta inte kunna innebära att du gör en Read/Write på samma diskar, och detta har väl en lägre prestanda än en read respektive write från olika datakällor?

Här för någon som har mer erfarenhet av storage gärna tillrättavisa om jag är ute och cyklar.

Visa signatur

-

Permalänk
Medlem
Skrivet av BerraBing:

VM 1.1 4vcpu, 8GB RAM, 5x4TB WD Red BTRFS Raid6, Xpenology 6.1.4u5
VM 1.2 4vcpu, 16GB RAM, 4x4TB WD Red BTRFS Raid10, Rockstor
VM 2 4vcpu, 16GB RAM, 8x2TB WD Green BTRFS Raid6, Rockstor

Stora filer; 3st isofiler på mellan 7-8GB/st
Små filer; 96st filer på ca 47MB/st

Alla överföringar har gjorts mellan dessa två VMar.
Setup för VM 2 ändras inte, bara den för VM 1.

Test 1, NFS4
storafiler
VM 2 -> VM 1.1 150-180MB/s
småfiler
VM 2 -> VM 1.1 80-100MB/s

Test 2, NFS4, async on
storafiler
VM 2 -> VM 1.2 160-180MB/s
småfiler
VM 2 -> VM 1.2 hann-inte-seMB/s

Test 3, NFS4, sync on
storafiler
VM 2 -> VM 1.2 170-180MB/s
småfiler
VM 2 -> VM 1.2 hann-inte-seMB/s

Överföring av 6,5TB blandade filer, NFS4, raid6 -> raid10: runt 200MB/s upp till 240MB/s med mycket mycket jämnare överföring. Båda VMarna i detta sista test hade 90% av RAM fyllt av cache...

Just jämnare prestanda är ju en fördel, men det låter ändå som låga siffror för sekventiell prestanda tycker jag. Du borde få 2x diskarnas prestanda i skrivning med 4 diskar.

Att småfiler gick snabbare är är dock något positivt.
Ofta är ju nätverket (Gbit) flaskhalsen ändå, förutom med småfiler, så får man dessa upp till den nivån märks det.

Skrivet av BerraBing:

MEN, raid6 på VM 2var degraded när jag kom hem. hdd-ras på en 2TBare.

DOH!
Murphy got u again

Skrivet av BerraBing:

Har beställt en WD Red 4TB till nu för att utöka raid10n till 6x4TB och ska hämta en WD Green 2TB i morgon för att göra om den andra poolen.
Resultatet blir då en raid10 på 6x4TB och en raid10 på 8x2TB.
Får göra lite nya tester när jag har dem nya diskarna och ny pool på den som var degraded.
Om allt stämmer så bör nuvarande raid10 med 4x4TB (som blir 6x4TB) öka från ca 220MB/s till ca 330MB/s i skrivning.

Får hoppas den skalar bättre, för något är konstigt.

Permalänk
Skrivet av flummster:

@BerraBing: "Servern" är bestyckad med:
1st Intel Xeon E3-1245v5 CPU
64 GB Crucual DDR 4 ram (icke ECC, datorn har varit en workstation tidigare)
Asus P10S WS moderkort
6x 4TB WD Red
1x Kingston KC400 256gb ssd, bootdisk.
Intel X540T2 10Gb Ethernet

Jag har satt upp ZFS på själva proxmox hosten då det finns native stöd för detta.
Filservern (samba) körs som en Container ovanpå Proxmox, där jag i Proxmox mountat ett antal olika datastores från hostens ZFS till till mina containers.

Har en ZFS pool med alla 6 diskarna tillagda, ingen cache.

Samtliga datastores i denna pool har LZ4 compression och 1mb block size.
Det bör dock tilläggas att jag ändrade från standard block size till 1mb efter jag flyttat in allt data, så detta gäller bara det som jag lägger till nu i efterhand.
Ökade från 128kb till 1Mb då större delen av filerna är filmer och musik som jag rippat från sånt jag köpt genom åren.

Kommer skapa en ny datastore med mindre block size om jag ska köra databas på någon av dem

Samtliga tester jag gjort med kopieringar hit och dit är med mkv-filer runt 15-31 Gb i storlek som kommer från mina blu-ray filmer som nu förpassats till vinden. Har även testat med en 31Gb stor .tar fil.

Jag är ingen expert på detta utan nybörjare. Men som du ser är det ganska enkel hårdvara med mycket standard. Värt att tänka på är att alla mina tester gjorts mellan maskiner som faktiskt inte sitter i samma host, utan via ett 10GBE nätverk.

I ditt fall tolkar jag det som att du skyfflar data "mellan" maskiner som sitter i samma host och som jobbar mot samma underliggande datastore.

Skulle detta inte kunna innebära att du gör en Read/Write på samma diskar, och detta har väl en lägre prestanda än en read respektive write från olika datakällor?

Här för någon som har mer erfarenhet av storage gärna tillrättavisa om jag är ute och cyklar.

Hinner inte svara så långt just nu men;
Du kör alltså hela poolen direkt i hosten och delar ut den till nätverket?

Skrivet av Paddanx:

Just jämnare prestanda är ju en fördel, men det låter ändå som låga siffror för sekventiell prestanda tycker jag. Du borde få 2x diskarnas prestanda i skrivning med 4 diskar.

Att småfiler gick snabbare är är dock något positivt.
Ofta är ju nätverket (Gbit) flaskhalsen ändå, förutom med småfiler, så får man dessa upp till den nivån märks det.

DOH!
Murphy got u again

Får hoppas den skalar bättre, för något är konstigt.

Ja precis, jämnare prestanda känns ju som att man är på rätt väg iaf även att det är för låga siffror...
ja, även 220MB/s är lite lågt för två utav den diskarna eftersom jag får 2xskrivprestandan just nu.
Hoppas disken kommer i morgon.
Jo jag vet ju såklart om det med 1Gbit, men alla tester just nu är inom hosten och på 10Gbit. Dessutom kommer lanet snart att uppgraderas till 10Gbit inom en snart framtid...

Haha ja den där jävla murphy! men som tur är körde jag raid6 så kunde komma åt filerna och kopiera dem till main-storage på raid10n Detta handlar ju om en main-pool samt en backup-pool så kunde ändå labba lite trots rasad disk, ingen kommer ihåg en fegis

Du som kan detta med SSDer bra; Innan jag gör något med 850 Pro'n så har jag lite andra SSDer att testa med.
1 x 530 180GB
1 x 520 180GB
1 x 520 120GB
520 var bättre som cache-disk va trots lägre IOPS?

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk
Medlem

Har inte läst tråden, bara TS inlägg.

Jag kör själv med FreeNAS (ZFS) som lagring över NFS till en VMware ESXi host. Med Raid10 + en Intel 540 (rekommenderad av FreeNAS på IRC) så fick jag ut ynka 60-70 MB/s i write. Bytte upp mig till en DC3710 och får nu ut magiska 350 MB/s.

Nuff said.

Visa signatur

Citera för svar

Stora Owncloud/Nextcloud-tråden: http://www.sweclockers.com/forum/122-server/1212245-officiell...
Jobb: Datacenter Manager
Grundare: https://www.hanssonit.se

Permalänk
Skrivet av BerraBing:

Hinner inte svara så långt just nu men;
Du kör alltså hela poolen direkt i hosten och delar ut den till nätverket?

Det stämmer ZFS poolen ligger direkt på hosten och delas ut som shares via nätverket (från en container som har delar av poolen mountad).

Visa signatur

-

Permalänk
Medlem
Skrivet av BerraBing:

Du som kan detta med SSDer bra; Innan jag gör något med 850 Pro'n så har jag lite andra SSDer att testa med.
1 x 530 180GB
1 x 520 180GB
1 x 520 120GB
520 var bättre som cache-disk va trots lägre IOPS?

Intel 520 skulle kunna fungera, men jag vet inte med hur bra prestsanda. 240GB är den bäst presterande 520 versionen, men 180GB ska vara rätt nära. 120GB har färre NAND paket och därför har sämre skrivprestanda. NANDet de använder är också på 5k P/E och MLC så det bör hålla rätt bra. https://www.intel.com/content/dam/support/us/en/documents/ssd... (Se sid 7 för okomprimerbar prestanda)

Intel 530 hade jag nog inte kört dock, eftersom den är senare generation och har därför större NAND mängd / paket, vilket gör samma storlek långsammare. (520 har 8, 530 har 4) 530 har också en bugg med sin energisparläge, som kan ge rätt enorma WAf och sliter ut NAND även när disken inte används. De har även "bara" 3k P/E NAND så lite sämre tålighet. (Du kan se min disk på jobb här och dens enorma WAf, trots att den knappt används) https://www.intel.com/content/dam/www/public/us/en/documents/... (Se sid 8 för okomprimerbar prestanda, notera hur låg sekventiella prestandan är)

Men jag kan förstå varför 520 tex kan vara snabbare än 850, då moderna SSDer är hårt designade att använda DRAM cache. Men utan kondensatorer så kan de tappa data som inte hunnits skrivas till NAND. Och om jag förstått det rätt är det här problemet är med denna typ av last du har... den kan inte använda denna Cachen, varpå prestandan dyker på SSDerna. Detta är ju varför enterprise klassade diskar med backup kondensatorer kan fungera bra här, medan konsumentdiskar får så dålig prestanda.

Sandforce kontrollern som både 520 och 530 bygger på är dock DRAM lösa. Denna kontroller skriver istället direkt till NANDet, och har endast en ytterst liten mängd RAM internt, så den synkrona prestanda bör blir rätt bra. Så även om den har lägre prestanda rent... benchmark-mässigt, så kan den mycket väl ha bättre prestanda i detta special scenario. De har även komprimering som kan hjälpa till med viss typ av data. Så jag hade definitivt testat 520 180GB disken... och med 8-16GB storlek lär du inte ha problem med WAf med den gamla kontrollern.

Permalänk
Medlem
Skrivet av BerraBing:

Har jag missat någon info som behövs så får ni hojta till

Kom på en sak, vad kör du för nätverkskort på dina VMs? Kör du med VMXNET3?

Permalänk
Skrivet av enoch85:

Har inte läst tråden, bara TS inlägg.

Jag kör själv med FreeNAS (ZFS) som lagring över NFS till en VMware ESXi host. Med Raid10 + en Intel 540 (rekommenderad av FreeNAS på IRC) så fick jag ut ynka 60-70 MB/s i write. Bytte upp mig till en DC3710 och får nu ut magiska 350 MB/s.

Nuff said.

Ja jag verkar inte vara ensam om att ha problem med överföringshastigheten i FreeNAS..!
Du hade tom problem med en SSD-slog. Nu verkar det ju inte som att 540 var den bästa med tanke på ditt resultat.
Vet att S3700 och S3710 är dem bästa för detta, men tänker inte lägga pengar på en sådan förrns jag ser att det är värt det.
Vid vilken filstorlek och datamängd får du 350MB/s skrivningar?
Hur stor är din 3710?
Hur många diskar har du i din raid10?

Skrivet av flummster:

Det stämmer ZFS poolen ligger direkt på hosten och delas ut som shares via nätverket (från en container som har delar av poolen mountad).

Tack för infon, tål att tänkas på...

Skrivet av Paddanx:

Intel 520 skulle kunna fungera, men jag vet inte med hur bra prestsanda. 240GB är den bäst presterande 520 versionen, men 180GB ska vara rätt nära. 120GB har färre NAND paket och därför har sämre skrivprestanda. NANDet de använder är också på 5k P/E och MLC så det bör hålla rätt bra. https://www.intel.com/content/dam/support/us/en/documents/ssd... (Se sid 7 för okomprimerbar prestanda)

Intel 530 hade jag nog inte kört dock, eftersom den är senare generation och har därför större NAND mängd / paket, vilket gör samma storlek långsammare. (520 har 8, 530 har 4) 530 har också en bugg med sin energisparläge, som kan ge rätt enorma WAf och sliter ut NAND även när disken inte används. De har även "bara" 3k P/E NAND så lite sämre tålighet. (Du kan se min disk på jobb här och dens enorma WAf, trots att den knappt används) https://www.intel.com/content/dam/www/public/us/en/documents/... (Se sid 8 för okomprimerbar prestanda, notera hur låg sekventiella prestandan är)

Men jag kan förstå varför 520 tex kan vara snabbare än 850, då moderna SSDer är hårt designade att använda DRAM cache. Men utan kondensatorer så kan de tappa data som inte hunnits skrivas till NAND. Och om jag förstått det rätt är det här problemet är med denna typ av last du har... den kan inte använda denna Cachen, varpå prestandan dyker på SSDerna. Detta är ju varför enterprise klassade diskar med backup kondensatorer kan fungera bra här, medan konsumentdiskar får så dålig prestanda.

Sandforce kontrollern som både 520 och 530 bygger på är dock DRAM lösa. Denna kontroller skriver istället direkt till NANDet, och har endast en ytterst liten mängd RAM internt, så den synkrona prestanda bör blir rätt bra. Så även om den har lägre prestanda rent... benchmark-mässigt, så kan den mycket väl ha bättre prestanda i detta special scenario. De har även komprimering som kan hjälpa till med viss typ av data. Så jag hade definitivt testat 520 180GB disken... och med 8-16GB storlek lär du inte ha problem med WAf med den gamla kontrollern.

Tack för utförligt svar!
Så om jag förstår dig rätt så kan mina 520 funka riktigt bra som SLOG om jag har tur? Och jag ska skippa 530'n för detta?
Ska jag partitionera dem med 16GB partitioner eller varför inte 50-80GB?
Kommer främst skyfflas större datamängder mellan poolerna.

Skrivet av erifri:

Kom på en sak, vad kör du för nätverkskort på dina VMs? Kör du med VMXNET3?

Skrev det i första posten; vmxnet3 med MTU 9000 på alla nicar samt vswitchen.

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk

Fick min nya 4TB-disk idag, så kör nu en resize och rebalance till 6x4TB i raid10 BTRFS.
Tar TID, så lär inte hinna testa något idag...

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk
Medlem
Skrivet av BerraBing:

Tack för utförligt svar!
Så om jag förstår dig rätt så kan mina 520 funka riktigt bra som SLOG om jag har tur? Och jag ska skippa 530'n för detta?
Ska jag partitionera dem med 16GB partitioner eller varför inte 50-80GB?
Kommer främst skyfflas större datamängder mellan poolerna.

520, ja, den borde kunna fungera bra, kanske inte enterprise nivå, men för konsument SATA iaf (finns även liknande i listan som ddelin linkade tidigare, där tom 60GB disk får rätt bra prestanda)
530 lär inte klara det i längden / sämre prestanda.

Varför så liten partition, är för Write Amplification factor på denna kontroller är inte så pass bra utan TRIM. Du kan säkert ta till med 1/4 av diskens storlek (ca 32GB på 120GB disken), men jag hade nog inte gått över det, då den enda bit som Sandforce kontrollern har för att få bra WAf är TRIM + komprimeringen, och ingen av dessa kan du lita på med en cache med denna typ av jobb.

Du vill ju att den ska hålla så bra som möjligt, och skriver du stora mängder data så kommer ju den cachen att skrivas om, och om igen relativt fort och kontrollern bör då ha 1 uppsättning data (nuvarande), 1 uppsättning data (nytt inkommande), 1 uppsättning data (gammalt som inte hunnits tömmas) + marginaler på detta så jämnt slitage kan ske.

850 PRO visste jag pga tester kunde hantera det pga hur kontrollern är gjord (där en kärna bara gör GC mer eller mindre, samt NANDet är mycket snabbare än SATA, så den hinner städa. Tyvärr verkar dens prestanda rätt dålig här, även om den tål det, så jag hade nog kört på 520 disken.

Se dock till att du uppgraderar deras FW först om det inte är gjort, då Sandforce kontrollern hade en bugg förr i tiden (som är lagad). Tror Intels diskar var immuna mot det, men de har släppt ny FW ändå.

Permalänk
Medlem
Skrivet av BerraBing:

Ja jag verkar inte vara ensam om att ha problem med överföringshastigheten i FreeNAS..!
Du hade tom problem med en SSD-slog. Nu verkar det ju inte som att 540 var den bästa med tanke på ditt resultat.
Vet att S3700 och S3710 är dem bästa för detta, men tänker inte lägga pengar på en sådan förrns jag ser att det är värt det.
Vid vilken filstorlek och datamängd får du 350MB/s skrivningar?
Hur stor är din 3710?
Hur många diskar har du i din raid10?

Det är skillnad på SLOG och SLOG, uppenbarligen. Allt handlar väl i slutändan var du vill dra gränsen. Jag menar om vi använder säkerhet som liknelse; hög säkerhet är bra, men inte så hög att det inte går att använda. På samma sätt är hög hastighet bra, men inte till vilket pris som helst, och i detta fallet så handlar det ju om vad du vill få ut och vad du är beredd att ge. Jag kom över mina diskar billigt här på Sweclockers, jag hade tur.

De tester jag gjort är på en Windows VM i VMware samtidigt som alla mina andra 20 VMs var igång i produktion. Senast igår så packade jag upp 4 RARfiler samtidigt och Windows visade då toppar på 470 MB/s. Dock ska man nog ta det med en nypa salt. Mina första tester gjorde jag med XXX (minns inte namnet, men ett seiöst program för diskbench iaf) och då fick jag ut 350 MB/s. Dock har jag numera FreeNAS 11.1 och jag vet att en hel del förbättringar gjordes med ZFS i den versionen, så det kan ha blivit bättre.

Jag har en RAID10 med 8 diskar, och 10 GBe NFS mellan Server och FreeNAS. Inga diskar i servern. Min DC3710 är ~400 GB, minns inte exakt.

Sen vill jag påpeka att det inte är FreeNAS fel, det är snarare ZFS i sig själv som är krävande.

Visa signatur

Citera för svar

Stora Owncloud/Nextcloud-tråden: http://www.sweclockers.com/forum/122-server/1212245-officiell...
Jobb: Datacenter Manager
Grundare: https://www.hanssonit.se

Permalänk
Skrivet av Paddanx:

520, ja, den borde kunna fungera bra, kanske inte enterprise nivå, men för konsument SATA iaf (finns även liknande i listan som ddelin linkade tidigare, där tom 60GB disk får rätt bra prestanda)
530 lär inte klara det i längden / sämre prestanda.

Varför så liten partition, är för Write Amplification factor på denna kontroller är inte så pass bra utan TRIM. Du kan säkert ta till med 1/4 av diskens storlek (ca 32GB på 120GB disken), men jag hade nog inte gått över det, då den enda bit som Sandforce kontrollern har för att få bra WAf är TRIM + komprimeringen, och ingen av dessa kan du lita på med en cache med denna typ av jobb.

Du vill ju att den ska hålla så bra som möjligt, och skriver du stora mängder data så kommer ju den cachen att skrivas om, och om igen relativt fort och kontrollern bör då ha 1 uppsättning data (nuvarande), 1 uppsättning data (nytt inkommande), 1 uppsättning data (gammalt som inte hunnits tömmas) + marginaler på detta så jämnt slitage kan ske.

850 PRO visste jag pga tester kunde hantera det pga hur kontrollern är gjord (där en kärna bara gör GC mer eller mindre, samt NANDet är mycket snabbare än SATA, så den hinner städa. Tyvärr verkar dens prestanda rätt dålig här, även om den tål det, så jag hade nog kört på 520 disken.

Se dock till att du uppgraderar deras FW först om det inte är gjort, då Sandforce kontrollern hade en bugg förr i tiden (som är lagad). Tror Intels diskar var immuna mot det, men de har släppt ny FW ändå.

Utförligt svar som vanligt, tackar för det!

Nej precis, förväntar mig ju inte enterprise-nivå i detta läget, det får komma efter proof of concept
Okej, då förstår jag lite mer gällande storleken på partitionen.

Tack för påminnelsen om FW! Kollade dem och det var redan senaste.

Skrivet av enoch85:

Det är skillnad på SLOG och SLOG, uppenbarligen. Allt handlar väl i slutändan var du vill dra gränsen. Jag menar om vi använder säkerhet som liknelse; hög säkerhet är bra, men inte så hög att det inte går att använda. På samma sätt är hög hastighet bra, men inte till vilket pris som helst, och i detta fallet så handlar det ju om vad du vill få ut och vad du är beredd att ge. Jag kom över mina diskar billigt här på Sweclockers, jag hade tur.

De tester jag gjort är på en Windows VM i VMware samtidigt som alla mina andra 20 VMs var igång i produktion. Senast igår så packade jag upp 4 RARfiler samtidigt och Windows visade då toppar på 470 MB/s. Dock ska man nog ta det med en nypa salt. Mina första tester gjorde jag med XXX (minns inte namnet, men ett seiöst program för diskbench iaf) och då fick jag ut 350 MB/s. Dock har jag numera FreeNAS 11.1 och jag vet att en hel del förbättringar gjordes med ZFS i den versionen, så det kan ha blivit bättre.

Jag har en RAID10 med 8 diskar, och 10 GBe NFS mellan Server och FreeNAS. Inga diskar i servern. Min DC3710 är ~400 GB, minns inte exakt.

Sen vill jag påpeka att det inte är FreeNAS fel, det är snarare ZFS i sig själv som är krävande.

Precis, skillnad mellan diskar. Absolut, men jag börjar på denna nivån först. Sen får vi se

Så du har inte gjort tester med datamängder på säg 3-4TB?

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk

Dagens tester

Rockstor i båda VMarna, 4vCPU och 16GB RAM, vmxnet3 MTU 9000, inga cache-diskar

raid10 btrfs (6diskar,4TB) -> raid5 btrfs (7diskar,2TB): 350-450MB/s
raid5 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): 470-505MB/s (svajigare ner till ca 320MB/s)

raid10 btrfs (6diskar,4TB) -> raid6 btrfs (7diskar,2TB): 380-410MB/s (jämnt ca 400MB/s)
raid6 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): 150-300MB/s (svajigt)

raid10 btrfs (6diskar,4TB) -> raid10 btrfs (6diskar,2TB): 375-400MB/s (jämnt ca 385MB/s)
raid10 btrfs (6diskar,2TB) -> raid10 btrfs (6diskar,4TB): 360-370MB/s (svajigare med någon dipp ner till 50MB/s)

Känns som att läsning från 2TB-diskarna generellt är lite svajigare.
Som jag utläser resultaten så är raid10-poolen med 4TB-diskar snabbare och stabilare både gällande läsning och skrivning.

Btw, oavsett slutresultat med system och cache så kommer poolen med 2TB-diskar nästan alltid vara "destination" eftersom det är en backup av 4TB-diskarna i main-storage.

Edit; Glömde skriva att testerna gjordes med 3st iso-filer på 7-8GB/st så 22GB totalt.

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk
Medlem
Skrivet av BerraBing:

Utförligt svar som vanligt, tackar för det!

Nej precis, förväntar mig ju inte enterprise-nivå i detta läget, det får komma efter proof of concept
Okej, då förstår jag lite mer gällande storleken på partitionen.

Tack för påminnelsen om FW! Kollade dem och det var redan senaste.

Precis, skillnad mellan diskar. Absolut, men jag börjar på denna nivån först. Sen får vi se

Så du har inte gjort tester med datamängder på säg 3-4TB?

De RARfiler jag packade upp igår var totalt 5 TB med en konstant överföringshastighet på 350-470 MB/s.

Visa signatur

Citera för svar

Stora Owncloud/Nextcloud-tråden: http://www.sweclockers.com/forum/122-server/1212245-officiell...
Jobb: Datacenter Manager
Grundare: https://www.hanssonit.se

Permalänk
Medlem
Skrivet av BerraBing:

Rockstor i båda VMarna, 4vCPU och 16GB RAM, vmxnet3 MTU 9000, inga cache-diskar

raid10 btrfs (6diskar,4TB) -> raid5 btrfs (7diskar,2TB): 350-450MB/s
raid5 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): 470-505MB/s (svajigare ner till ca 320MB/s)

raid10 btrfs (6diskar,4TB) -> raid6 btrfs (7diskar,2TB): 380-410MB/s (jämnt ca 400MB/s)
raid6 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): 150-300MB/s (svajigt)

raid10 btrfs (6diskar,4TB) -> raid10 btrfs (6diskar,2TB): 375-400MB/s (jämnt ca 385MB/s)
raid10 btrfs (6diskar,2TB) -> raid10 btrfs (6diskar,4TB): 360-370MB/s (svajigare med någon dipp ner till 50MB/s)

Känns som att läsning från 2TB-diskarna generellt är lite svajigare.
Som jag utläser resultaten så är raid10-poolen med 4TB-diskar snabbare och stabilare både gällande läsning och skrivning.

Btw, oavsett slutresultat med system och cache så kommer poolen med 2TB-diskar nästan alltid vara "destination" eftersom det är en backup av 4TB-diskarna i main-storage.

Edit; Glömde skriva att testerna gjordes med 3st iso-filer på 7-8GB/st så 22GB totalt.

Det ser iaf lite bättre ut, vi ser iaf 300-400 på flesta ställen vs de <200MB/s du hade innan.

Det kan ju vara så att din svajighet är en disk som börjar bli dålig, (då 2 st 2TB hade rasat lär de andra vara "på väg".), samt det verkar bli just svajigt när du läser från 2TB diskarna, då så de blir lite flaskhals.

Permalänk
Medlem

@BerraBing På tal om firmware, har du dubbelkollat så "drive head parking" är avstängt på dina WD Green? Kika på attribut 193 (Load Cycle Count) via SMART.

https://support.wdc.com/knowledgebase/answer.aspx?ID=5357

Visa signatur

Speldator: Fractal Design Meshify C, Core i7-8700k @ 5,0 GHz (AVX -3) luftkyld med Cryorig R1 Universal, Asrock Z370 Fatal1ty Professional Gaming i7, 64 GB Corsair Dominator Platinum @ 3466 MHz CL16 (XMP), ASUS ROG Strix GeForce GTX 1080 Ti Gaming, Win10 Pro, Acer XB271HU (gamla bilder med GTX 970)
i7-8700k 5.0 GHz OC: CPU 50x, Vcore 1,310V, LLC 2 (1=max, 5=min), BCLK 100.0, AVX offset -3, Cache 45x
Server: Xeon E3-1226v3 3,3 GHz, 32 GB ECC DDR3, VMware ESXi 6, 10 Gbps fiber

Permalänk
Skrivet av enoch85:

De RARfiler jag packade upp igår var totalt 5 TB med en konstant överföringshastighet på 350-470 MB/s.

Okej, det är ju bra hastigheter du får alltså.

Skrivet av Paddanx:

Det ser iaf lite bättre ut, vi ser iaf 300-400 på flesta ställen vs de <200MB/s du hade innan.

Det kan ju vara så att din svajighet är en disk som börjar bli dålig, (då 2 st 2TB hade rasat lär de andra vara "på väg".), samt det verkar bli just svajigt när du läser från 2TB diskarna, då så de blir lite flaskhals.

Ja precis, det såg lite bättre ut iaf.
Kan vara som du säger, att 2TB-diskarna är lite halv-risiga nu.

Skrivet av kai:

@BerraBing På tal om firmware, har du dubbelkollat så "drive head parking" är avstängt på dina WD Green? Kika på attribut 193 (Load Cycle Count) via SMART.

https://support.wdc.com/knowledgebase/answer.aspx?ID=5357

Nej har inte kollat det, får kanske göra det?
Vad gör den attriben? Parkerar huvudet när?

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk

Dagens tester 2

Rockstor i raid10-VM, 4vCPU och 16GB RAM, vmxnet3 MTU 9000.
FreeNAS i den andra VMen, 4vCPU och 16GB RAM, vmxnet3 MTU 9000.

raid10 btrfs (6diskar,4TB) -> raidz1 zfs (7diskar,2TB,lz4): 180-300MB/s (jämnt ca 200MB/s, vid filbyte droppar till 50MB/s)
raidz1 zfs (7diskar,2TB,lz4) -> raid10 btrfs (6diskar,4TB): 140-200MB/s (jämnt ca 170MB/s, vid filbyte droppar till 150MB/s)

raid10 btrfs (6diskar,4TB) -> raidz2 zfs (7diskar,2TB,lz4): 170-300MB/s (jämnt ca 170MB/s, vid filbyte droppar till 50MB/s)
raidz2 zfs (7diskar,2TB,lz4) -> raid10 btrfs (6diskar,4TB): 130-220MB/s (jämnt ca 180MB/s, vid filbyte droppar till 150MB/s)

raid10 btrfs (6diskar,4TB) -> raid10 zfs (6diskar,2TB,lz4): 130-300MB/s (jämnt ca 130MB/s, vid filbyte droppar till 0MB/s)
raid10 zfs (6diskar,2TB,lz4) -> raid10 btrfs (6diskar,4TB): 120-190MB/s (jämnt ca 160MB/s, vid filbyte droppar till 100MB/s)

Med 32GiB cache på zfs, överföring av 69GB datamängd, 9x8GB/st
raid10 btrfs (6diskar,4TB) -> raidz1 zfs (7diskar,2TB,lz4): 180-350MB/s (jämnt ca 200MB/s, vid filbyte droppar till 50MB/s)
Inget tecken på att den fyller cache först, alltså dem första 30GB av datan.
raid10 btrfs (6diskar,4TB) -> raidz2 zfs (7diskar,2TB,lz4): 160-350MB/s (jämnt ca 140MB/s, vid filbyte droppar till 20MB/s)
Inget tecken på att den fyller cache först, alltså dem första 30GB av datan.

Med 120GB (Hela disken) cache på zfs, överföring av 69GB datamängd, 9x8GB/st
raid10 btrfs (6diskar,4TB) -> raidz1 zfs (7diskar,2TB,lz4): 180-350MB/s (jämnt ca 200MB/s, vid filbyte droppar till 50MB/s)
Inget tecken på att den fyller cache först, alltså dem första 30GB av datan.
raid10 btrfs (6diskar,4TB) -> raidz2 zfs (7diskar,2TB,lz4): 150-350MB/s (jämnt ca 150MB/s, vid filbyte droppar till 50MB/s)
Inget tecken på att den fyller cache först, alltså dem första 30GB av datan.

SSD'n partitionerad som följer;
GPT 32GiB prim part unformatted unnamed unlabeled

Verkligen inte imponerad av FreeNAS, mitt tidigare intryck av FreeNAS är bara förstärkt.
Okej om jag hade sett någon ökning av hastigheterna ihop med SSD'n, men märkte ingenting. Kanske har gjort helt fel?
Se nedan;
raidz1 med 32GiB-cache

raidz2 med 32GiB-cache

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk

Dagens tester 3

Rockstor i båda VMarna
storage: 4vCPU och 16GB RAM, vmxnet3 MTU 9000.
backup: 4vCPU och 4GB RAM, vmxnet3 MTU 9000.
3x8GB filer överförda

raid10 btrfs (6diskar,4TB) -> raid5 btrfs (7diskar,2TB): 320-360MB/s
raid5 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): 400-460MB/s

Rockstor i båda VMarna
storage: 4vCPU och 16GB RAM, vmxnet3 MTU 9000.
backup: 4vCPU och 8GB RAM, vmxnet3 MTU 9000.
3x8GB filer överförda

raid10 btrfs (6diskar,4TB) -> raid5 btrfs (7diskar,2TB): 370-405MB/s
raid5 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): 460-500MB/s

Rockstor i båda VMarna
storage: 4vCPU och 8GB RAM, vmxnet3 MTU 9000.
backup: 4vCPU och 8GB RAM, vmxnet3 MTU 9000.
3x8GB filer överförda

raid10 btrfs (6diskar,4TB) -> raid5 btrfs (7diskar,2TB): 370-415MB/s
raid5 btrfs (7diskar,2TB) -> raid10 btrfs (6diskar,4TB): väldigt svajigt med höga pikar 516

Känns som att sweet-spot är 16GB RAM i "main" och 8GB RAM i "backup" just nu.

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system

Permalänk
Medlem

titta i dmesg eller motsvarande att den inte har problem med WD-green diskarna - dom kan fula sig ganska ordentligt med långa svarstider och omskrivningar av sektorer upprepande för att de lästa är felaktiga utan att det syns något alls i SMART efteråt.

Hade ett sådant fall och det trögade ned NAS ordentligt utan att man kunde sätta fingret på det mha. de grafiska gränssnitten, SMART-värden där etc. utan blev till djupdykning i dmesg etc. och titta på lågnivå SCSI-kommandon...

Permalänk
Medlem

@BerraBing Du kan inte förvänta dig att ZFS L2ARC (läs-cache) kommer hjälpa vid sekventiell skrivning. Enkelt sett så fylls denna cache endast vid repetitiv läsning av samma data innan denna data hunnit avlägsnas från primär cache (ARC) i RAM. Och den fylls långsamt. Samt överlever inte omstart.

Som @xxargs säger bör du undersöka dina WD Green mer i detalj.

Det är svårt för mig att göra någon direkt jämförelse med min egen server, men jag testade lite överföring till mina ZFS-pooler genom en Windows 10-VM på samma VMware-host som min FreeNAS-server. Jag testade överföring mellan pooler, samt från en RAM-disk i Windows. Ingen pool har cache (L2ARC) eller log (SLOG), bara fyra (raid10) eller två (raid1) diskar.

Jag skriver filer i ca 180-280 MB/s (snittar runt 230) till en 60% fylld pool bestående av 4x WD Black 640GB i mostvarande raid10 (stripe+mirror). Dessa diskar har över 7 år på nacken.

Jag får även ca 60% av ovan prestanda (90-120 MB/s), men med något större variation (ibland över 200 MB/s för flera GB i sträck), när jag skriver en likvärdig fil till min andra pool som består av två Seagate NAS 4TB i en enkel raid1 (mirror.) Denna pool är precis över 80% full vilket är övre gränsen för vad som rekommenderas för prestanda.

Ovan resultat är med jumbo frames (MTU 9000) och vmxnet3 på båda sidor. Kör jag över ett E1000E-interface utan jumbo frames (MTU 1500) i Windows, mot vmxnet3 utan jumbo frames i FreeNAS, så går prestandan ner ca 10-20%.

Jag har minskat ner maximal tid innan en transaktionsgrupp skrivs till disk, från 5 till 2 sekunder, vilket jag tror (kanske inbillar mig) ger mig mer jämn prestanda. (Jag sätter "loader" type tunable "vfs.zfs.txg.timeout" till 2.)

Det kan också vara bra att utesluta nätverksrelaterat strul. FreeBSD, som FreeNAS baseras på, kanske helt enkelt fungerar sämre än Linux i din miljö.

Hur snabbt skriver du data till din pool? Testa t.ex. genom att skapa ett dataset utan komprimering och skriva data dit via "dd". Se till att mängden data du skriver inte är för liten så den helt äts upp av en transaktionsgrupp (1/8 av RAM per default).

Exempel för 10 GB: dd if=/dev/zero of=/mnt/minpool/test/zerofile bs=1G count=10

Jag har ca 18 GB RAM för FreeNAS, så min skrivcache ligger runt 2 GB, men skrivs också ut efter max 2 sekunder. Data nedan är från 3 körningar per pool.

2 diskar i raid1: 83, 88, samt 89 sekunder för 10 GB (115-123 MB/s)
4 diskar i raid 10: 45, 58, samt 51 sekunder för 10 GB (176-227 MB/s)

Hur snabbt kan du skriva över nätverket? Testa genom att över nätverket skriva en högt komprimerbar fil till ett dataset med lz4-komprimering igång. T.ex. kan du kopiera över en eller flera av dessa filer med enbart 0:or till btrfs-poolen, eller en RAM-disk för den delen. Windows kommer skicka all data som den är, men FreeNAS kommer applicera sin enkla, och i det här fallet extrema, komprimering, så du kommer i stort sett se hur snabbt du kan föra över i absolut bästa fall till en blixtsnabb pool.

Att direkt i FreeNAS skriva en fil med bara nollor till en pool med lz4-komprimering tar för mig ca 4-5 sekunder, dvs runt 2 GB/s.

För min even del verkar min Windows-VM slå i taket vid en snitthastighet på ca 250 MB/s från RAM-disk till FreeNAS via både SMB och iSCSI. För SMB ser jag en initial burst på 1-2 sekunder med nära dubbla hastigheten, oklart vad det kommer från. För iSCSI ser hastigheten ut att börja lågt för att sedan rampa upp mer långsamt.

Det här blev längre än jag tänkt mig... Hoppas det hjälper någon.

Visa signatur

Speldator: Fractal Design Meshify C, Core i7-8700k @ 5,0 GHz (AVX -3) luftkyld med Cryorig R1 Universal, Asrock Z370 Fatal1ty Professional Gaming i7, 64 GB Corsair Dominator Platinum @ 3466 MHz CL16 (XMP), ASUS ROG Strix GeForce GTX 1080 Ti Gaming, Win10 Pro, Acer XB271HU (gamla bilder med GTX 970)
i7-8700k 5.0 GHz OC: CPU 50x, Vcore 1,310V, LLC 2 (1=max, 5=min), BCLK 100.0, AVX offset -3, Cache 45x
Server: Xeon E3-1226v3 3,3 GHz, 32 GB ECC DDR3, VMware ESXi 6, 10 Gbps fiber

Permalänk
Skrivet av xxargs:

titta i dmesg eller motsvarande att den inte har problem med WD-green diskarna - dom kan fula sig ganska ordentligt med långa svarstider och omskrivningar av sektorer upprepande för att de lästa är felaktiga utan att det syns något alls i SMART efteråt.

Hade ett sådant fall och det trögade ned NAS ordentligt utan att man kunde sätta fingret på det mha. de grafiska gränssnitten, SMART-värden där etc. utan blev till djupdykning i dmesg etc. och titta på lågnivå SCSI-kommandon...

hmm det kanske man skulle kolla upp då, tack för tipset!
Men borde inte felet i sådana fall visa sig även med BTRFS?

Skrivet av kai:

@BerraBing Du kan inte förvänta dig att ZFS L2ARC (läs-cache) kommer hjälpa vid sekventiell skrivning. Enkelt sett så fylls denna cache endast vid repetitiv läsning av samma data innan denna data hunnit avlägsnas från primär cache (ARC) i RAM. Och den fylls långsamt. Samt överlever inte omstart.

Som @xxargs säger bör du undersöka dina WD Green mer i detalj.

Det är svårt för mig att göra någon direkt jämförelse med min egen server, men jag testade lite överföring till mina ZFS-pooler genom en Windows 10-VM på samma VMware-host som min FreeNAS-server. Jag testade överföring mellan pooler, samt från en RAM-disk i Windows. Ingen pool har cache (L2ARC) eller log (SLOG), bara fyra (raid10) eller två (raid1) diskar.

Jag skriver filer i ca 180-280 MB/s (snittar runt 230) till en 60% fylld pool bestående av 4x WD Black 640GB i mostvarande raid10 (stripe+mirror). Dessa diskar har över 7 år på nacken.

Jag får även ca 60% av ovan prestanda (90-120 MB/s), men med något större variation (ibland över 200 MB/s för flera GB i sträck), när jag skriver en likvärdig fil till min andra pool som består av två Seagate NAS 4TB i en enkel raid1 (mirror.) Denna pool är precis över 80% full vilket är övre gränsen för vad som rekommenderas för prestanda.

Ovan resultat är med jumbo frames (MTU 9000) och vmxnet3 på båda sidor. Kör jag över ett E1000E-interface utan jumbo frames (MTU 1500) i Windows, mot vmxnet3 utan jumbo frames i FreeNAS, så går prestandan ner ca 10-20%.

Jag har minskat ner maximal tid innan en transaktionsgrupp skrivs till disk, från 5 till 2 sekunder, vilket jag tror (kanske inbillar mig) ger mig mer jämn prestanda. (Jag sätter "loader" type tunable "vfs.zfs.txg.timeout" till 2.)

Det kan också vara bra att utesluta nätverksrelaterat strul. FreeBSD, som FreeNAS baseras på, kanske helt enkelt fungerar sämre än Linux i din miljö.

Hur snabbt skriver du data till din pool? Testa t.ex. genom att skapa ett dataset utan komprimering och skriva data dit via "dd". Se till att mängden data du skriver inte är för liten så den helt äts upp av en transaktionsgrupp (1/8 av RAM per default).

Exempel för 10 GB: dd if=/dev/zero of=/mnt/minpool/test/zerofile bs=1G count=10

Jag har ca 18 GB RAM för FreeNAS, så min skrivcache ligger runt 2 GB, men skrivs också ut efter max 2 sekunder. Data nedan är från 3 körningar per pool.

2 diskar i raid1: 83, 88, samt 89 sekunder för 10 GB (115-123 MB/s)
4 diskar i raid 10: 45, 58, samt 51 sekunder för 10 GB (176-227 MB/s)

Hur snabbt kan du skriva över nätverket? Testa genom att över nätverket skriva en högt komprimerbar fil till ett dataset med lz4-komprimering igång. T.ex. kan du kopiera över en eller flera av dessa filer med enbart 0:or till btrfs-poolen, eller en RAM-disk för den delen. Windows kommer skicka all data som den är, men FreeNAS kommer applicera sin enkla, och i det här fallet extrema, komprimering, så du kommer i stort sett se hur snabbt du kan föra över i absolut bästa fall till en blixtsnabb pool.

Att direkt i FreeNAS skriva en fil med bara nollor till en pool med lz4-komprimering tar för mig ca 4-5 sekunder, dvs runt 2 GB/s.

För min even del verkar min Windows-VM slå i taket vid en snitthastighet på ca 250 MB/s från RAM-disk till FreeNAS via både SMB och iSCSI. För SMB ser jag en initial burst på 1-2 sekunder med nära dubbla hastigheten, oklart vad det kommer från. För iSCSI ser hastigheten ut att börja lågt för att sedan rampa upp mer långsamt.

Det här blev längre än jag tänkt mig... Hoppas det hjälper någon.

Tack för utförligt svar!
Nej jag vet att läs-cache inte hjälper skrivningar... Men är inte "cache" i terminalen en slog alltså skrivcache?
Nu kommer jag inte ihåg hur det såg ut i guit, men har för mig att jag kikade där när jag inte såg några förbättringar och att "cache" var zil? och att jag även testade med "det andra" bara för att utesluta att jag tog fel men blev ingen förbättring då heller..?

Nu tog jag bort FreeNAS VMen efter alla dessa tester utan några bra resultat och installerade en Rockstor-vm till för att köra ovan tester.
Så kan inte testa allt du skrev i ditt svar just nu, men visst kan installera en ny FreeNAS-vm och testa kanske till helgen.

Visa signatur

Klient: ASUS TUF Gaming X670E-Plus | AMD R9-7900X | Kingston FURY Beast DDR5-6000MHz 32GB | MSI GTX 1070Ti | Lian Li PC-O11XL | Cutom H20-loop ½"
Server: Supermicro H11SSL-i | Epyc 7551P | 8x16GB 2933 RDIMM | ConnectX5 2x25gig | 2xLSI 9400-16i | 14x4TB zfs-raid60 | NVMe/900p logs/cache/system