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 az Azure Managed Redis Cache 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 kialakításhoz nagyobb értékeket kell tárolnia az Azure Managed 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 a hosszú ideig 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ó: Az Azure Cache for Redis kiszolgálóoldali hibáinak elhárítása.
Kiszolgáló terhelésének monitorozása
Monitorozza a kiszolgálóterhelést, hogy értesítést kapjon magas kiszolgálóterhelés előfordulása esetén. 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. Az Azure Managed Redis jelenleg két metrikát tesz elérhetővé a Portál bal oldalán található Erőforrás menü Figyelés területén, a CPU és a kiszolgálói terhelés alatt. A kiszolgáló terhelésének monitorozása során fontos megérteni, hogy mit mérnek az egyes metrikák.
A CPU-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 metrika a kártevőirtó és egyéb háttérfolyamatokat is magában foglalja. 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és metrika csak a Redis-kiszolgálón lévő terhelést jelöli. Javasoljuk, hogy cpu helyett a kiszolgálói terhelés metrikáját monitorozza.
A kiszolgáló terhelésének monitorozása során azt is javasoljuk, hogy az átlagos helyett vizsgálja meg a kiszolgálói terhelés maximális csúcsait, mert még a rövid csúcsok is kiválthatják a feladatátvételeket és a parancsok időtúllépéseit.
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.