Hoe beïnvloeden wachtrijdiepte en blokgrootte de willekeurige leestijd op een thuis-NAS?

Wachtrijdiepte en blokgrootte veranderen de latentie van willekeurige leesopdrachten omdat ze bepalen hoeveel werk tegelijk wordt ingediend en hoeveel data elke bewerking overdraagt. Een test met lage wachtrij en kleine blokken meet hoe snel één aanvraag wordt voltooid, terwijl een test met hoge wachtrij meet hoeveel parallel werk het opslagpad kan volhouden.

Dezelfde NAS kan dus bescheiden 4K QD1 IOPS tonen, veel hogere 4K QD32 IOPS en sterke doorvoer met grote blokken zonder tegenstrijdigheid. Elk resultaat beschrijft een andere werklast, en het snelste benchmarkcijfer is mogelijk het minst representatief voor een interactieve database, fotobibliotheek of containerapp.

Wat regelen wachtrijdiepte en blokgrootte eigenlijk?

Wachtrijdiepte is het aantal I/O-bewerkingen dat openstaat op een gemeten laag. wachtrijdiepte regelt het aantal openstaande I/O-aanvragen, terwijl blokgrootte de hoeveelheid gegevens bepaalt die per aanvraag wordt overgedragen.

Een test met QD1 dient één bewerking in en wacht op voltooiing voordat de volgende wordt gestart. Een QD32-test staat veel bewerkingen toe die wachten of parallel worden uitgevoerd, waardoor de schijf, controller, array en het netwerk meer mogelijkheden krijgen om werk te overlappen.

Deze waarden bestaan op verschillende lagen. De benchmark-threadwachtrij, de blokwachtrij van het besturingssysteem, HBA, NVMe-submissiewachtrij, NAS-protocolcredits en individuele schijven kunnen allemaal verschillende aantallen openstaande aanvragen zien.

Waarom onthult QD1 de servicetijd van opslag?

Met één openstaande aanvraag kan de volgende bewerking zich niet verbergen achter parallel werk, dus onthult QD1 de servicetijd van een enkele aanvraag. Het resultaat omvat de servicetijd van het apparaat plus protocol-, bestandssysteem-, controller-, netwerk- en client-overhead.

QD1 is daarom nuttig voor taken die één of enkele afhankelijke leesopdrachten uitvoeren: metadata openen, een databasepagina laden, een miniatuur lezen of een verwijzing naar de volgende structuur volgen.

Het is geen volledige capaciteitsmeting. Een moderne SSD of gestreepte array kan veel meer parallel werk aan dan QD1 levert, dus het resultaat kan de maximale totale IOPS onderschatten terwijl het wel de reactietijd van een enkele aanvraag nauwkeurig weergeeft.

Waarom kunnen een hogere wachtrijdiepte IOPS en latentie tegelijk verhogen?

Meer uitstaand werk kan opslagkanalen bezet houden en het aantal voltooide bewerkingen per seconde verhogen, maar hogere wachtrijdiepte kan IOPS en latentie samen verhogen. Elk verzoek kan langer wachten voordat het wordt bediend.

De benchmark rapporteert meer totale voltooiingen omdat het systeem werk overlapt, niet omdat elk verzoek sneller werd. Zodra het apparaat of de array zijn servicecapaciteit bereikt, verlengt extra wachtrijdiepte meestal de wachtrij.

Dit is waarom hoge QD-IOPS en lage interactieve latentie aparte doelen zijn. Een back-upserver of analysejob kan profiteren van diepe paralleliteit, terwijl een app-verzoek geeft om de voltooiingstijd van één kritieke leesbewerking.

Hoe verandert blokgrootte IOPS, doorvoer en wachttijd?

IOPS telt bewerkingen zonder te beschrijven hoeveel bytes elke bewerking verplaatst. blokgrootte verandert de balans tussen IOPS en doorvoer. Duizend 4K-leesbewerkingen verplaatsen veel minder data dan duizend 128K-leesbewerkingen.

