Live-optik | Optisk Prime | Kødybde: Et dybere kig

Diskkø betragtes ofte som den første indikator for dårlig applikationsydelse, men det får ofte skylden for tidligt. Følgende forklaring er en hurtig og beskidt guide til forståelse af nogle grundlæggende tilgange til afmystificering af Disk Que.

Lad os opdele dette i to dele. Den grundlæggende hit and run overlevelsesguide til dem af jer, der ikke har tid til at læse videre og en mere dybdegående forståelse af, hvorfor Diskkø blev et fokuspunkt i første omgang. 

Overlevelsesguiden:

AN Optical Prime-projektet viser antallet af udestående IO'er fra OS's perspektiv for hver prøve i hele optagelsesperioden. Hvis Diskkø er problemet, skal det være tæt forbundet med ventetid i samme periode. Så fra godt til værre:

- Lav diskkø og lav latenstid = En sandsynlig glad applikations- og brugeroplevelse

- Høj diskkø og lav latenstid = Hvis latenstid forbliver ønskelig, bør dette være OK.

- Lav diskkø og høj latenstid = Har brug for opmærksomhed, men det er usandsynligt, at det er din lagerplads.

- Høj disk og høj latenstid = Skal se på din opbevaring som en potentiel flaskehals.

Denne sidste bør undersøges, og her er hvor værdien af Optical Prime, der repræsenterer ydeevne over tid, er vigtig. Hvis Diskkø forårsager latenstid, skal man se tæt korrelerede mønstre mellem de to værdier.  

Her er en post, der viser et eksempel på en god sammenhæng mellem latenstid og diskkø.

For at forstå det grundlæggende i Diskkølængde tænk på en check-out linje på din lokale "Food-Mart." Alle kender boret... Du vælger dine varer, du står i kø for at blive tjekket ud, når det er din tur, betaler du, og til sidst ejer du varen.

Alle har også været der på ferie eller sent om aftenen, når linjen er lang, og den dårlige check-out kontorist har en kø af forstyrrede mennesker, der siger: "Hvorfor åbner ledelsen ikke bare flere check-out baner!"

På et grundlæggende definitionsniveau er Diskkø antallet af udestående diskoperationer, der "venter i kø" og dermed grunden til, at det ofte ses på for at indikere lagerproblemer.

Vi ved alle, at tilføjelse af flere check-out ekspedienter på Food-Mart ville gøre linjen fan-out og gå hurtigere, og det gør det, fordi vi øgede vores grad af parallelt arbejde. De samme grundlæggende principper kan anvendes på IO-anmodninger. Hvis jeg kun havde en disk på min server, der forsøgte at gøre alt det arbejde, eller endda, lad os sige, en lille RAID 5, der forsøgte at gøre det arbejde. Derefter kunne vi forestille os, at applikationen ville generere et workloadbehov, hvor kasselinjen for I/O'er ville blive sikkerhedskopieret. Dette fænomen med høj diskkø kaldes at være "spindelbundet". Almindelige og enkle sæt diskene kan ikke følge med efterspørgslen, så der dannes en linje, og det manifesterer sig som latenstid til operativsystemet.

Den grundlæggende retningslinje er, at en diskkø på mere end 2-4 er dårlig.

Let, ikke? Nå, det bliver desværre mere kompliceret.

Reglen er, at en diskkø på mere end 2-4 pr. disk er dårlig... grunden til, at det bliver svært, er, at Optical Prime ikke fortæller dig, hvor mange diske der udgør det "F: Kør."

Virker trivielt nok, hvorfor griber vi ikke antallet af diske og kalder det en dag? Det kan vi ikke altid gøre. Nogle drev er virkelig partitioner, og et E: og F: drev kan være på samme disk. En bedre maske af sandheden kommer fra lagerarrays selv.

Enhver ekstern diskmatrix, der muligvis repræsenterer en diskenhed eller en LUN til et operativsystem, kan maskere et vilkårligt antal drev fra operativsystemet. Et system kan f.eks. have en RAID-gruppe på 4 eller 9 diske, der udgør den LUN, der er repræsenteret i Windows OS som "F: Kør"... så hvis vi har en diskkø på 15, er det dårligt ... eller er det OK?

Programinterferens
Nogle programmer kan administrere diskkøen eller reagere på den. En administrationsteknikapplikation som SQL Server kan begrænse I / O for ikke at skabe for mange udestående IO'er. Hvis de ser Diskkøen klatre, kan det maskere problemet ved ikke at lade det komme ud af hånden.

Datamønstre
Tilbage ved check-out skranken på Food - Mart. . . Når manageren endelig vågner op og åbner tre nye check-out-baner, kan folk fan-out og gå gennem linjerne, fordi deres køb ikke er relaterede. De er som tilfældige I/O. Hver person går gennem linjen uafhængigt af andre. Tilfældig IO er den samme. Hver operation ønsker at afslutte så hurtigt som muligt og er ligeglad med andre.

Sekventielle data er det modsatte og kan betragtes mere som en film. En film er en serie stillbilleder, der afspilles "i rækkefølge" for at give dig effekten af en film. For at filmen skal give mening, skal disse billeder afspilles i rækkefølge og er afhængige af den rækkefølge, for at filmen giver mening. (minus eventuelle Quentin Tarantino-film selvfølgelig)

Ofte kan sekventiel I/O ikke opdeles i parallel aktivitet. Afhængigt af arten af det program, der kører den sekventielle arbejdsbelastning, kan du muligvis ikke se en øget mængde diskkø og ventetid, men du kan muligvis se en lignende korrelation, der strækker sig til I/O-overførselsstørrelsen. For at lære mere om dette, læs indlægget om, hvordan I / O-overførselsstørrelse kan påvirke latenstid.

Resumé
I dag med SSD'er og virtualiseret lagring er chancerne for, at diske er flaskehalsen, ikke som de var, da 15 K RPM-drev var det højeste niveau. Ikke desto mindre er det noget, der er værd at undersøge, hver gang du jagter et latensproblem.  

Det er næsten lettere at udelukke, at disken forårsager latenstiden end at finde årsagen til latenstiden. Men i det mindste kan du have et sted mindre at se :).

Hvis du har spørgsmål, kan du kontakte Live Optics-support på liveoptics.support@dell.com.