Ajánlott eljárások az optimális teljesítményhez
Az Apache Cassandra Azure Managed Instance egy teljesen felügyelt szolgáltatás tiszta nyílt forráskódú Apache Cassandra-fürtökhöz. A szolgáltatás lehetővé teszi a konfigurációk felül bírálását is az egyes számítási feladatok adott igényeitől függően, ami maximális rugalmasságot és szabályozást tesz lehetővé, ahol szükséges. Ez a cikk tippeket nyújt a teljesítmény optimalizálásához.
Optimális beállítás és konfigurálás
Replikációs tényező, lemezek száma, csomópontok és termékváltozatok száma
Mivel a legtöbb régióban három rendelkezésre állási zónát Azure-támogatás, és a Cassandra felügyelt példány a rendelkezésre állási zónákat állványokra képezi le, javasoljuk, hogy válasszon magas számosságú partíciókulcsot a gyakori elérésű partíciók elkerülése érdekében. A megbízhatóság és a hibatűrés legjobb szintje érdekében javasoljuk, hogy konfiguráljon egy 3-ás replikációs tényezőt. Azt is javasoljuk, hogy adja meg a replikációs tényező többszörösét a csomópontok számaként, például 3, 6, 9 stb.
RAID 0-t használunk a kiépített lemezek számához. Az optimális IOPS eléréséhez ellenőriznie kell a P30-lemez IOPS-jával együtt kiválasztott termékváltozat maximális IOPS-ját. Az SKU például Standard_DS14_v2 51 200 nem csatlakoztatott IOPS-t támogat, míg egyetlen P30-lemez alapteljesítménye 5000 IOPS. Tehát négy lemez 20 000 IOPS-t eredményezne, ami jóval a gép korlátai alatt van.
Határozottan javasoljuk, hogy a számítási feladat széles körű teljesítményértékelését a termékváltozat és a lemezek száma alapján mérje fel. A teljesítménymérés különösen fontos a mindössze nyolc maggal rendelkező termékváltozatok esetében. Kutatásunk azt mutatja, hogy nyolc magos processzor csak a legkevésbé igényes számítási feladatokhoz működik, és a legtöbb számítási feladatnak legalább 16 magra van szüksége a teljesítményhez.
Elemzési és tranzakciós számítási feladatok
A tranzakciós számítási feladatokhoz általában alacsony késésre optimalizált adatközpontra van szükség, míg az elemzési számítási feladatok gyakran összetettebb lekérdezéseket használnak, amelyek végrehajtása hosszabb időt vesz igénybe. A legtöbb esetben külön adatközpontokat szeretne:
- Alacsony késésre optimalizált
- Elemzési számítási feladatokhoz optimalizált
Elemzési számítási feladatok optimalizálása
Javasoljuk, hogy az ügyfelek az alábbi cassandra.yaml beállításokat alkalmazzák az elemzési számítási feladatokhoz (lásd itt az alkalmazás módját).
Időtúllépések
| Érték | Cassandra MI alapértelmezett | Elemzési számítási feladatokra vonatkozó javaslat |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 10,000 |
| range_request_timeout_in_ms | 10,000 | 20000 |
| counter_write_request_timeout_in_ms | 5,000 | 10,000. |
| cas_contention_timeout_in_ms | 1,000 | 2000 |
| truncate_request_timeout_in_ms | 60,000 | 120 000 |
| slow_query_log_timeout_in_ms | 500 | 1000 |
| roles_validity_in_ms | 2,000 | 120 000 |
| permissions_validity_in_ms | 2,000 | 120 000 |
Gyorsítótárak
| Érték | Cassandra MI alapértelmezett | Elemzési számítási feladatokra vonatkozó javaslat |
|---|---|---|
| file_cache_size_in_mb | 2,048 | 6,144 |
További javaslatok
| Érték | Cassandra MI alapértelmezett | Elemzési számítási feladatokra vonatkozó javaslat |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| compaction_throughput_mb_per_sec | 128 | 256 |
Ügyfélbeállítások
Javasoljuk, hogy a Kiszolgálón alkalmazott időtúllépéseknek megfelelően növelje a Cassandra-ügyfélillesztők időtúllépéseit.
Optimalizálás az alacsony késésre
Az alapértelmezett beállítások már alkalmasak alacsony késésű számítási feladatokhoz. A késések legjobb teljesítményének biztosítása érdekében javasoljuk, hogy használjon olyan ügyfélillesztőt, amely támogatja a spekulatív végrehajtást , és ennek megfelelően konfigurálja az ügyfelet. A Java V4-illesztőhöz egy bemutatót talál, amely bemutatja, hogyan működik ez, és hogyan engedélyezheti a szabályzatot.
Teljesítmény-palackok nyakának monitorozása
CPU-teljesítmény
Mint minden adatbázisrendszer, a Cassandra is akkor működik a legjobban, ha a processzorhasználat 50% körül van, és soha nem éri el a 80%-ot. A CPU-metrikákat a Metrikák lapon tekintheti meg a Monitorozás lapon a portálról:
Ha a processzor a legtöbb csomópont esetében végleg meghaladja a 80%-ot, az adatbázis túlterhelté válik, ami több ügyfél-időtúllépés során jelentkezik. Ebben a forgatókönyvben a következő műveleteket javasoljuk:
- vertikálisan skálázható fel egy több processzormaggal rendelkező termékváltozatra (különösen akkor, ha a magok csak 8 vagy annál kisebbek).
- horizontális skálázás további csomópontok hozzáadásával (ahogy korábban említettük, a csomópontok számának a replikációs tényező többszörösének kell lennie).
Ha a cpu csak néhány csomópont esetében magas, de a többiek számára alacsony, akkor egy gyakori partíciót jelez, és további vizsgálatot igényel.
Feljegyzés
A termékváltozat módosítása az Azure Portalon, az Azure CLI-vel és az ARM-sablon üzembe helyezésével támogatott. Az ARM-sablont üzembe helyezheti/szerkesztheti, és lecserélheti az SKU-t az alábbiak egyikére.
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
Vegye figyelembe, hogy jelenleg nem támogatjuk a termékváltozat-családok közötti váltást. Ha például jelenleg rendelkezik termékváltozattal Standard_DS13_v2 , és nagyobb termékváltozatra Standard_DS14_v2szeretne frissíteni, ez a lehetőség nem érhető el. Megnyithat azonban egy támogatási jegyet a magasabb termékváltozatra való frissítés igényléséhez.
Lemezteljesítmény
A szolgáltatás azure P30-beli felügyelt lemezeken fut, amelyek lehetővé teszik a "burst IOPS"-t. A lemezzel kapcsolatos teljesítmény szűk keresztmetszetei esetén gondos monitorozásra van szükség. Ebben az esetben fontos áttekinteni az IOPS-metrikákat:
Ha a metrikák az alábbi jellemzők egyikét vagy mindegyikét mutatják, az azt jelezheti, hogy fel kell skáláznia.
- Következetesen magasabb vagy egyenlő az alap IOPS-nál (ne felejtse el szorozni az 5000 IOPS-t a csomópontonkénti lemezek számával a szám lekéréséhez).
- Következetesen magasabb vagy egyenlő az írási termékváltozathoz engedélyezett maximális IOPS-értéknél.
- Az SKU támogatja a gyorsítótárazott tárolást (írási gyorsítótárazás), és ez a szám kisebb, mint a felügyelt lemezek IOPS-ja (ez lesz az olvasási IOPS felső korlátja).
Ha csak néhány csomópont esetében látja az IOPS-emelt szintű IOPS-t, előfordulhat, hogy van egy gyakori partíciója, és át kell tekintenie az adatokat egy esetleges eltérés miatt.
Ha az IOPS alacsonyabb a választott termékváltozat által támogatottnál, de magasabb vagy egyenlő a lemez IOPS-jával, a következő műveleteket hajthatja végre:
- Adjon hozzá további lemezeket a teljesítmény növelése érdekében. A lemezek számának növeléséhez támogatási esetet kell létrehozni.
- Az adatközpont(ok) vertikális felskálázása további csomópontok hozzáadásával.
Ha az IOPS maximálisan támogatja az SKU-t, a következőket teheti:
- skálázás egy másik termékváltozatra, amely több IOPS-t támogat.
- Az adatközpont(ok) vertikális felskálázása további csomópontok hozzáadásával.
További információkért tekintse meg a virtuális gép és a lemez teljesítményét.
Hálózati teljesítmény
A legtöbb esetben a hálózati teljesítmény elegendő. Ha azonban gyakran streameli az adatokat (például gyakori horizontális felskálázás/leskálázás), vagy hatalmas bejövő/kimenő adatmozgások vannak, ez problémát okozhat. Előfordulhat, hogy ki kell értékelnie az SKU hálózati teljesítményét. Az SKU például Standard_DS14_v2 12 000 Mb/s-ot támogat, hasonlítsa össze ezt a metrikák bájt/ki értékével:
Ha csak néhány csomópont esetében látja emelt szintűnek a hálózatot, előfordulhat, hogy egy gyakori partícióval rendelkezik, és át kell tekintenie az adateloszlási és/vagy hozzáférési mintákat egy esetleges eltérés esetén.
- Vertikálisan felskálázható egy másik termékváltozatra, amely több hálózati I/O-t támogat.
- Horizontálisan skálázza fel a fürtöt további csomópontok hozzáadásával.
Túl sok csatlakoztatott ügyfél
Az üzembe helyezéseket úgy kell megtervezni és kiépíteni, hogy támogassák az alkalmazás kívánt késéséhez szükséges párhuzamos kérelmek maximális számát. Egy adott üzembe helyezés esetén a rendszernek a minimális küszöbérték feletti nagyobb terhelés növeli az általános késést. Figyelje meg a csatlakoztatott ügyfelek számát, hogy ez ne lépje túl az elviselhető korlátokat.
Lemezterület
A legtöbb esetben elegendő lemezterület áll rendelkezésre, mivel az alapértelmezett üzemelő példányok IOPS-ra vannak optimalizálva, ami a lemez alacsony kihasználtságát eredményezi. Mindazonáltal javasoljuk, hogy időnként tekintse át a lemezterület-metrikákat. A Cassandra sok lemezt halmoz fel, majd csökkenti azt a tömörítés aktiválásakor. Ezért fontos áttekinteni a lemezhasználatot hosszabb időszakokban, hogy trendeket állapítsunk meg – például a tömörítés nem tudja visszavenni a helyet.
Feljegyzés
A tömörítéshez rendelkezésre álló hely biztosítása érdekében a lemezkihasználtságot 50% körül kell tartani.
Ha csak néhány csomópont esetében látja ezt a viselkedést, előfordulhat, hogy egy gyakori partícióval rendelkezik, és át kell tekintenie az adateloszlási és/vagy hozzáférési mintákat egy esetleges eltérés esetén.
- további lemezeket adhat hozzá, de tartsa szem előtt az SKU által előírt IOPS-korlátozásokat
- a fürt horizontális felskálázása
JVM-memória
Az alapértelmezett képlet a virtuális gép memóriájának felét 31 GB-os felső korláttal rendeli a JVM-hez , ami a legtöbb esetben jó egyensúly a teljesítmény és a memória között. Egyes számítási feladatok, különösen azok, amelyek gyakori keresztpartíciós olvasással vagy tartományvizsgálattal rendelkeznek, memóriabeli nehézségekkel járhatnak.
A legtöbb esetben a Java szemétgyűjtő hatékonyan visszanyeri a memóriát, de különösen akkor, ha a processzor gyakran 80% felett van, nincs elegendő processzorciklus a szemétgyűjtőnek. Ezért a processzorteljesítmény-problémákat a memóriaproblémák előtt kell kezelni.
Ha a processzor 70% alatt van, és a szemétgyűjtés nem tudja visszanyerni a memóriát, több JVM-memóriára lehet szüksége. Ez különösen akkor fordul fenn, ha korlátozott memóriával rendelkező termékváltozatot használ. A legtöbb esetben át kell tekintenie a lekérdezéseket és az ügyfélbeállításokat, és csökkentenie fetch_size kell a CQL-lekérdezésben limit kiválasztottakkal együtt.
Ha valóban több memóriára van szüksége, a következőkre van szüksége:
- Küldjön nekünk egy jegyet a JVM memóriabeállításainak növeléséhez
- Vertikális skálázás több memóriával rendelkező termékváltozatra
Sírkövek
A javításokat hét naponta reaperrel futtatjuk, amely eltávolítja azokat a sorokat, amelyek TTL-értéke lejárt (az úgynevezett "tombstone"). Egyes számítási feladatok gyakrabban törölnek, és figyelmeztetéseket látnak, például Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) a Cassandra-naplókban, vagy akár olyan hibákat, amelyek azt jelzik, hogy a lekérdezés nem teljesíthető a túlzott sírkövek miatt.
Rövid távú kockázatcsökkentés, ha a lekérdezések nem teljesülnek, a Cassandra konfigurációjának növelése tombstone_failure_threshold az alapértelmezett 100 000-ről egy magasabb értékre.
Ezen kívül javasoljuk, hogy tekintse át a TTL-t a kulcstéren, és akár naponta futtassa a javításokat, hogy több sírkövet töröljön. Ha a TCL-ek rövidek, például kevesebb mint két nap, és az adatfolyamok gyorsan törlődnek, javasoljuk, hogy tekintse át a tömörítési stratégiát , és részesítse előnyben Leveled Compaction Strategy. Bizonyos esetekben az ilyen műveletek arra utalhatnak, hogy szükség van az adatmodell felülvizsgálatára.
Batch-figyelmeztetések
Ez a figyelmeztetés a CassandraLogsban és az esetlegesen kapcsolódó hibákban jelenhet meg:
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
Ebben az esetben érdemes áttekinteni a lekérdezéseket, hogy a javasolt kötegméret alatt maradjon. Ritka esetekben és rövid távú kockázatcsökkentésként a Cassandra konfigurációja az alapértelmezett 50-ről magasabb értékre növelhetőbatch_size_fail_threshold_in_kb.
Nagyméretű partíció figyelmeztetése
Ez a figyelmeztetés a CassandraLogsban jelenhet meg:
Writing large partition <table> (105.426MiB) to sstable <file>
Ez problémát jelez az adatmodellben. Íme egy halom túlcsordulásról szóló cikk , amely részletesebben is bemutatja. Ez súlyos teljesítményproblémákat okozhat, és meg kell oldani.
Speciális optimalizálás
Tömörítés
A Cassandra lehetővé teszi a megfelelő tömörítési algoritmus kiválasztását egy tábla létrehozásakor (lásd : Tömörítés). Az alapértelmezett érték az LZ4, amely kiválóan alkalmas az átviteli sebességre és a CPU-ra, de több helyet foglal el a lemezen. A Zstd (Cassandra 4.0 és újabb verzió) használata körülbelül ~12%-os helyet takarít meg minimális processzorterheléssel.
A memtable halomterület optimalizálása
Alapértelmezés szerint a JVM halom 1/4-ét használjuk a cassandra.yaml memtable_heap_space . Írásorientált alkalmazások és/vagy kis memóriával rendelkező termékváltozatok esetén ez gyakori kipiruláshoz és töredezett sstable-khoz vezethet, ami nagyobb tömörítést igényel. Ilyen esetekben a növekedés legalább 4048-ra előnyös lehet, de gondos teljesítménymérést igényel annak érdekében, hogy más műveletek (például olvasások) ne legyenek hatással.
Következő lépések
Ebben a cikkben bemutattunk néhány ajánlott eljárást az optimális teljesítmény érdekében. Most már megkezdheti a fürttel való munkát: