| Merk: |
| CacheCade-funksjonen er tilgjengelig fra første halvdel av kalenderåret 2011. |
| Merk: |
| Hvis du skal bruke CacheCade for den virtuelle disken, må skrive- og leseretningslinjene for den harddiskbaserte virtuelle disken være angitt som Write Back (tilbakeskriving) eller Force Write Back (tvungen tilbakeskriving), og leseretningslinjene må være angitt som Read Ahead (forhåndslesning) eller Adaptive Read Ahead (adaptiv forhåndslesing). |
Relaterte artikler og rapporter:
Måling av ytelsesbrukere
forstår kanskje ikke de beste metodene for å teste SSD- og CacheCade-enheter™, slik at de kan observere fordelene med SSD-lagring. Denne artikkelen prøver å gi veiledning om optimale ytelsesspesifikasjoner som kan brukes generelt på de fleste av verktøyene for ytelsestesting.
Bruken av verktøy for ytelsestesting for å oppnå optimal ytelse er selvfølgelig avhengig av nivået av forståelse av brukeren for hvordan enheten som testes, skal fungere.
Blokkstørrelse: SSD- og CacheCade-enheter fungerer optimalt når de brukes med små blokkstørrelser i stedet for store blokker. Når I/U leses eller skrives, er prosessen med å velge den aktive cellen elektronisk og avhenger ikke av fysisk bevegelse på hodet som med mekaniske disker. Dette betyr at SSD-enhetene kan reagere svært raskt på tilfeldig IO med små blokker og kan oppnå mer enn 10 000 IOPS der en mekanisk disk vil slite med å oppnå mer enn 200 IOPS.
Kødybde: SSD-disker har en dyp kødybde, med de fleste mulighet for 64 utestående IO-er, betydelig mer enn en standard SAS-disk, vanligvis ved 16 utestående IO-er. Denne dype kødybden gir disken mye mer fleksibilitet, ettersom den reduserer diskens avhengighet av kontrolleren for å gi IO-er i tide. Kontrolleren kan opprettholde køen når den kan, slik at disken kan fungere gjennom den uten å måtte vente på kontrolleren.
Etter hvert som teknologien endrer seg og SSD-en utfører flere oppgaver parallelt, vil diskkødybden sannsynligvis bli dypere igjen. Verktøyet for ytelsestesting må brukes til å undersøke for den mest effektive kødybden, så å øke denne kødybden fra tid til annen kan føre til bedre figurer med ulike enheter.
Hurtigbufferbundet: Det er viktig at ytelsesverktøyet ikke er bundet av hurtigbufferen, fordi all I/U blir vedlikeholdt av kontrollerens hurtigbuffer. Dette skjer når testfilstørrelsen er feilaktig angitt og kan monteres fullstendig i kontrollerhurtigbufferen. Når dette skjer, vil IO-ene aldri nå diskene, og ytelsen som returneres for IO, er vanligvis begrenset av hastigheten til PCI-bussen. Derfor kan falske ytelsestall på mer enn 3 GB/sek observeres. Opplast alltid hurtigbufferen ved å velge en testfilstørrelse som er større enn den for kontrollerhurtigbufferen.
CacheCadeCacheCade
må benchmarkes på en annen måte enn standard SSD-disker, da denne teknologien bare brukes til å bufre leseforespørsler, ikke skriveforespørsler. En utfordring opprettes derfor når en bruker ønsker å måle en CacheCade-løsning, ettersom standardmetoden for bare å lese eller skrive blokker ikke gir de forventede resultatene med mindre hurtigbufferen er klargjort.
For ytterligere å beskrive denne egenskapen til CacheCade bør du vurdere en situasjon der mekaniske disker bare er lesebufret, og du ønsker å kjøre IOMeter for å bekrefte at CacheCade er i stand til å levere ytelsen som forventes av den. IOMeter vil først opprette en testfil som den skal utføre IO-operasjoner fra. Denne filen skrives til mållagringen. Derfor bufres ikke filen av CacheCade. IOMeter vil da begynne å utføre IO-operasjoner på filen, men som vi allerede forstår, er det ikke i hurtigbufferen, så de første IO-operasjonene vil bli utført på de mekaniske diskene. Denne første hurtigbuffer-missen (der de forespurte dataene ikke er tilgjengelige i hurtigbufferen) påvirker den første delen av ytelsesanalysen negativt, så trinnene må utføres for å eliminere denne ytelsen fra statistikken. CacheCade implementerer også hurtigbufring bare på hurtigpunkter for data, noe som betyr at data må åpnes ofte før de blir bufret. Vi må også takle denne effekten for å måle ytelsen på et praktisk nivå.
For å oppnå forventningene våre må vi sørge for at testfilen er tilgjengelig nok til at den bufres. Hvis du vil gjøre dette, lar du IOMeter kjøre en lesetest over lengre tid. Husk at størrelsen på testfilen og hastigheten til I/O-operasjonene i MD/sek vil bestemme hvor lang tid det tar før filen bufres. Filen må leses flere ganger før den blir bufret, slik at du kan forsøke å lese filen tilsvarende fem ganger ved at filen får tilgang til størrelsen på filen med hastigheten i MB/sek * 5.
For eksempel en testfil på 4 GB som leses ved 40 MB/sek = 100 sekunder * 5 = 500 sekunder.
I dette eksemplet må du la en READ-test kjøre i minst 8,5 minutter for at tilsvarende fem leseoperasjoner skal utføres over hele filen. Denne gangen kalles "oppvarmingstiden" for hurtigbufferen.
Når du har fullført mer enn 8,5 minutter med oppvarming, avslutter du ytelsestesten. Dette lar IOMeters testmålfil fortsatt bufres, ettersom det ikke vil være noen prosess for å tømme dataene fra CacheCade, ettersom filen beholdes etter at applikasjonen er lukket. Start deretter samme ytelsesapplikasjon på nytt, og velg de samme målstasjonene. Når IOMeter nå begynner å lese fra filen, vil dataene allerede være i hurtigbuffer (et hurtigbuffer-treff), og ytelsen skal ligne på CacheCade i en optimalisert tilstand.
Nøkkelpunkter:
Når du kjører andre verktøy for ytelsesmåling, er det noen konfigurasjonsanbefalinger som bør følges.
For SSD og CacheCade: