RAID10 stripe size voor (My)SQL data opslag

[sjender101]

Goedemorgen,

Op internet is veel te vinden over RAID10 stripe size.
Maar alles spreekt elkaar behoorlijk tegen.
De ene site zegt simpelweg: zo groot mogelijk.
De andere zegt: voor kleine files een grote strip size, voor grote files een kleine stripe size.

Ik heb een RAID 10 opstelling van 4x 1TB WD RE4 schijven op een LSI 9750-4i RAID controler.
Ik kan de stripe size instellen op 16k, 64k of 256k.
Ik weet ook wat stripe size inhoudt, echter kom ik er maar niet achter wat beter is voor mijn applicatie.
De betreffende server heeft de bestanden voor een drukke MySQL en MSSQL database, de database software zelf staat op een andere server, dit zijn puur de bestanden die via iSCSI richting de front-end database servers gaan.
De betreffende server is een Windows 2012 server.

Wat is beter, zo veel mogelijk reads van dezelfde schijf, of moet je juist zoveel mogelijk op verschillende schijven je data verzamelen?

[com2,1ghz]

Laad je je database niet in je geheugen? Dan heb je niet zo veel reads meer nodig lijkt mij.

[Verwijderd]

Hier bestaan verschillende gedachten over. Cruciaal hierbij is of je opslagapparaten latency-capped zijn zoals hardeschijven, of transfer-capped zoals solid state drives. Bij laatstgenoemde wil je de stripesize kleiner houden om al eerder voordeel te hebben van één I/O request dat door twee of meer apparaten wordt uitgevoerd.

Echter, bij mechanische hardeschijven zit je met een tegenovergestelde situatie waarbij vooral het seeken dodelijk is voor performance. Door hardeschijf A te laten seeken naar een locatie voor de 1e I/O request, blijven schijven B, C en D beschikbaar voor andere seeks die elk hun eigen I/O request afhandelen. In dit geval moet de stripesize groot genoeg zijn zodat er geen 2 apparaten nodig zijn om één I/O request af te handelen. Hier geldt dus: hoe groter hoe beter. Met 256K is de kans heel klein dat een 8K random read door twee apparaten moet worden afgehandeld. Dat is nog steeds mogelijk bij non-aligned I/O zoals 252K - 260K dan zit je net over een drempel van twee stripe boundaries.

In jouw geval zou ik kiezen tussen 64K en 256K. Heel veel uitmaken zal het niet. Maar je moet in elk geval de stripe niet te klein maken. Zou je SSDs gebruiken, dan is 16K of zelfs lager wellicht beter omdat voor kleine read/write I/O je dan al een lagere latency hebt ook met een lage queue depth. Hoe hoger de stripesize, des te meer afhankelijk je wordt van queue depth om prestatievoordeel te behalen. Bij drukke serverapplicaties is er bijna altijd genoeg queue depth - dus op zich hoef je je hier niet zo druk over te maken.

[Midas.e]

sjender101 schreef op dinsdag 23 april 2013 @ 11:28:
Goedemorgen,

De betreffende server heeft de bestanden voor een drukke MySQL en MSSQL database, de database software zelf staat op een andere server, dit zijn puur de bestanden die via iSCSI richting de front-end database servers gaan.
De betreffende server is een Windows 2012 server.

Wat is beter, zo veel mogelijk reads van dezelfde schijf, of moet je juist zoveel mogelijk op verschillende schijven je data verzamelen?

Meten is weten in dit geval, heb je al eens een iops meting gedaan of laten doen? vaak zal je dan zien dat juist 1 bepaald onderdeel de vertragende factor is, kan iscsi zijn maar net zo makkelijk de gebruikte disks/controller combinatie.

Zelf ben ik niet zo van databases via iscsi te laten lopen, vaak zit hier toch een vertragende factor in. Hierna zou ik pas naar cluster sizes gaan kijken.

[Verwijderd]

Midas.e schreef op dinsdag 23 april 2013 @ 12:27:
Zelf ben ik niet zo van databases via iscsi te laten lopen

Het voordeel hiervan is echter wel dat doordat de client het filesystem bestuurt deze ook lokale caches kan aanhouden en de eigen RAM dus kan en zal gebruiken voor filecache. Bij NAS-protocollen zoals Samba (CIFS) en NFS is dat niet het geval, omdat de client niet kan weten of de server in de tussentijd de files heeft geupdate. Je kunt wel met local locking werken, maar in hoeverre dat de filecache beïnvloed weet ik niet.

Met een iSCSI-volume kun je je RAM dus wel gebruiken om alles te cachen, daardoor gebruik je het iSCSI-volume uiteindelijk vooral voor de writes omdat alle reads door de RAM filecache worden afgehandeld zolang je RAM groot genoeg is voor de dataset.

[Q]

De latency die iSCSI oplevert staat in het niet tov de rest van de storage layer, lijkt mij dus iSCSI lijkt mij niet zo'n issue.