Kleine blokken benadrukken overhead per bewerking en zijn gebruikelijk voor databasepagina's, metadata en applicatiestatus. Grotere blokken verbeteren de overdrachtsefficiëntie en doorvoer, maar bezetten het apparaat, netwerk en de controller voor meer bytes per verzoek.

Een grotere blok kan het aantal IOPS verminderen dat nodig is voor een bepaalde bandbreedte, terwijl de servicetijd van elke bewerking toeneemt. Gemengde toepassingen hebben beide dimensies nodig omdat een NAS kleine metadata-leesbewerkingen kan bedienen naast grote media- of back-upoverdrachten.

Waarom laten cache en parallelisme resultaten beter lijken dan apps aanvoelen?

Benchmarkresultaten kunnen worden gedomineerd door RAM, controllercache, clientcache of herhaalde toegang tot een kleine werkset. cache en gelijktijdigheid kunnen koude-leeslatentie verbergen.

Parallelle benchmark-werkers kunnen ook verzoeken effectiever verdelen over schijven, NAND-kanalen, CPU-kernen, SMB-kanalen of NVMe-wachtrijen dan één applicatiedraad. De test bewijst totale schaalvergroting, niet dat één koude app-leesbewerking hetzelfde voordeel krijgt.

Gebruik een dataset die groter is dan de relevante caches bij het testen van opslagmedia, en voer aparte warm-cache tests uit wanneer applicatiecaching deel uitmaakt van het echte ontwerp. Het mengen van de twee levert een cijfer op waarvan de bottleneck onduidelijk is.

Hoe moet een random-read test voor een thuis-NAS aansluiten bij echte werklasten?

Een nuttige benchmark varieert de dimensies die echte applicaties variëren. realistische tests moeten aansluiten bij de werklast-wachtrijdiepte in plaats van één maximale IOPS-waarde te rapporteren.

Test QD1 en een paar matige dieptes, gebruik 4K of 8K kleine reads en de grotere blokken die door media- of back-uptools worden gebruikt, en registreer gemiddelde plus p95, p99 en maximale latentie. Houd client, protocol, encryptie en dataset constant bij het vergelijken van opslagwijzigingen.

Voer de random-read test zowel alleen als naast de achtergrondwerkzaamheden uit die de NAS daadwerkelijk delen. Een geïsoleerde benchmark kan het opslagpad schoon meten, maar kan niet de latentie onthullen die gebruikers ervaren tijdens app-, backup-, indexerings- of pariteitsconcurrentie.

FAQ

Is een hogere wachtrijdiepte altijd beter?

Nee. Het kan de totale doorvoer verbeteren totdat het opslagpad verzadigd is, maar verzoeken kunnen langer wachten en interactieve latentie kan verslechteren.

Waarom worden 4K random-read cijfers vaak gerapporteerd?

Kleine blokken lijken op databasepagina’s, metadata en applicatiestatus, en ze tonen overhead per bewerking die grote sequentiële overdrachten verbergen.

Moet een NAS benchmark QD32 gebruiken?

Alleen wanneer de verwachte werklast zoveel parallelle I/O kan creëren. Gebruik QD1 en matige dieptes voor interactieve thuisserver-apps.

Kan netwerkvertraging een random-read test domineren?

Ja. SMB- of NFS-ronde reizen, clientverwerking, encryptie en switchwachtrijen kunnen de servicetijd van het apparaat overschrijden, vooral bij lage wachtrijdiepte.

Laatste conclusie

De wachtrijdiepte bepaalt hoeveel I/O kan wachten of parallel kan worden uitgevoerd, terwijl de blokgrootte bepaalt hoeveel data elke bewerking verplaatst. Een hogere wachtrijdiepte kan de totale IOPS verhogen terwijl de latentie per verzoek toeneemt, en grotere blokken kunnen de doorvoer verbeteren terwijl het aantal bewerkingen afneemt. Een nuttige thuis-NAS benchmark sluit aan bij echte gelijktijdigheid, datagroottes, cachestatus en tail-latency vereisten in plaats van het kiezen van het grootste kopcijfer.