Schijven voor simultane en intense lees- en schrijfprocessen

[BramVroy]

Goedemiddag Tweakers

Ik ben professioneel aan het werk in AI, information retrieval, en data mining. Het meeste werk doe ik dan ook op onze servers of op een cluster. Vaak ben ik echter met zoveel tegelijk bezig, dat het niet verantwoord is om de servers of de cluster zo vaak in te plannen. Daarom wil ik mijn eigen PC gebruiken om de simpelere processen uit te voeren, of om eigen projecten in dit genre uit te voeren.

Mijn huidige computer bestaat uit de volgende onderdelen:

#	Product
1	Intel Core i7-7700K Boxed
1	Asus ROG Strix Z270E Gaming
1	MSI GeForce GTX 1070 GAMING X 8G
2	WD Green WD20EARX, 2TB
1	Fractal Design Define S
1	Scythe Mugen 5
2	Corsair Vengeance LED CMU16GX4M2C3200C16R
1	BitFenix Whisper BWG550M
1	Sandisk Ultra II SSD 960GB

De Greens heb ik met WDIDLE3 'gehackt'. Een van hen gebruik ik om mijn data crunching op te doen. Het gaat voornamelijk om eenvoudige acties die niet veel CPU nodig hebben, maar wel veel disk access nodig hebben (bv. grote XML bestanden uitlezen en omvormen, of heel veel CSVs wegschrijven, of bestanden comprimeren, enz.). Deze acties kunnen vaak in parallel lopen.

Momenteel lukt het op een enkele green op zich wel, maar de snelheid is beperkt. Ik kan bijvoorbeeld 'slechts' drie directories met XML-files tegelijkertijd inlezen en op hetzelfde ogenblik informatie hieruit wegschrijven (dus 3x lees, 3x schrijf) en de schijf zit op 100% gebruik.

