Mi a tárolási tesztelés? Típusok, Concepts & Példa

⚡ Okos összefoglaló

A tárolástesztelés ellenőrzi, hogy egy alkalmazás a megfelelő könyvtárakba írja-e az adatait, és rendelkezik-e elegendő lemezterülettel a váratlan leállások elkerülése érdekében, miközben méri, hogy az alapul szolgáló tároló milyen gyorsan reagál valós terhelés alatt.

  • 💾 Más néven: Tárolási teljesítménytesztelés, mert a sebesség ugyanolyan fontos, mint a helyes elhelyezés.
  • ⚠️ Miért számít: A lassú tárolás lassú válaszidőket, hosszan futó lekérdezéseket és alacsonyabb alkalmazás-rendelkezésre állást eredményez.
  • 🧩 Három típus: Alkalmazástesztelés, alkalmazásszimuláció és benchmarking, mindegyiknek megvannak a saját tevékenységei.
  • 📏 Alapvető mutatók: Az IOPS, a késleltetés, az átviteli sebesség és a várólista mélysége mindig együttesen, nem pedig külön-külön kerül értelmezésre.
  • 🧪 Hogyan működik: Határozza meg a célokat, méretezze az adathalmazt, válasszon reális olvasási/írási keverékeket, majd növelje a terhelést.
  • 🇧🇷 szerszámozás: A szintetikus I/O generátorok olyan ismételhető számokat állítanak elő, amelyeket a fájlmásoló parancsok soha nem tudnak.
  • ???? Gyakori hibák: Rossz szerver monitorozása, kihagyásping gyorsítótár-ürítés és a processzor kihasználtságának figyelmen kívül hagyása.

Tárolási tesztelési útmutató, amely a típusokat, koncepciókat és gyakori hibákat tartalmazza

Mi a tárolási tesztelés?

Tárolási tesztelés egyfajta szoftvertesztelés, amelynek célja annak ellenőrzése, hogy a tesztelt szoftveralkalmazás a megfelelő könyvtárakban tárolja-e a releváns adatokat, és hogy van-e elegendő helye a nem elegendő lemezterület miatti váratlan leállások megelőzésére. Más néven tárolási teljesítménytesztelés.

A technika a tudományág nem funkcionális oldalán helyezkedik el: más formákhoz hasonlóan nem funkcionális tesztelés, semmit sem mond arról, hogy egy funkció a helyes választ adja-e, hanem mindent arról, hogy a rendszer képes-e folyamatosan válaszokat adni az adatmennyiség és az I/O-nyomás növekedésével.

Miért a tárolás tesztelése?

A tárolás a leglassabb réteg, amellyel a legtöbb alkalmazás érintkezik, így egy gyengeség mindenhol máshol is felszínre kerül. Négy ok indokolja a dedikált tesztciklus létrehozását.

  • A lassú tárolás lassú válaszidőket, hosszan futó lekérdezéseket és alacsonyabb alkalmazás-rendelkezésre állást jelent.
  • A lassú tárolás a szerver infrastruktúra karbantartásának többletterhelését jelenti.
  • Segít a rendszer gyakorlati tárhelykorlátainak meghatározásában a telepítés előtt.
  • Segít megérteni, hogyan reagál a rendszer, amikor egy hardvereszközt kicserélnek vagy frissítenek.

Az alábbi ábra a tárolási tesztelést ebbe a kontextusba helyezi – az alkalmazás, a fájlrendszer és a fizikai eszköz ugyanazon az útvonalon található, és a felhasználóhoz bárhol késés éri el.

Tárolástesztelés áttekintése, amely bemutatja, hogyan ír adatokat egy alkalmazás a fájlrendszeren keresztül a tárolóeszközre

A tárolási tesztelés típusai

Három megközelítést alkalmaznak, és ezek főként abban különböznek, hogy a munkaterhelés mennyire hasonlít a valós alkalmazáshoz.

  • Alkalmazás tesztelése: Alkalmazástesztelés minta lekérdezésekkel éles környezetben.
  • Alkalmazás szimuláció: A tesztelés elvégzése szabványos szoftverrel, amely hasonlóan viselkedik, mint a célalkalmazás.
  • Benchmarking: A tesztelés elvégzése szabványos benchmarking szoftverrel, amely szintetikus, megismételhető munkaterhelést generál.

Az első a legreálisabb és a legkevésbé hordozható eredményt adja; a harmadik olyan számokat ad, amelyek összehasonlíthatók az eszközök és a gyártók között, de keveset mond arról, hogyan fog viselkedni maga az alkalmazás.

Általános tesztelés Concepts Részt vett a tárolási tesztelés során

Mindhárom típus egy-egy különálló tevékenységcsoporthoz tartozik, amelyeket az alábbiakban foglalunk össze.

