Live Optics | Optisk Prime | Ködjup: En djupare titt

Diskkö anses ofta vara den första indikatorn på dålig programprestanda, men den skylls ofta för tidigt. Följande förklaring är en snabb och smutsig guide för att förstå några grundläggande metoder för att avmystifiera Disk Que.

Låt oss dela upp detta i två delar. Den grundläggande överlevnadsguiden för dig som inte har tid att läsa vidare och en mer djupgående förståelse för varför Disk Queue fick vara en fokuspunkt i första hand. 

Överlevnadsguiden:

AN Optical Prime-projekt visar antalet utestående IO:er ur operativsystemets perspektiv för varje sampling under hela inspelningsperioden. Om diskkö är problemet bör det vara nära associerat med svarstid under samma period. Så, från bra till sämre:

- Låg diskkö och låg latens = En sannolikt lycklig applikations- och användarupplevelse

- Hög diskkö och låg latens = Om latensen förblir önskvärd bör detta vara OK.

- Låg diskkö och hög latens = Behöver åtgärdas, men det är osannolikt att det är din lagring.

- Hög disk och hög latens = Bör se på din lagring som en potentiell flaskhals.

Det sistnämnda bör undersökas och det är här som värdet av Optical Prime som representerar prestanda över tid är viktigt. Om diskkön orsakar svarstiden bör man se nära korrelerade mönster mellan de två värdena.  

Här är en post som visar ett exempel på en bra korrelation mellan svarstid och diskkö.

För att förstå grunderna i diskkölängd kan du tänka på en kassakö på din lokala "Food-Mart". Alla vet hur det går till... Du väljer dina varor, du ställer dig i kö för att bli utcheckad, när det är din tur betalar du och slutligen äger du varan.

Alla har också varit där på semestern eller sent på kvällen när kön är lång och den stackars kassörskan har en kö av upprörda människor som säger: "Varför öppnar inte ledningen bara upp fler utcheckningsbanor?"

På en grundläggande definitionsnivå är diskkö antalet utestående diskåtgärder som "väntar i kö" och därmed anledningen till att den ofta ses som ett tecken på lagringsproblem.

Vi vet alla att om man lägger till fler kassörer på Food-Mart skulle det få linjen att gå snabbare och det gör det för att vi har ökat vår grad av parallellt arbete. Samma grundläggande principer kan tillämpas på I/O-begäranden. Om jag bara hade en disk i min server som försökte göra allt det arbetet eller till och med, låt oss säga, en liten RAID 5 som försökte göra det arbetet. Då kan vi tänka oss att programmet genererar en arbetsbelastningsefterfrågan där utcheckningsraden för I/O säkerhetskopieras. Detta höga diskköfenomen kallas att vara "spindelbunden". Enkelt uttryckt kan diskarna inte hålla jämna steg med efterfrågan, så en linje bildas och det manifesterar sig som latens till operativsystemet.

Den grundläggande riktlinjen är att en diskkö på mer än 2-4 är dålig.

Enkelt, eller hur? Tja, det blir mer komplicerat tyvärr.

Regeln är att en diskkö på mer än 2-4 per disk är dålig... anledningen till att det blir svårt är att Optical Prime inte berättar hur många skivor som utgör att "F: Kör."

Verkar trivialt nog, varför tar vi inte tag i antalet diskar och kallar det en dag? Det kan vi inte alltid göra. Vissa enheter är i själva verket partitioner och en E:- och F:-enhet kan finnas på samma disk. En bättre mask av sanningen kommer från själva lagringsmatriserna.

Alla externa disksystem som representerar en volym eller ett LUN för ett operativsystem kan maskera ett obegränsat antal enheter från operativsystemet. Ett disksystem kan till exempel ha en RAID-grupp på 4 eller 9 diskar som utgör det LUN som representeras av Windows som "F: Kör"... så om vi har en diskkö på 15 är det dåligt ... eller är det OK?

Applikationsstörningar
Vissa program kan hantera diskkön eller svara på den. Ett hanteringsteknikprogram som SQL Server kan begränsa I/O så att det inte skapas för många utestående I/O:er. Om de ser att diskkön klättrar kan det maskera problemet genom att inte låta det gå överstyr.

Datamönster
Tillbaka vid utcheckningsdisken på Food-Mart... När chefen äntligen vaknar och öppnar tre nya utcheckningsbanor kan personerna fläkta ut och gå igenom köerna eftersom deras inköp inte är relaterade. De är som Random I/O. Varje person går igenom kön oberoende av någon annan. Slumpmässig I/O är samma sak. Varje operation vill bli klar så snabbt som möjligt och bryr sig egentligen inte om någon annan.

Sekventiella data är motsatsen och kan ses mer som en film. En film är en serie stillbildsbilder som spelas upp "i följd" för att ge dig effekten av en film. För att filmen ska vara meningsfull måste dessa bildrutor spelas upp i ordning och är beroende av den ordningen för att filmen ska vara meningsfull. (minus eventuella Quentin Tarantino-filmer förstås)

Ofta kan sekventiell I/O inte delas upp i parallell aktivitet. Beroende på vilken typ av program som kör den sekventiella arbetsbelastningen kanske du ser en ökad mängd diskkö och latens, men du kan se en liknande korrelation som sträcker sig till I/O-överföringsstorleken. Om du vill veta mer om detta kan du läsa inlägget om hur I/O-överföringsstorlek kan påverka latensen.

Sammanfattning
Idag, med SSD-diskar och virtualiserad lagring, är risken för att diskar är flaskhalsen inte densamma som den var när 15 K RPM-hårddiskar var den högsta nivån. Icke desto mindre är det något som är värt att undersöka varje gång du jagar ett latensproblem.  

Det är nästan enklare att utesluta att disken orsakar latensen än att hitta orsaken till latensen. Men du kan åtminstone ha ett ställe mindre att titta :).

Om du har frågor kan du kontakta Live Optics-supporten på liveoptics.support@dell.com.