SSD cache disk

[Kwomkwommr]

Hallo,

Ik heb al jaren een wannebe "server" actief welke 4x 1TB disks heeft. Nu ben ik dmv een zelfbouw scriptje in bash en in php al een aantal jaar sites aan het crawlen en hier van URL's te verzamelen en aan het indexeren in een mysql db.

Het loopt zo opzich prima, maar ik zou graag flashcache voor mijn lvm disks zetten zodat het allemaal iets wat sneller zou verlopen. Ook voor andere vm's op mijn kvm host gezien de vm die urls verzameld/indexeert onderhand een beste iowait (2 +) veroorzaakt.

En ik snap dat het ook vast aan de applicatie ligt, ik wil gewoon veel tegelijk doen.. houd in dat er ~7 processen tegelijk een url ophalen en hier informatie van verzamelen. Indexes in MySQL voor selects en atime staat uit op de vm.

Het is een Jetway mobile cpu moederbord matx met een i7-3612QM - 16GB DDR3 en 4x 1TB WD blue disks in raid 5 mdadm (Eerder was het raid 10 maar gezien ruimte gebrek heb ik deze omgezet in een raid 5 opstelling). Voor deze omzetting had ik ook last van een hoge iowait tho..

Ik heb een jaar geleden de volgende ssd aangeschaft : Kingston SSDNow MS200 mSATA - 60GB deze ssd verdween na ongeveer 3 weken in het niks als ik deze in combinatie met flashcache gebruikte op mijn volume group in lvm. Ook ZFS met een cache device heb ik geprobeerd en dit deed exact het zelfde. Na een herstart kwam deze weer terug, maar ik moest echt de pc herstarten. Jammer dus...

Eigenlijk zoek een SSD welke wel betrouwbaar is voor dit soort "workload".. iemand ervaring met een bepaald type of moet ik dan gelijk een enterprise ssd aanschaffen ?

De kvm host op ubuntu loopt gemiddeld op een load van 3~4 met een iowait van 2 + de vm zelf ook ongeveer 2 en met een gemiddelde load van 4. En ik kan duidelijk zien dat het aan de io ligt welke beschikbaar is gezien het cpu gebruik nihil is.

[fvdberg]

ja: geen SSD maar extra geheugen bijprikken en een ramdisk inzetten.

[Kwomkwommr]

En dan... Op de ramdisk iets wegschrijven wat weg is na een reboot dan moet je het indirect nog op de disks zien weg te schrijven?

[DataGhost]

Je zegt dat het een cache disk is, cache is per definitie volatile dus een reboot, verwacht of onverwacht, zou geen enkele impact mogen hebben op je applicatie. Uiteindelijk moet het gewoon op je disks terecht komen en dat gaat traag zijn, zeker in raid5, dat is ongeveer de traagst mogelijke mode voor random writes.

Als het allemaal op je grote disk-array terecht moet komen en de SSD niet gebruikt wordt om intermediate results op te slaan die vervolgens in minder data/writes weggeschreven kunnen worden naar je array, heb je gewoon 0 winst. Je zal dan alle disks in je array moeten vervangen voor SSD's.

Je kan ook naar je applicatie kijken, waarschijnlijk is er met het design het een en ander mis. Elke keer als je een insert doet trigger je daarbij een hele index rebuild in een grote table. Als je 10 URLs in 1 insert weet te doen trigger je nog maar 1/10 van het aantal rebuilds. Probeer alles te batchen in een (of meerdere) kleine/temporary table(s) en dat dan als groot blok weg te schrijven in je master.

[ Voor 56% gewijzigd door DataGhost op 29-06-2017 09:39 ]

[Kwomkwommr]

Ligt er maar net aan of je aan writeback doet of write through.. voor random lees operaties zal ssdcache zeker wel zin hebben gezien je random io ook gewoon slecht is met raid 5. Houd in dat waarschijnlijk de reads van de database allemaal van de ssd komen omdat er een aantal grote tabellen veel worden geraadpleegd en overheen word gelopen. Writes zijn een paar inserts, maar gezien dit redelijk gecombineerd gebeurd denk ik niet dat dit de bottleneck is.


Voor er een insert gebeurd word er eerst in 3 tabellen gekeken of dit record al bestaat, zoja misschien een update. En anders een insert.

En inderdaad het kan best aan de applicatie liggen het is een uit de hand gelopen hobby projectje...

[DataGhost]

RAID5 is met kleine records opzich best okee qua random read, maar dus compleet niet met random write. Voor read zou je met fatsoenlijke indices geen problemen mogen hebben, zeker niet als je 16GB RAM erachter hebt hangen want alles vliegt gewoon die cache in, en die is nog steeds stukken sneller dan je SSD. Daarom dat ik ervan uitga dat je write performance slecht is. Als je tabellen groot zijn zijn index rebuilds een stuk duurder.