Ik vroeg me af of hier geen oplossing voor te bedenken is (die het verder gebruik van m'n OS met rust laat). Zou er bijvoorbeeld een raid-oplossing zijn, waar er meer bandbreedte beschikbaar is op de schijf/schijven? Of zijn er simpelweg schijven die veel beter voor dit doel geschikt zijn (Blues, Reds...)?

[Tsurany]

Je kan beter naar een SSD kijken. Het probleem is dat bij traditionele harde schijven een fysieke leeskop moet bewegen om een ander deel van de harde schijf aan de spreken. Je bent dus enorm beperkt door een fysieke kop die van de ene sector naar de andere sector gaat. Daar heeft een SSD geen last van.

Het lijkt me dus geen beperking van bandbreedte maar puur access times. Daar gaat RAID niet of nauwelijks bij helpen.

[ Voor 16% gewijzigd door Tsurany op 19-07-2017 15:07 ]

[Hann1BaL]

Wat @Tsurany zegt.is juist. Dit lijk je vooral op te kunnen lossen met SSD(s). Dat is de eenvoudigste oplossing.

[CurlyMo]

Ik zou eens kijken naar enterprise SSD's zoals de Intel S3700. Die dingen zijn gemaakt voor extreem lezen en schrijven tegelijk in lage queue depths.

[BramVroy]

Ik dacht eerlijk gezegd altijd dat SSDs niet bedoeld waren voor 'server'operaties waar veel data geschreven en herschreven moet worden. Het is wel de bedoeling dat de schijf/schijven een tijdje meegaan, aangezien het maar van mijn eigen spaarcentjes komt.

Is wat ik dacht dus fout, en kan je SSDs wel degelijk gebruiken als data-crunch schijf waar heel vaak dingen naar geschreven, overschreven en uit gelezen worden?

@Tsurany Bedankt voor de info over de leeskop en access time!
@CurlyMo Wat bedoel je met 'lage queue depths'?

[anboni]

SSDs zijn prima geschikt voor langdurig veel lezen en schrijven: nieuws: Laatste ssd in Duitse duurtest bereikt 9,1PB aan schrijfacties

Grootste bezwaar is vooralsnog de prijs per GB die nog flink hoger ligt dan van een magnetische disk (scheelt een factor 10).

[ Voor 4% gewijzigd door anboni op 19-07-2017 15:55 ]

[CurlyMo]

Queue depth is the number of I/O requests (SCSI commands) that can be queued at one time on a storage controller. Each I/O request from the host's initiator HBA to the storage controller's target adapter consumes a queue entry. Typically, a higher queue depth equates to better performance.

De meeste benchmarks die je zult zien zijn geoptimaliseerd voor een hoge queue depth, terwijl diezelfde SSD's significant langzamer zijn in een lage queue depth (=1). De S3700 van Intel staat om drie dingen bekend:
1. Een enorm hoge prestatie op een queue depth = 1
2. Een enorme prestatie consistentie.
S3700


Samsung 840 Pro

3. Een enorme write endurance (hoe vaak kan je hem overschrijven).

Endurance: 10 drive writes per day for 5 years

Wat betreft het simultaan lezen en schrijven hier een vergelijking met een oude rot (crucial mx100):


Het is een wat ouder type SSD, daarom zie je vaak ook oudere types van andere merken in de benchmarks. Dat neemt niet weg dat dit type nog vrijwel ongeëvenaard snel is (voor een specifiek doeleind).

PS. ik heb er twee te koop staan

[BramVroy]

@CurlyMo Bedankt voor de info en het aanbod! 200Gb is helaas te weinig voor me, ik werk al gauw met corpora die 400Gb groot zijn. Ik zal dus nog wat geld opzij moeten houden de komende maanden om een 2Tb enterprise SSD te pakken te kunnen krijgen!

[Tsurany]

Is dit geen vrij eenvoudige business case naar je werkgever toe? Investeer eenmalig X tegenover tijdswinst Y? Zakelijk gezien moet dit peanuts zijn

[BramVroy]

Tsurany schreef op woensdag 19 juli 2017 @ 16:29:
Is dit geen vrij eenvoudige business case naar je werkgever toe? Investeer eenmalig X tegenover tijdswinst Y? Zakelijk gezien moet dit peanuts zijn

Als doctoraalstudent heb je niet veel te eisen Maar het zou ook voor persoonlijk werk en bijjobs dienen, dus is niet volledig te verantwoorden.

[johnkeates]

Of koop meerdere kleinere SSD's en stop ze in een ZFS pool?

[BramVroy]

johnkeates schreef op woensdag 19 juli 2017 @ 16:32:
Of koop meerdere kleinere SSD's en stop ze in een ZFS pool?

Ik ken er niet genoeg van om daarmee aan de slag te gaan vrees ik.

[dcm360]

johnkeates schreef op woensdag 19 juli 2017 @ 16:32:
Of koop meerdere kleinere SSD's en stop ze in een ZFS pool?

ZFS en SSD's is mogelijk geen gelukkige combinatie

[johnkeates]

dcm360 schreef op woensdag 19 juli 2017 @ 21:26:
[...]

ZFS en SSD's is mogelijk geen gelukkige combinatie

Tenzij je een SSD zonder interne GC koopt is TRIM niet zo spannend als je denkt dat het is.

[dcm360]

johnkeates schreef op woensdag 19 juli 2017 @ 23:37:
[...]


Tenzij je een SSD zonder interne GC koopt is TRIM niet zo spannend als je denkt dat het is.

De eerste SSD die zich goed kan houden zonder heb ik zelf nog niet gehad. Een Samsung PM851 zonder TRIM kan zich wat betreft prestaties meten met een USB-stick. Een Corsair Force 3 (welke ik sowieso niet een fatsoenlijke schijf ga noemen, daar niet van) deed me terugdenken aan de tijd van diskettes. Een Crucial M500 heb ik met licht servergebruik in mijn thuisserver in 3 jaar tijd door de TBW gekregen (iets met write amplification).

Misschien doen nieuwere SSD's het beter, maar ik verwacht dat, zeker voor SSD's gericht op consumenten, niet. Fabrikanten van SSD's gericht op consumenten houden er gewoon geen rekening mee dat de schijf in een systeem zonder ondersteuning voor TRIM terecht komt.

[johnkeates]

dcm360 schreef op donderdag 20 juli 2017 @ 08:41:
[...]

De eerste SSD die zich goed kan houden zonder heb ik zelf nog niet gehad. Een Samsung PM851 zonder TRIM kan zich wat betreft prestaties meten met een USB-stick. Een Corsair Force 3 (welke ik sowieso niet een fatsoenlijke schijf ga noemen, daar niet van) deed me terugdenken aan de tijd van diskettes. Een Crucial M500 heb ik met licht servergebruik in mijn thuisserver in 3 jaar tijd door de TBW gekregen (iets met write amplification).

Misschien doen nieuwere SSD's het beter, maar ik verwacht dat, zeker voor SSD's gericht op consumenten, niet. Fabrikanten van SSD's gericht op consumenten houden er gewoon geen rekening mee dat de schijf in een systeem zonder ondersteuning voor TRIM terecht komt.

Je weet dat TRIM niks anders is dan een ATA commando dat het OS kan gebruiken om vrije blokken expliciet te markeren? Het is geen magische disk-conditioner... In principe zorgt de NAND controller dat garbage collection sowieso al draait om cellen die na een write naar een andere cel niet meer gebruikt worden gecleared worden. Dat moet altijd al om dat je geen individuele cellen kan wissen, en meestal complete pages/words(?) moet wissen. Praktisch betekent dat ook dat een kleine write meerdere pages kan invalideren die dan allemaal verplaatst moeten worden naar nieuwe pages (waar write amplification vandaan komt).

Het enige wat TRIM dus kan doen, is dat proces sneller laten lopen, of vaker, of accurater.

[dcm360]

Ik weet prima wat TRIM doet, maar bedankt voor de uitleg

Wat je hierbij misschien vergeet, is dat ZFS (en BTRFS) doet aan CoW. Bij het overschrijven van data krijgt de SSD dus een write naar een andere sector, en weet niet dat de oude sector weer beschikbaar is en kan die cell dus niet vrijgeven. De SSD heeft dus een heel ander beeld van welke ruimte beschikbaar is dan het filesystem, en dan is dit alleen nog maar voor data die overschreven wordt. Verwijderde bestanden 'ziet' een SSD sowieso al niet. De 'magie' van TRIM lost dit verschil in inzicht op.

Bij de twee SSD's die ik noemde met prestatieterugloop waren de prestaties weer in orde na het inschakelen van TRIM (kwestie van de onhandige configuratie van BTRFS/LUKS aanpassen), wat een indicatie lijkt te geven dat TRIM ruim belangrijker is dan jouw vermoeden.