Mijn benchmarks onder Linux betreffende seriele read/write performance gaf de beste resultaten met een chunk size van 64Kb. Maar dat kan voor jouw situatie anders zijn. Wat de impact op random IO is weet ik niet.

Oh wacht:

http://louwrentius.com/bl...of-different-raid-levels/

[ Voor 61% gewijzigd door Q op 23-04-2013 17:14 ]

[Verwijderd]

Om meerdere redenen niet zo'n geschikte benchmark. De interpretatie van de resultaten is de sleutel, maar daar gaat het vaak fout; men weet niet exact wat men test en dus ook niet hoe men de resultaten moet interpreteren. Zo is write-buffering uitgeschakeld, wat sowieso al heel kunstmatig is vooral voor parity RAID levels.

Voor de invloed van stripesize kun je ook kijken naar de simpele doch interessante benchmarks van Jason inzake FreeBSD geom_stripe:

http://submesa.com/data/raid/geom_stripe

De onderste drie grafieken zijn het meest interessant. Ook de UFS sequential read/write benchmarks zijn interessant vanwege de invloed van read-ahead, hetgeen de queue depth beïnvloedt.

[Q]

Mijn benchmark was precies om de write penalty van parity raid te demonstreren.

Qua read is het oke, maar ik heb geen grotere stripe sizes getest, dus ik kan de resultaten 1MB stripe is best for random io, niet staven. Zal ik nog eens testen, ben wel benieuwd. Want dan zou mijn blog post niet kloppen.

Wat ik in deze link

http://submesa.com/data/raid/geom_stripe

mis is het hele latency verhaal. Want hogere queue depths zijn leuk, maar zeker met een database telt latency enorm mee. IOPS zijn betekenisloos zonder de bijbehorende latency te weten.

[ Voor 23% gewijzigd door Q op 23-04-2013 19:15 ]

[Q]

Ik zie geen gevolgen voor de random read performance met 4K size reads op een 10GB test file met verschillende chunk sizes.

EDIT: de oorspronkelijke afbeelding hieronder was van onjuiste data. Dit is gecorrigeerd maar de essentie is onveranderd.



Mogelijk is er impact als de request size van 4K groter wordt. De genoemde benchmark testte ook met grotere request sizes.

Er is trouwens wel een issue. 6 x ~70 IOPS per drive = ~ 420 IOPS, wat je ook in de grafiek ziet. Maar omdat mijn test data set maar 10 GB is zou ik meer IOPS verwachten.

[ Voor 99% gewijzigd door Q op 24-04-2013 23:02 ]

[Verwijderd]

Uiteindelijk zijn je hardeschijven beperkt door rotational delay, dus ook al is de seekafstand beperkt, dan nog word je hierdoor beperkt.

Wat uit jouw test blijkt is dat de striping goed werkt en in jouw geval maakt het niet uit, omdat:

1) je request size is altijd lager dan de stripesize. Dat heeft tot gevolg dat een I/O request door maximaal één hardeschijf wordt afgehandeld. Dit is belangrijk, want als je stripesize kleiner wordt dan de request size, gaan meerdere hardeschijven één I/O request afhandelen. Dit is voor hardeschijven minder gunstig omdat je vooral seeks wilt beperken. Als je een random read hebt, wil je dat één hardeschijf zich hiermee bemoeit. De overige x schijven blijven dan beschikbaar voor overige I/O requests. Elke schijf handelt dus individueel één request af; dat geeft de beste prestaties bij striping en random I/O.

2) jouw reads aligned zijn op 4K boundaries, als dat niet zo was, had je ook bij huidige stripesizes verschil kunnen zien, omdat bij kleinere stripesizes er boundary crossings voorkomen; een 4K request kan dan wel een boundary van een 128K stripesize overschrijden (126K-130K dus twee stripes). Als dat gebeurt, kost je dat prestaties omdat je nu 2 disks naar eenzelfde locatie laat seeken ipv 1 disk. Daardoor zijn er minder disks beschikbaar voor overige read requests.

Doe je test nog eens en gebruik kleinere stripesizes:
- 512-byte, 4K, 16K, 32K, 64K, 128K, 1M, 16M

Pak dan ook een grotere request size, zoals 16K en kijk welk effect dit heeft. Beter is om een mix te gebruiken van request sizes tussen 4K en 128K. Dit is ook gebruikt in de test op submesa.com en zo zou je jouw benchmarkresultaten kunnen koppelen aan de resultaten van Jason.

Je zult dan zien dat de stripesize dan wel de resultaten gaat beïnvloeden. Dat komt omdat je dan niet langer alle disken kunt laten werken aan één I/O request, maar dat twee of zelfs meer schijven bezig zijn met één request en dat zal de resultaten beperken.

[Q]

Verwijderd schreef op woensdag 24 april 2013 @ 14:43:
Uiteindelijk zijn je hardeschijven beperkt door rotational delay, dus ook al is de seekafstand beperkt, dan nog word je hierdoor beperkt.

De verminderde seek distance heeft dus veel minder impact op de performance dan je zou verwachten en de rotational delay zou het probleem hier zijn.

Ik heb echter wel gebencht met 7200 RPM disks en daar 100+ IOPS uit weten te halen met kleine partities of test file sizes, ik moet dat nog eens opzoeken, maar hoe dat zich in een array verhoudt...

Wat uit jouw test blijkt is dat de striping goed werkt en in jouw geval maakt het niet uit, omdat:

1) je request size is altijd lager dan de stripesize. Dat heeft tot gevolg dat een I/O request door maximaal één hardeschijf wordt afgehandeld. Dit is belangrijk, want als je stripesize kleiner wordt dan de request size, gaan meerdere hardeschijven één I/O request afhandelen. Dit is voor hardeschijven minder gunstig omdat je vooral seeks wilt beperken. Als je een random read hebt, wil je dat één hardeschijf zich hiermee bemoeit. De overige x schijven blijven dan beschikbaar voor overige I/O requests. Elke schijf handelt dus individueel één request af; dat geeft de beste prestaties bij striping en random I/O.

2) jouw reads aligned zijn op 4K boundaries, als dat niet zo was, had je ook bij huidige stripesizes verschil kunnen zien, omdat bij kleinere stripesizes er boundary crossings voorkomen; een 4K request kan dan wel een boundary van een 128K stripesize overschrijden (126K-130K dus twee stripes). Als dat gebeurt, kost je dat prestaties omdat je nu 2 disks naar eenzelfde locatie laat seeken ipv 1 disk. Daardoor zijn er minder disks beschikbaar voor overige read requests.

Dat zal zeker verklaren waarom ik geen verschil zie.

Doe je test nog eens en gebruik kleinere stripesizes:
- 512-byte, 4K, 16K, 32K, 64K, 128K, 1M, 16M

Ik heb al eerder een 4K 64K en 128K chunk getest in een 6 disk RAID 10 (zelfde disks).



Ook hier geen verschil, maar ook hier is de request size 4K.

Pak dan ook een grotere request size, zoals 16K en kijk welk effect dit heeft. Beter is om een mix te gebruiken van request sizes tussen 4K en 128K. Dit is ook gebruikt in de test op submesa.com en zo zou je jouw benchmarkresultaten kunnen koppelen aan de resultaten van Jason.

Je zult dan zien dat de stripesize dan wel de resultaten gaat beïnvloeden. Dat komt omdat je dan niet langer alle disken kunt laten werken aan één I/O request, maar dat twee of zelfs meer schijven bezig zijn met één request en dat zal de resultaten beperken.

MySQL werkt met 16KB page size en dat lijk je ook terug te zien in deze bron:

http://www.dbasquare.com/...analyzing-io-performance/

Deze lijkt rond de 16 KB te fluctueren, maar ik weet niet of dit echt klopt.



Bron over page sizes: http://docs.aws.amazon.co...view.ProvisionedIOPS.html

MSSQL heeft een 8K page size en dit artikel:

MSDN: SQL Server Best Practices Article

Geeft aan dat je voor random i/o je kunt focussen op 8K I/O sizes.

Hier lees ik ook over wat grotere request sizes voor MSSQL:

http://sqlserverio.com/20...ms-capturing-io-patterns/

Ik denk dat voor de topic starter 64K of 128 K of zelfs 256 K chunk size niet uit gaat maken. Zolang je chunk size maar groter is dan je request size. Maar de TS heeft het over een stripe size en dat is chunk size x aantal disks (parity niet mee gerekend). Bij 16K requests wil je dus conform wat CiPHER aangeeft 2 disks is dus een minimum 32K stripe size hebben. 16K valt dus af, 64K is de eerste optie die zinnig is, die zou dan in mijn verhaal resulteren in een 32K chunk size.

Weet niet of het al is opgemerkt maar een RAID 10 van 4x 1TB disks gaat niet zulke spannende IOPS opleveren. 4 disks x ~75 iops = 300 IOPS? Schrijven is de helft, 150 IOPS. Als dit drukke databases zijn dan gaat dat heel spannend worden denk ik. Wat precies 'drukke databases' zijn weet ik niet, maar dan ga ik zelf al snel aan 10K of 15K sas denken en meer spindels, of natuurlijk SSD.

Ik zal mijn benches ook nog eens draaien maar dat duurt even.

[ Voor 9% gewijzigd door Q op 24-04-2013 22:31 ]

[Q]

Verwijderd schreef op woensdag 24 april 2013 @ 14:43:

Je zult dan zien dat de stripesize dan wel de resultaten gaat beïnvloeden. Dat komt omdat je dan niet langer alle disken kunt laten werken aan één I/O request, maar dat twee of zelfs meer schijven bezig zijn met één request en dat zal de resultaten beperken.

En dat klopt 100% exact. Ik doe hier random I/O met een 8K request size. Zie wat er gebeurt met een 4K chunk size (dus 8K stripe (RAID 10)).



De I/O performance van een 4K chunk size bij een 8K request size stort in omdat voor iedere I/O request meerdere disks aan het werk moeten.

[ Voor 10% gewijzigd door Q op 24-04-2013 23:24 ]