Un test de stocare util potrivește dimensiunea operației, modelul de acces, concurența și cerințele de durabilitate cu aplicația. Înregistrați condițiile testului și distribuția latenței, apoi confirmați rezultatul cu măsurători ale aplicației.
Începeți cu o întrebare despre stocare, nu cu un scor
Decideți ce trebuie să știți înainte de a rula un benchmark. Este posibil să investigați commit-uri lente ale bazei de date, debitul de distribuire a fișierelor sau un proces de build care creează multe fișiere mici. Aceste volume de lucru nu cer discului să facă același lucru. O copiere secvențială mare poate părea impresionantă, dar spune puțin despre întârzierea resimțită de un serviciu care face citiri mici aleatorii.
NVMe a fost proiectat pentru medii non-volatile și I/O paralel eficient, dar numele protocolului său nu descrie fiecare parte a unei căi de stocare găzduite. Virtualizarea, sistemul de fișiere, contenția resurselor și aplicația contează în continuare. Scrieți o ipoteză de test, cum ar fi dacă latența stocării încetinește o anumită operație, în loc să încercați să produceți un număr care dovedește că întregul server este rapid.
Descrieți volumul de lucru în termeni reproductibili
Înregistrați dimensiunea operației, modelul secvențial sau aleatoriu, raportul citire-scriere, numărul de joburi și adâncimea cozii. Includeți dimensiunea setului de date și durata testului. Documentația fio explică aceste controale ale volumului de lucru și motoarele de I/O disponibile. O adâncime intenționată poate să nu fie atinsă de fiecare motor sau configurație, așa că citiți comportamentul raportat, precum și configurația pe care ați solicitat-o.
Păstrați o copie a descrierii testului lângă rezultat. Notați sistemul de operare, sistemul de fișiere, opțiunile de montare, activitatea serviciilor și capacitatea disponibilă. Dacă comparați configurații, schimbați o singură condiție relevantă pe rând. Un test cu un model de acces sau o concurență diferită nu poate fi prezentat în mod corect ca și cum s-ar fi schimbat doar mediul de stocare.
| Modelul aplicației | Dimensiunea testului de descris | Rezultatul de examinat |
|---|---|---|
| Livrarea fișierelor mari | Citiri secvențiale și clienți concurenți | Debit susținut și utilizarea CPU |
| Căutare în înregistrări | Citiri mici aleatorii și concurență reprezentativă | Distribuția latenței și operațiile finalizate |
| Tranzacție durabilă | Cerințe de scriere și sincronizare | Întârziere legată de commit, nu doar viteza de scriere în buffer |
| Build sau extragere | Operații mixte cu fișiere mici | Durata jobului end-to-end și așteptările I/O |
Controlați cache-ul fără a pretinde că nu contează
Un set de date care încape în memorie poate măsura în mare parte comportamentul cache-ului după prima trecere. Acest lucru poate fi util dacă aplicația beneficiază în mod normal de același cache, dar nu ar trebui etichetat ca performanță brută a dispozitivului. Alegeți în mod deliberat dacă testul examinează o cale de aplicație caldă, un set de date mai rece sau un mod I/O destinat să reducă efectul de tamponare al sistemului de operare.
Suportul și alinierea I/O direct depind de platformă și de motor. De asemenea, nu exprimă automat cerințele de durabilitate ale aplicației și nu elimină fiecare cache din stivă. Declarați clar modul ales și evitați compararea unui test cu buffer cu un test fără buffer ca și cum ar reprezenta aceeași muncă. Păstrați intervalele de încălzire și cele măsurate separate acolo unde acest lucru ajută la interpretare.
Citiți cozile de latență alături de debit
Latența medie poate ascunde operații lente care afectează cererile reale. Examinați percentilele raportate și numărul de eșantioane din spatele lor. O percentilă ridicată descrie limita sub care a căzut o fracțiune declarată din operațiile observate în timpul acelui test; nu este o garanție permanentă de serviciu. Rulările scurte sau nereprezentative oferă dovezi limitate despre perioadele de producție aglomerate.
O adâncime mai mare a cozii poate îmbunătăți debitul finalizat, crescând în același timp timpul de așteptare. Acest compromis poate fi potrivit pentru procesarea în lot și poate dăuna unui serviciu interactiv. Comparați rezultatele la o concurență care seamănă cu aplicația și monitorizați CPU și presiunea I/O în același timp. Opriți-vă înainte ca testul să creeze perturbări inutile pentru un alt volum de lucru care partajează mediul.
Păstrați testul autorizat și nedistructiv
Folosiți un director de test dedicat sau un volum de unică folosință pregătit, cu suficient spațiu liber și un plan explicit de curățare. Nu îndreptați niciodată un benchmark de scriere către un dispozitiv brut neverificat sau un set de date de producție. Verificați ținta și comportamentul de scriere al instrumentului înainte de a începe și începeți cu o rulare limitată. I/O sintetic poate consuma capacitate și poate interfera cu serviciile chiar și atunci când nu suprascrie fișiere utile.
Pentru o evaluare asemănătoare producției, conveniți o fereastră de mentenanță și păstrați monitorizarea aplicației. Folosiți date fabricate atunci când este posibil. Nu deduceți fiabilitatea stocării dintr-un test de viteză: verificările de integritate, backup-urile și restaurarea sunt sarcini separate. Un dispozitiv care finalizează un benchmark are totuși nevoie de o strategie de recuperare pentru ștergere, greșeli software sau pierderea mașinii.
Închideți bucla cu dovezi din aplicație
Să presupunem că un serviciu de raportare petrece mult timp așteptând citiri aleatorii. Echipa testează un model de citire reprezentativ, apoi repetă raportul real pe date comparabile. Dacă raportul se îmbunătățește în timp ce restul activității sale rămâne stabil, rezultatul susține ipoteza stocării. Dacă nu, investigați proiectarea interogărilor, memoria sau o altă dependență, în loc să repetați teste sintetice mai largi.
Pulse NVMe și configurațiile dedicate selectate listează stocarea NVMe în catalogul SwissOctet. Etichetele lor sunt specificații, nu benchmark-uri publicate de aplicații. Folosiți o metodă controlată pentru a evalua mediul livrat și păstrați condițiile împreună cu constatările. Decizia devine mai puternică atunci când măsurarea stocării și rezultatul vizibil pentru utilizator răspund la aceeași întrebare.
Lista dumneavoastră practică de verificare.
- Definiți mai întâi întrebarea aplicației.
- Înregistrați modelul, dimensiunea blocului, concurența și durata.
- Declarați ipotezele privind cache-ul și modul I/O.
- Inspectați percentilele de latență, precum și debitul.
- Folosiți o țintă de unică folosință verificată și o încărcare inițială limitată.
- Confirmați constatarea cu un test al aplicației.
Detaliile care contează.
Este suficientă o copiere secvențială pentru a compara stocarea bazelor de date?+
De obicei nu. Accesul la baza de date poate implica citiri mici aleatorii, scrieri și sincronizare. Modelați modelul relevant și verificați aplicația reală.
Dovedește I/O direct scrierile durabile?+
Nu. Tamponarea și durabilitatea sunt aspecte separate. Potriviți comportamentul de sincronizare cerut de aplicație.
Pot publica un test ca viteză garantată a planului?+
Nu. Publicați condițiile și domeniul său de aplicare. Un rezultat măsurat dintr-o singură rulare nu este o garanție de nivel de serviciu sau de performanță viitoare.
Mergeți la sursă.
Aceste referințe susțin conceptele tehnice din acest ghid. Urmați documentația actuală înainte de a modifica un sistem de producție.
- fio: Documentația testerului I/O flexibil fio.readthedocs.io
- NVM Express: Prezentare generală a specificației și întrebări frecvente nvmexpress.org
- Nucleul Linux: Pressure Stall Information docs.kernel.org
Îndrumare editorială de SwissOctet. Exemplele sunt ilustrative. Specificațiile serviciilor, opțiunile disponibile și condițiile contractuale trebuie verificate separat.