A tárolási tesztelés típusai Példa a gyakori tárolási tesztelési tevékenységekre
Alkalmazás tesztelése Hasonlítsa össze az OLTP válaszidőket
Hasonlítsa össze a kötegelt futási időket
Hasonlítsa össze a tartós streamelési arányokat
Alkalmazás szimuláció Tesztelje a csúcstároló IOPS-t adatbázisokhoz
Csúcs tárhelyáteresztőképesség tesztelése adatfolyam-környezetekben
Tárolási késleltetés tesztelése üzenetküldéshez vagy más egyszálú alkalmazásokhoz
benchmarking Adatok sérülésének tesztelése

Kulcsfontosságú mutatók a tárolási tesztelésben

A tárolási eredményeket egy kis számhalmazon keresztül jelentik. Bármelyik szám önmagában történő kiolvasása a leggyorsabb módja a téves következtetésre jutásnak, mivel egymás ellen cserélődnek.

Metric Mit mér Ahol a legfontosabb
IOPS Másodpercenként végrehajtott olvasási és írási műveletek, mérettől függetlenül Tranzakciós adatbázisok és kis véletlenszerű írások
Késleltetés Egyetlen I/O művelet kezdete és befejezése között eltelt idő Üzenetküldés és egyszálú alkalmazásútvonalak
áteresztőképesség Másodpercenként átvitt adatmennyiség, általában MB/s-ban Kötegelt futtatások, biztonsági mentések és streamelt munkafolyamatok
Várólista mélysége Egyidejűleg kiadott, függőben lévő kérelmek száma Bármely futtatás, amelynek valós párhuzamosságot kell tükröznie

A várakozási sor mélysége különös figyelmet érdemel. Az egyes kérések kiadása pontos egyedi kérés késleltetést eredményez, de mesterségesen alacsony IOPS és átviteli sebességet, ezért tűnhet egy eszköz tesztben lassúnak, éles környezetben pedig gyorsnak, vagy fordítva.

Tárolási tesztelés végrehajtása

Egy tárolási teszt csak annyira megbízható, mint a körülmények, amelyek között elvégezték. Az alábbi sorrend biztosítja az eredmények megismételhetőségét.

  • 1. lépés) Határozza meg a célt. Döntsd el, hogy a futtatás az adatbázis felkészültségének igazolására, az átviteli határ meghatározására vagy két eszköz összehasonlítására szolgál-e. Minden cél más munkaterhelést von maga után, és ezek keverése olyan számokat eredményez, amelyek alapján senki sem tud cselekedni.
  • 2. lépés) Méretezze reálisan az adathalmazt. Egy olyan kicsi munkahalmaz, amely elfér a gyorsítótárban, a gyorsítótárat méri, nem a tárhelyet. Egyezzen meg az éles adatmennyiséggel, vagy legalábbis nagymértékben haladja meg a gyorsítótár méretét.
  • 3. lépés) Válassza ki az olvasási/írási keveréket és mintát. A véletlenszerű és a szekvenciális hozzáférés ugyanazon az eszközön nagyon eltérően viselkedik, akárcsak a 70/30-as olvasási-írási keverékek és a csak írási célú burstök. Az összehasonlítást az éles monitorozásból, ne pedig az alapértelmezettől vedd.
  • 4. lépés) Állítsa be a várólista mélységét és a szálak számát. Ezek szabályozzák, hogy mennyi párhuzamos adat jut el az eszközhöz, ezért minden találattal rögzítsd őket – egy nélkülük idézett adat nem reprodukálható.
  • 5. lépés) Töröld a gyorsítótárakat és melegítsd be. A futtatások között törölje a szerver- és eszközgyorsítótárakat, majd dobja el az első intervallumot, hogy az állandósult állapotú számokat hasonlítsa össze az elsőként kapottak helyett.
  • 6. lépés) Fuss elég sokáig. A rövid futtatások elrejtik az írási szakadékot, ami akkor jelentkezik, amikor az SSD kimeríti az írási pufferét. A tartós futtatások viszont felfedik ezt.
  • 7. lépés) Figyelje a teljes köteget. A processzor kihasználtságát, a memóriát és a hálózatot a tárhelyszámlálók mellett rögzíti, így egy máshol fellépő szűk keresztmetszetet nem értelmez tárhelykorlátként.
  • 8. lépés) Ismételje meg és hasonlítsa össze. Futtassa ugyanazt a konfigurációt többször, és őrizze meg a naplókat; a teljesítménybeli eltérés a buildek között csak egy tárolt alapvonalhoz képest látható.

Mivel ugyanaz a fegyelem vonatkozik minden terhelésvezérelt mérésre, ezeket a futtatásokat általában a következőkkel együtt tervezik meg: Teljesítményfelmérés és a kiadásra jelölt verzió befagyasztása előtt ütemezve.

