Article Number: 000136940
| Bemærk: |
| CacheCade-funktionen er tilgængelig fra første halvdel af kalenderåret 2011. |
| Bemærk: |
| Hvis du vil bruge CacheCade til den virtuelle disk, skal skrive-og læsepolitikken for den harddiskbaserede virtuelle disk indstilles til Write Back eller Force Write Back, og læsepolitikken skal være indstillet til Read Ahead eller Adaptive Read Ahead. |
Relaterede artikler og hvidbøger:
Måling af ydeevnebrugere
forstår muligvis ikke de bedste metoder til at teste SSD- og CacheCade-enheder™, så de kan observere fordelene ved solid state-lager. Denne artikel forsøger at give vejledning om de optimale ydeevnespecifikationer, som kan anvendes generisk på de fleste af værktøjerne til ydeevnetest.
Brugen af værktøjer til test af ydeevnen for at opnå optimal ydeevne afhænger naturligvis af brugerens forståelse af, hvordan den enhed, der testes, forventes at fungere.
Blokstørrelse: SSD- og CacheCade-enheder opfører sig optimalt, når de bruges med små blokstørrelser i stedet for store blokke. Når IO læses eller skrives, er processen med at vælge den aktive celle elektronisk og er ikke afhængig af en fysisk hovedbevægelse som med mekaniske diske. Det betyder, at solid state-enhederne kan reagere meget hurtigt på en vilkårlig IO med små blokke og kan opnå mere end 10.000 IOPS, hvor en mekanisk disk kæmper med at opnå større end 200 IOPS.
Kødybde: SSD'er har en dyb kølængde med mulighed for 64 udestående IO'er, betydeligt mere end en standard SAS-disk, typisk ved 16 udestående IO'er. Denne dybe kødybde giver meget mere fleksibilitet til disken, da den mindsker diskens afhængighed af controlleren for at levere IO'er rettidigt. Controlleren kan opretholde køen, når den kan, og lade disken arbejde igennem den uden at skulle vente på controlleren.
Efterhånden som teknologien ændrer sig, og SSD'er udfører flere opgaver parallelt, vil diskkøens dybde sandsynligvis blive endnu dybere. Værktøjet til ydeevnetest skal bruges til at sondere for den mest effektive kødybde, så en forøgelse af denne kødybde fra tid til anden kan medføre bedre figurer med forskellige enheder.
Cache-bundet: Det er vigtigt, at ydelsesværktøjet ikke er cachebundet, da det betyder, at al IO serviceres af controllercachen. Dette sker, når testfilens størrelse er forkert angivet og kan passe helt ind i controllerens cachelager. Når dette sker, når IO'erne aldrig når frem til diskene, og den returnerede ydeevne for IO normalt er begrænset af hastigheden på PCI-bussen, så der kan observeres falske ydelsesfigurer på mere end 3 GB/sek. Du skal altid overbelaste cachen ved at vælge en testfilstørrelse, der er større end controllerens cache-lager.
CacheCadeCacheCade
skal benchmarkes forskelligt fra standard SSD-drev, da denne teknologi kun bruges til at cachelæse anmodninger, ikke skriveanmodninger. Der oprettes derfor en udfordring, når en bruger ønsker at benchmarke en CacheCade-løsning, da standardmetoden til blot at læse eller skrive blokke ikke vil give de forventede resultater, medmindre cachen er forberedt.
For yderligere at beskrive denne egenskab for CacheCade skal du overveje en situation, hvor mekaniske diske kun er læsecachelagret, og du ønsker at køre IOMeter for at validere, at CacheCade kan levere den forventede ydeevne. IOMeter opretter først en testfil, hvorfra den udfører sine IO-handlinger. Denne fil skrives til destinationslageret, og filen cachelagres derfor ikke af CacheCade. IOMeter vil derefter begynde at udføre dets IO-handlinger på filen, men da vi allerede forstår, er det ikke i cachen, så de indledende IO-handlinger vil blive udført på de mekaniske diske. Denne indledende cache-fejl (hvor de ønskede data ikke er tilgængelige i cachen) påvirker den første del af ydeevneanalysen negativt, så der skal udføres trin for at eliminere dette resultat fra statistikken. CacheCade implementerer også cachelagring kun på datagenveje, hvilket betyder, at der ofte skal opnås adgang til data, før de cachelagres. Vi er også nødt til at overvinde denne effekt for at måle ydeevnen på et praktisk niveau.
For at opnå vores forventninger skal vi sikre, at testfilen er tilstrækkelig til, at den kan cachelagres. Dette gøres ved at lade IOMeter køre en læsetest i længere tid. Husk, at størrelsen på testfilen og hastigheden på IO-handlingerne i MD/sek. vil afgøre, hvor lang tid det tager for filen at blive cachelagret. Filen skal læses FLERE gange, før den bliver cachelagret, så du kan gå efter at læse filen 5 gange mere ved at angive filens størrelse med hastigheden i MB/sek. * 5.
F.eks. en testfil på 4 GB, der læses ved 40 MB/sek. = 100 sekunder * 5 = 500 sekunder.
I dette eksempel skal du lade en READ-test køre i mindst 8,5 minutter, for at det tilsvarende af 5 læsehandlinger kan udføres over hele filen. Denne gang kaldes det "varm op"-tid" for cachen.
Efter at have fuldført mere end 8,5 minutter med varm varme, skal du afslutte ydeevnetesten. Dette vil efterlade IOMeters testdestinationsfil i cachen, da der ikke vil være nogen proces til at tømme data fra CacheCade, da filen bevares, efter programmet er lukket. Genstart derefter det samme ydeevneprogram, og vælg de samme måldrev. Når IOMeter nu begynder at læse fra filen, vil dataene allerede være i cache (et cache-tryk), og ydeevnen bør ligne cacheCades i optimeret tilstand.
Vigtige punkter:
Når du kører andre måleværktøjer for ydeevne, er der nogle konfigurationsanbefalinger, der skal følges.
For SSD og CacheCade:
Servers
22 Feb 2022
7
How To