Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ebben a cikkben a felügyelt Redis-gyorsítótár Azure terhelésének használatát és monitorozását ismertetjük.
Értékméretek
Az ügyfélalkalmazás kialakítása határozza meg, hogy több kis értéket vagy kevesebb nagyobb értéket kell-e tárolnia. A Redis-kiszolgáló szempontjából a kisebb értékek jobb teljesítményt biztosítanak. Javasoljuk, hogy az értékméret 100 kB-nál kisebb legyen.
Ha a tervezés során nagyobb értékeket kell tárolnia a Azure Felügyelt Redisben, a kiszolgáló terhelése nagyobb lesz. Ebben az esetben előfordulhat, hogy magasabb gyorsítótárszintet kell használnia, hogy a processzorhasználat ne korlátozza az átviteli sebességet.
Még ha a gyorsítótár rendelkezik is elegendő processzorkapacitással, a nagyobb értékek növelik a késéseket, ezért kövesse a megfelelő időtúllépések konfigurálásáról szóló szakasz útmutatását.
Ügyfélkapcsolati csúcsok elkerülése
A kapcsolatok létrehozása és bezárása költséges művelet a Redis-kiszolgáló esetében. Ha az ügyfélalkalmazás túl sok kapcsolatot hoz létre vagy zár be rövid idő alatt, az megterhelheti a Redis-kiszolgálót.
Ha egyszerre több ügyfélpéldányt hoz létre a Redishez való csatlakozáshoz, érdemes lehet eltolni az új kapcsolatok létrehozását, hogy elkerülje a csatlakoztatott ügyfelek számának hirtelen megnövekedését.
Memóriaterhelés
A kiszolgáló magas memóriahasználata miatt nagyobb valószínűséggel történik meg az, hogy a rendszernek lemezre kell helyeznie az adatokat, ami olyan laphibákat okoz, amelyek jelentősen lelassíthatják a rendszert.
Kerülje el a hosszasan futó parancsokat.
A Redis-kiszolgáló egy egyszálas rendszer. A hosszú ideig futó parancsok késést vagy időtúllépést okozhatnak az ügyféloldalon, mivel a kiszolgáló nem tud más kérésekre válaszolni, miközben egy hosszú ideig futó parancson dolgozik. További információért lásd: Az Azure Cache for Redis kiszolgálóoldali problémáinak hibaelhárítása.
Kiszolgálói terhelés és processzor figyelése
Monitorozást állítson be a szerver terhelésére és a CPU-ra, hogy értesítést kapjon, ha bármelyik értéke magasnak bizonyul. A monitorozás segíthet megérteni az alkalmazás korlátozásait. Ezt követően proaktív módon kezelheti a problémákat. Javasoljuk, hogy a teljesítményre gyakorolt negatív hatások elkerülése érdekében próbálja meg 80% alatt tartani a kiszolgálóterhelést. A kiszolgáló 80%-nál nagyobb tartós terhelése nem tervezett feladatátvételekhez vezethet.
Jelenleg Azure Managed Redis két metrikát tesz elérhetővé a
A CPU (más néven percentProcessorTime) metrika a gyorsítótárat üzemeltető csomópont processzorhasználatát jelzi. A CPU metrika olyan folyamatokat is tartalmaz, amelyek nem szigorúan Redis-kiszolgálófolyamatok. A CPU tartalmazza a háttérfolyamatokat, például a kártevőirtó programokét és másokat is. Ennek eredményeképpen előfordulhat, hogy a CPU metrika kiugróan magas értéket mutat, és nem feltétlenül a Redis-kiszolgáló processzorhasználatának tökéletes mutatója.
A Kiszolgálóbetöltési metrika a Redis-kiszolgálónak a teljes terhelésre vonatkozó saját értékelését tükrözi, és hasonló a CPU-metrikához, de fürtszinten.
Javaslatok kisebb termékváltozatokhoz
A 2 vCPU virtuális gépekkel (B0–B5, X3 és M10) támogatott Azure felügyelt Redis SKU-k esetében a százalékalapú metrikák, mint például a kiszolgálói terhelés és a CPU, eredendően érzékenyebbek. Egyetlen rövid élettartamú háttérszál a teljes CPU jelentős százalékát használhatja fel, így a metrikák akkor is megemelkednek, ha a tényleges számítási feladat könnyű. Ennek eredményeképpen ezek a metrikák túlbecsülhetik a kis termékváltozatok tényleges terhelését, és nem jelezhetik a számítási feladatok telítettségét.
A metrikák hosszabb időszakokra ( például több órára vagy napra) történő áttekintésekor a következőket javasoljuk:
- CPU használata Szerver Terhelés helyett, mivel a példány szintjén tekinthető meg, nagyobb részletgazdagságot biztosítva
- Felosztás a Azure Felügyelt Redis-példányt futtató virtuális gépek példányazonosítója alapján
- Átlag aggregáció használata a Maximum helyett ezekben a hosszabb időtartományokban
A maximális összesítést rövid idő alatt is használhatja a rövid idő alatt bekövetkező csúcsok vagy események (például időtúllépéseket vagy feladatátvételeket okozható) elfogásához, miközben a hosszabb időszakok átlagára támaszkodva trendelemzést végezhet a kis termékváltozatok esetében, különösen processzorhasználat esetén.
Nagyobb kiszolgálóterhelés tesztelése feladatátvétel után
Standard és prémium termékváltozatok esetén minden gyorsítótár két csomóponton üzemel. Egy terheléselosztó osztja el az ügyfélkapcsolatokat a két csomópont között. Ha tervezett vagy nem tervezett karbantartás történik az elsődleges csomóponton, a csomópont lezárja az összes ügyfélkapcsolatot. Ilyen esetekben az összes ügyfélkapcsolat egyetlen csomópontra kerülhet, ami miatt a kiszolgáló terhelése nő a fennmaradó csomóponton. Javasoljuk, hogy tesztelje ezt a forgatókönyvet úgy, hogy újraindítja az elsődleges csomópontot, és biztosítja, hogy egy csomópont kezelni tudja az összes ügyfélkapcsolatot anélkül, hogy a kiszolgáló terhelése túlságosan megnövekedne.