Tárolástesztelő eszközök

Az eszközök két csoportba sorolhatók, és a legtöbb csapatnak mindkettőre szüksége van.

  • Szintetikus I/O generátorok. Közművek, mint például FioAz Iometer és a sysbench pontosan leírt munkaterhelést ad ki – a blokkméret, az olvasási/írási arány, a várólista mélysége és az időtartam mind deklarált, így egy futás pontosan megismételhető egy másik eszközön.
  • Alkalmazásszintű betöltőeszközök. Az olyan sofőrök, mint JMeter magát az alkalmazást gyakorolja, hogy a tároló ugyanazt a hozzáférési mintát lássa, amit a valódi felhasználók hoznak létre, beleértve a lekérdezési terveket és az indexelési viselkedést is, amelyeket egy szintetikus eszköz nem tud reprodukálni.

Operaa terhelést generáló rendszerszámlálók teszik teljessé a képet. Bármelyik eszköz is generálja a terhelést, a tárhelyadatokat a processzor-, memória- és hálózati számlálók mellett kell leolvasni – számos tárhelytesztelési technika létezik, beleértve a következőket: benchmark tesztelés és a mennyiségi tesztelés, az eredmény helyes értelmezéséhez a teljes veremnézetre van szükség.

Hibák a tárolási tesztelés során

Legtöbb érvénytelen tárolási eredmény tracvisszatérünk néhány elkerülhető hibához.

  • A rossz szerver teljesítményének monitorozása, így a számok egy olyan gépet írnak le, amely nincs tesztelés alatt.
  • Tárolóeszközök összehasonlítása a szerver gyorsítótárának előzetes törlése nélkül, amely a memóriát, és nem a lemezt méri.
  • A processzor kihasználtságának monitorozásának elfelejtése tesztelés közben, ami egy processzorhoz kötött szűk keresztmetszetet rejt egy tároló alakú tünet mögé.
  • Tárolási teljesítmény tesztelése fájlmásolási parancsokkal, amelyek egyszálúak, gyorsítótár-támogatásúak és nem ismételhetők.

GYIK

Térfogatvizsgálat növeli az alkalmazás által tárolt adatmennyiséget, és figyeli a viselkedés romlását. A tárolási tesztelés az alatta lévő eszközréteget célozza meg, azt mérve, hogy milyen gyorsan lehet az adatokat írni és olvasni vissza.

Minden hely, ahová az alkalmazás ír: adatkönyvtárak, napló- és ideiglenes mappák, feltöltési célok és archív útvonalak. Mindegyiknél ellenőrizni kell, hogy a fájl a megfelelő helyre kerül-e, és hogy a szabad terület helyesen van-e jelentve.

A metrikák változatlanok maradnak, de a kiépített IOPS korlátok, a löketes kreditek és a zajos szomszédok hozzáadódnak. Elég sokáig futtassa, hogy a löketes kredit kimerüljön, ellenkező esetben a mért érték átmeneti korlátot tükröz, nem pedig állandó állapotot.

A gépi tanulási modellek a normál IOPS és késleltetési görbéket veszik alapul, majd a küszöbérték túllépése előtt eltérő jelzőfutásokat végzik. Ugyanezek a modellek előrejelzik a kapacitásnövekedést, így a lemez kimerülését előre jelzik, nem pedig éles környezetben észlelik.

GitHub másodpilóta gyorsan elkészíti a feladatfájlok vázlatait, a gyorsítótár-ürítő burkolókat és az eredmény-elemző szkripteket. A tesztelő továbbra is megadja a blokkméretet, a várólista mélységét és az időtartamot, mivel ezek az éles monitorozásból, nem pedig egy sablonból származnak.

Ez egy érvényes teszteset, nem baleset. Az alkalmazásnak figyelmeztetnie kell, szabályosan degradálnia kell magát, és naplóznia kell az állapotot a leállás helyett. A teljes lemezes állapotból való helyreállítás a következőhöz tartozik: helyreállítási tesztelés.

Általában a gyorsítótár állapota, a sor mélysége vagy a futási idő különbözött közöttük. Az eszköz állapota is számít – egy frissen formázott SSD gyorsabban ír, mint egy olyan, amelyet többször feltöltöttek és újraírtak.

Általában teljesítménytesztelők futtatják, az infrastruktúra- vagy adatbázis-adminisztrátorok pedig az eszközkonfigurációt és az éles hozzáférési mintákat biztosítják. Az eredmény csak akkor védhető, ha mindkét fél egyetért abban, hogy a munkaterhelés realisztikus volt.

Foglald össze ezt a bejegyzést a következőképpen: