Live Optics | Optisk Prime | Kødybde: Et dypere blikk

Diskkø blir ofte tenkt på den første indikatoren for dårlig applikasjonsytelse, men det får ofte skylden for tidlig. Følgende forklaring er en rask og skitten guide til å forstå noen grunnleggende tilnærminger til å avmystifisere Disk Que.

La oss dele dette opp i to deler. Den grunnleggende hit and run-overlevelsesguiden for de av dere som ikke har tid til å lese videre og en mer grundig forståelse av hvorfor Disk Queue fikk være et fokuspunkt i utgangspunktet. 

Overlevelsesguiden:

AN Optical Prime-prosjektet viser antall utestående I/O-er fra operativsystemets perspektiv for hver prøve gjennom innspillingsperioden. Hvis Disk Queue er problemet, bør det være tett forbundet med ventetid i samme periode. Så fra godt til vondt:

- Lav diskkø og lav ventetid = En sannsynlig lykkelig applikasjon og brukeropplevelse

- Høy diskkø og lav ventetid = Hvis ventetid forblir ønskelig, bør dette være OK.

- Lav diskkø og høy latens = Trenger oppmerksomhet, men det er usannsynlig at det er din lagring.

- Høy disk og høy latens = Bør se på lagringen din som en potensiell flaskehals.

Dette siste bør undersøkes, og det er her verdien av Optical Prime som representerer ytelse over tid er viktig. Hvis Disk Queue forårsaker ventetiden, bør man se tett korrelerte mønstre mellom de to verdiene.  

Her er en oppføring som viser et eksempel på en god korrelasjon mellom ventetid og diskkø.

For å forstå det grunnleggende om diskkølengde, tenk på en utsjekkingslinje på din lokale "Food-Mart." Alle kjenner drillen ... Du velger varene dine, du kommer i kø for å bli sjekket ut, når det er din tur du betaler, og til slutt eier du varen.

Alle har også vært der på ferie eller sent på kvelden når køen er lang og den stakkars kasseekspeditøren har en kø av opprørte folk som sier: "Hvorfor åpner ikke ledelsen bare flere utsjekkingsbaner!"

På et grunnleggende definisjonsnivå er Disk Queue antall utestående diskoperasjoner som "venter i kø" og dermed grunnen til at det ofte blir sett på for å indikere lagringsproblemer.

Vi vet alle at å legge til flere utsjekkingsfunksjonærer på Food-Mart ville gjøre linjen fan-out og gå raskere, og det gjør det fordi vi økte vår grad av parallelt arbeid. De samme grunnleggende prinsippene kan brukes på I/O-forespørsler. Hvis jeg bare hadde én disk på serveren min som prøvde å gjøre alt det arbeidet, eller til og med, la oss si, et lite RAID 5 som prøvde å gjøre det arbeidet. Da kunne vi tenke oss at applikasjonen ville generere et arbeidsbelastningsbehov der utsjekkingslinjen for I / Os ville bli sikkerhetskopiert. Dette fenomenet med høy diskkø kalles spindelbundet. Enkelt sagt, diskene kan ikke holde tritt med etterspørselen, så en linje dannes, og det manifesterer seg som ventetid til operativsystemet.

Den grunnleggende retningslinjen er at en diskkø på mer enn 2-4 er dårlig.

Enkelt, ikke sant? Vel, det blir mer komplisert dessverre.

Regelen er at en diskkø på mer enn 2-4 per disk er dårlig ... grunnen til at det blir vanskelig er at Optical Prime ikke forteller deg hvor mange disker utgjør at "F: Kjør.»

Virker trivielt nok, hvorfor tar vi ikke tak i antall disker og kaller det en dag? Vel, vi kan ikke alltid gjøre det. Noen stasjoner er egentlig partisjoner, og en E: og F: stasjon kan være på samme disk. En bedre maske av sannheten kommer fra selve lagringsarrayene.

En ekstern diskrekke som representerer et volum eller en LUN til et operativsystem, kan maskere et hvilket som helst antall stasjoner fra operativsystemet. En matrise kan for eksempel ha en RAID-gruppe på 4 eller 9 disker som utgjør LUN-en som representeres for Windows-operativsystemet som "F: Kjør"... så hvis vi har en diskkø på 15 er det dårlig ... eller er det greit?

Applikasjonsforstyrrelser
Noen programmer kan administrere diskkøen eller reagere på den. En administrasjonsteknikkapplikasjon som SQL Server kan strupe tilbake I / O for ikke å skape for mange utestående IOer. Hvis de ser at diskkøen klatrer, kan den maskere problemet ved ikke å la det komme ut av kontroll.

Datamønstre
Tilbake ved kassen på Food-Mart ... Når lederen endelig våkner opp og åpner tre nye utsjekkingsbaner, kan folk fan-out og gå gjennom linjene fordi kjøpene deres ikke er relaterte. De er som tilfeldige I / O. Hver person går gjennom linjen uavhengig av noen andre. Tilfeldig I/O er det samme. Hver operasjon ønsker å fullføre så raskt som mulig og bryr seg egentlig ikke om noen andre.

Sekvensielle data er det motsatte og kan betraktes mer som en film. En film er en serie stillbilder som spilles "i rekkefølge" for å gi deg effekten av en film. For at filmen skal gi mening, må disse rammene spilles i rekkefølge og er avhengig av den rekkefølgen for at filmen skal gi mening. (minus noen Quentin Tarantino-filmer selvfølgelig)

Ofte kan ikke sekvensiell I/O brytes inn i parallell aktivitet. Avhengig av typen program som kjører den sekvensielle arbeidsbelastningen, kan det hende at du ser en økt mengde diskkø og ventetid, men du kan se en lignende korrelasjon som strekker seg til I/O-overføringsstørrelsen. For å lære mer om dette, les innlegget om hvordan I / O-overføringsstørrelse kan påvirke ventetiden.

Sammendrag
I dag, med SSD-er og virtualisert lagring, er sjansene for at disker er flaskehalsen ikke som de var da 15 K RPM-stasjoner var det høyeste nivået. Ikke desto mindre er det noe som er verdt å se nærmere på hver gang du jakter på et latensproblem.  

Det er nesten lettere å utelukke at disken forårsaker ventetiden enn å finne årsaken til ventetiden. Men i det minste kan du ha ett sted mindre å lete :).

Hvis du har spørsmål, kan du kontakte kundestøtte for Live Optics på liveoptics.support@dell.com.