| Obs! |
| CacheCade-funktionen är tillgänglig från det första halvåret 2011. |
| Obs! |
| För att kunna använda CacheCade för den virtuella disken måste skriv- och läsprincipen för den virtuella HDD-baserade disken vara inställd på Write Back eller Force Write Back och läsprincipen måste vara inställd på Read Ahead eller Adaptive Read Ahead. |
Relaterade artiklar och informationsdokument:
Mätning av prestandaanvändare
kanske inte förstår de bästa metoderna för att testa SSD- och CacheCade-enheter™ så att de kan se fördelarna med SSD-lagring. Den här artikeln försöker ge vägledning om de optimala prestandaspecifikationerna som kan tillämpas allmänt på de flesta av verktygen för prestandatestning.
Användningen av verktyg för prestandatestning för att uppnå optimal prestanda är naturligtvis beroende av användarens förståelse av hur enheten som testas ska fungera.
Blockstorlek: SSD- och CacheCade-enheter fungerar optimalt när de används med små blockstorlekar snarare än stora block. När IO läses eller skrivs är processen för att välja den aktiva cellen elektronisk och är inte beroende av en fysisk huvudrörelse som med mekaniska diskar. Det innebär att SSD-enheter kan reagera mycket snabbt på slumpmässig IO i små block och uppnå mer än 10 000 IOPS där en mekanisk disk skulle ha problem med att uppnå större än 200 IOPS.
Ködjup: SSD-diskar har ett djupt ködjup, med de mest kapabla 64 utestående IO:er, betydligt mer än en vanlig SAS-disk, vanligtvis vid 16 enastående IO. Det här djupa ködjupet ger disken mycket större flexibilitet eftersom det minskar diskens beroende av styrenheten för att ge IO:er i tid. Styrenheten kan upprätthålla kön när den kan, vilket gör att disken kan arbeta sig igenom den utan att behöva vänta på styrenheten.
När tekniken förändras och SSD:er utför fler uppgifter parallellt kommer diskködjupet sannolikt att fördjupas igen. Verktyget för prestandatestning måste användas för att söka efter det mest effektiva ködjupet, så om du ökar ködjupet från tid till annan kan det resultera i bättre siffror med olika enheter.
Cachebunden: Det är viktigt att prestandaverktyget inte är cachebundet, eftersom alla IO servas av styrenhetens cacheminne. Detta inträffar när testfilsstorleken anges felaktigt och kan passa in helt i styrenhetens cacheminne. När detta inträffar når IO-enheterna aldrig diskarna och prestandan som returneras för IO begränsas vanligtvis av HASTIGHETEN på PCI-bussen, vilket innebär att falska prestandatal på mer än 3 GB/s kan observeras. Spara alltid cacheminnet genom att välja en testfilsstorlek som är större än styrenhetens cacheminne.
CacheCadeCacheCade
måste prestandatestas annorlunda än vanliga SSD-diskar eftersom den här tekniken endast används för läsbegäranden i cacheminnet och inte för skrivbegäran. En utmaning skapas därför när en användare vill prestandatesta en CacheCade-lösning eftersom standardmetoden för att bara läsa eller skriva block inte ger förväntade resultat om inte cacheminnet förbereds.
För att ytterligare beskriva denna egenskap hos CacheCade bör du överväga en situation där mekaniska diskar endast är läscachelagrade och du vill köra IOMeter för att validera att CacheCade kan tillhandahålla den prestanda som förväntas av den. IOMeter skapar först en testfil från vilken den utför sina IO-åtgärder. Den här filen skrivs till mållagringen och därför cachelagras den inte av CacheCade. IOMeter kommer då att börja utföra sina IO-åtgärder på filen, men som vi redan förstår det för närvarande inte finns i cacheminnet, så de första IO-åtgärderna utförs på de mekaniska diskarna. Den första cachemissen (där begärda data inte finns i cacheminnet) påverkar den första delen av prestandaanalysen negativt. Därför måste åtgärder utföras för att eliminera prestandaproblemet från statistiken. CacheCade implementerar även cachelagring endast på aktiva datafläckar, vilket innebär att data måste nås ofta innan de cachelagrar. Vi måste också övervinna den här effekten för att mäta prestanda på en praktisk nivå.
För att uppnå våra förväntningar måste vi se till att testfilen har åtkomst tillräckligt för att den ska cachelageras. Det gör du genom att låta IOMeter köra ett lästest under en längre tid. Tänk på att storleken på testfilen och hastigheten för IO-åtgärderna i MD/s avgör hur lång tid det tar för filen att cachelagrads. Filen måste läsas FLERA gånger innan den cachelagras, så du kan sträva efter att läsa filen motsvarande 5 gånger genom att avskilja storleken på filen med hastigheten i MB/s * 5.
Till exempel en testfil på 4 GB som läse vid 40 MB/s = 100 sekunder * 5 = 500 sekunder.
I det här exemplet behöver du lämna ett READ-test igång i minst 8,5 minuter för att motsvarande fem läsåtgärder ska utföras över hela filen. Den här gången kallas det "warm-up time" för cacheminnet.
När du har slutfört mer än 8,5 minuters varmhett avslutar du prestandatestet. Detta lämnar IOMeters testmålfil fortfarande cachelagrad eftersom det inte kommer att finnas någon process för att rensa data från CacheCade eftersom filen behålls efter att programmet har stängts. Starta sedan om samma prestandaprogram och välj samma målenheter. När IOMeter nu börjar läsa från filen kommer data redan att finnas i cacheminnet (ett cacheproblem) och prestandan bör likna CacheCade i ett optimerat läge.
Viktiga punkter:
När du kör andra prestandamätningsverktyg finns det några konfigurationsrekommendationer som bör följas.
För SSD och CacheCade: