Az Azure Cache for Redis késésének és időtúllépéseinek hibaelhárítása

  • Cikk

Azok az ügyfélműveletek, amelyekre nem érkezik időben válasz, nagy mértékű késést vagy időtúllépési kivételt okozhatnak. Az időtúllépésre a művelet különböző fázisaiban kerülhet sor. Az időtúllépés forrásának azonosítása segíthet az okok és a megoldás megállapításában.

Ez a szakasz az Azure Cache for Redishez való csatlakozáskor fellépő késési és időtúllépési problémák hibaelhárítását ismerteti.

Feljegyzés

Az útmutató számos hibaelhárítási lépése tartalmazza a Redis-parancsok futtatására és a különböző teljesítménymetrikák figyelésére vonatkozó utasításokat. További információkért és utasításokért tekintse meg a További információk szakaszban található cikkeket.

Ügyféloldali hibaelhárítás

Itt találja az ügyféloldali hibaelhárítást.

Hirtelen forgalomnövekedés és szálkészlet-konfiguráció

A rossz ThreadPool beállításokkal kombinált adatforgalom-sorozatok késést okozhatnak a Redis-kiszolgáló által már elküldött, de az ügyféloldalon még nem felhasznált adatok feldolgozásában. Ellenőrizze a Hibák (UnresponsiveClients típus) metrika alapján, hogy az ügyfél gazdagépe lépést tud-e tartani a forgalom hirtelen növekedésével.

Egy példa ThreadPoolLoggersegítségével megfigyelheti, hogyan változnak a ThreadPool statisztikák az idő függvényében. A StackExchange.Redis üzeneteit a következő további vizsgálatokhoz használhatja TimeoutException :

    System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

Az előző kivételben számos olyan probléma van, amely érdekes:

  • Figyelje meg, hogy a IOCP szakaszban és a WORKER szakaszban van egy Busy érték, amely nagyobb, mint az Min érték. Ez a különbség azt jelenti, hogy a ThreadPool beállításokat módosítani kell.
  • Az is látható in: 64221. Ez az érték azt jelzi, hogy 64 221 bájt érkezett az ügyfél kernelcsatornájának rétegére, de az alkalmazás nem olvasta be. Ez a különbség általában azt jelenti, hogy az alkalmazás (például a StackExchange.Redis) nem olvas olyan gyorsan adatokat a hálózatról, mint a kiszolgáló.

Konfigurálhatja a ThreadPool Gépház, hogy a szálkészlet gyorsan felskálázható legyen a kipukkadásos helyzetekben.

Nagy kulcsérték

További információ a több kulcs és a kisebb értékek használatáról: További kulcsok és kisebb értékek.

A parancs segítségével redis-cli --bigkeys nagy kulcsokat kereshet a gyorsítótárban. További információ: redis-cli, a Redis parancssori felülete– Redis.

  • A virtuális gép méretének növelése a nagyobb sávszélességű képességek eléréséhez
    • Az ügyfél- vagy kiszolgálói virtuális gép nagyobb sávszélessége csökkentheti a nagyobb válaszok adatátviteli idejét.
    • Hasonlítsa össze a két gép aktuális hálózati használatát az aktuális virtuálisgép-méret korlátaival. Előfordulhat, hogy a nagyobb sávszélesség csak a kiszolgálón vagy csak az ügyfélen nem elegendő.
  • Növelje az alkalmazás által használt kapcsolatobjektumok számát.
    • Ciklikus időszeleteléses módszer használata különböző kapcsolatobjektumokon keresztüli kérések létrehozásához

Magas CPU-használat az ügyfélgazdagépeken

A magas ügyfél cpu-használat azt jelzi, hogy a rendszer nem tud lépést tartani a hozzá rendelt munkával. Annak ellenére, hogy a gyorsítótár gyorsan elküldte a választ, előfordulhat, hogy az ügyfél nem tudja időben feldolgozni a választ. Azt javasoljuk, hogy az ügyfél CPU-ja kevesebb, mint 80%. Ellenőrizze a "Hibák" metrikát (típus: UnresponsiveClients) annak megállapításához, hogy az ügyfél gazdagépei képesek-e időben feldolgozni a Redis-kiszolgálótól érkező válaszokat.

Az ügyfél rendszerszintű processzorhasználatának monitorozása az Azure Portalon elérhető metrikákkal vagy a gép teljesítményszámlálóival. Ügyeljen arra, hogy ne figyelje a folyamat processzorát, mert egyetlen folyamat processzorhasználata alacsony lehet, de a rendszerszintű processzor magas lehet. Figyelje meg az időtúllépéseknek megfelelő processzorhasználat csúcsait. A magas PROCESSZOR magas értékeket is okozhat in: XXX a hibaüzenetekben TimeoutException a [Forgalomkitörés] szakaszban leírtak szerint.

Feljegyzés

A StackExchange.Redis 1.1.603-at és újabb verzióit a local-cpu hibaüzenetek tartalmazzák TimeoutException . Győződjön meg arról, hogy a StackExchange.Redis NuGet csomag legújabb verzióját használja. A hibák rendszeresen javítva vannak a kódban, hogy robusztusabbá tegyék az időtúllépéseket. A legújabb verzió fontos.

Az ügyfél magas processzorhasználatának csökkentése:

  • Vizsgálja meg, hogy mi okozza a processzor kiugró csúcsait.
  • Frissítse az ügyfelet nagyobb virtuálisgép-méretre, nagyobb processzorkapacitással.

Hálózati sávszélesség korlátozása az ügyfél gazdagépén

Az ügyfélgépek architektúrájától függően előfordulhat, hogy korlátozott a rendelkezésre álló hálózati sávszélesség. Ha az ügyfél a hálózati kapacitás túlterhelésével túllépi a rendelkezésére álló sávszélességet, akkor az adatok nem lesznek olyan gyorsan feldolgozva az ügyféloldalon, ahogyan a kiszolgáló küldi azokat. Ez a helyzet időtúllépésekhez vezethet.

A sávszélesség-használat időbeli változásának monitorozása egy példa BandwidthLoggerhasználatával. Előfordulhat, hogy ez a kód bizonyos korlátozott engedélyekkel rendelkező környezetekben (például Azure-webhelyeken) nem fut sikeresen.

A probléma mérséklése érdekében csökkentse a hálózati sávszélesség használatát, vagy növelje az ügyfél virtuálisgép-méretét egy nagyobb hálózati kapacitással rendelkezőre. További információ: Nagy kérés vagy válaszméret.

TCP-beállítások Linux-alapú ügyfélalkalmazásokhoz

A Linux optimista TCP-beállításai miatt a Linuxon üzemeltetett ügyfélalkalmazások csatlakozási problémákat tapasztalhatnak. További információ: A Linux által üzemeltetett ügyfélalkalmazások TCP-beállításai

RedisSessionStateProvider újrapróbálkozási időtúllépése

Ha használja RedisSessionStateProvider, győződjön meg arról, hogy helyesen állítja be az újrapróbálkozás időtúllépését. Az retryTimeoutInMilliseconds értéknek magasabbnak kell lennie, mint az operationTimeoutInMilliseconds érték. Ellenkező esetben nem történik újrapróbálkozás. Az alábbi példában retryTimeoutInMilliseconds 3000 értékre van állítva. További információ: ASP.NET Azure Cache for Redis munkamenet-állapotszolgáltatója, valamint a munkamenet-állapotszolgáltató és a kimeneti gyorsítótár-szolgáltató konfigurációs paramétereinek használata.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Kiszolgálóoldali hibaelhárítás

Itt találja a kiszolgálóoldali hibaelhárítást.

Kiszolgáló karbantartása

A tervezett vagy nem tervezett karbantartás zavart okozhat az ügyfelek kapcsolatában. A kivételek száma és jellege függ a kérésnek a kód elérési útjában elfoglalt helyétől és attól, hogy mikor zárja le a kapcsolatokat a gyorsítótár. Előfordulhat például, hogy egy kérést küldő, de a feladatátvételkor nem kap választ, időtúllépési kivételt kaphat. A bezárt kapcsolatobjektum új kérései kapcsolati kivételeket kapnak, amíg az újracsatlakozás sikeresen meg nem történik.

További információt az alábbi szakaszokban talál:

Annak ellenőrzéséhez, hogy az Azure Cache for Redis feladatátvételt végzett-e az időtúllépések során, ellenőrizze a metrikahibákat. Az Azure Portal Erőforrás menüjében válassza a Metrikák lehetőséget. Ezután hozzon létre egy új diagramot, amely a metrikát Errors méri, felosztással ErrorType. A diagram létrehozása után megjelenik a feladatátvétel száma.

A feladatátvételekről további információt az Azure Cache for Redis feladatátvétele és javítása című témakörben talál.

Magas kiszolgálóterhelés

A kiszolgáló magas terhelése azt jelenti, hogy a Redis-kiszolgáló nem tud lépést tartani a kérésekkel, ami időtúllépésekhez vezet. Előfordulhat, hogy a kiszolgáló lassan válaszol, és nem tud lépést tartani a kérések mennyiségével.

Monitorozza a metrikákat , például a kiszolgáló terhelését. Figyelje meg az időtúllépéseknek Server Load megfelelő használati csúcsokat. Hozzon létre riasztásokat a kiszolgáló terhelésére vonatkozó metrikákról, hogy időben értesüljön a lehetséges hatásokról.

A kiszolgálók magas terhelésének csökkentése érdekében számos módosítást végezhet:

  • Vizsgálja meg, hogy mi okozza a magas kiszolgálóterhelést, például a hosszú ideig futó parancsokat, amelyet ebben a cikkben jegyezünk fel a magas memóriaterhelés miatt.
  • Horizontális felskálázás több szegmensre a terhelés több Redis-folyamat közötti elosztásához, vagy nagyobb gyorsítótárméretre skálázás több processzormaggal. További információ: Azure Cache for Redis – gyakori kérdések.
  • Ha a C1-gyorsítótárban lévő éles számítási feladatra negatív hatással van a víruskeresésből származó extra késés, csökkentheti a hatást, ha magasabb szintű ajánlatot fizet több processzormaggal, például C2-vel.

Kiugróan magas a kiszolgáló terhelése

A C0- és C1-gyorsítótárakban előfordulhat, hogy a kiszolgáló terhelésének rövid kiugrásait nem a kérelmek napi párszori növekedése okozza, miközben a virtuális gépeken víruskeresés fut. A kérelmek nagyobb késést tapasztalnak, miközben ezeken a szinteken víruskeresés zajlik. A C0- és C1-szintek gyorsítótárai csak egyetlen maggal rendelkeznek a többfeladatos működéshez, elosztva a víruskeresés és a Redis-kérelmek kiszolgálásának munkáját.

Magas memóriahasználat

Ezt a szakaszt áthelyezték. További információ: Magas memóriahasználat.

Hosszú ideig futó parancsok

Egyes Redis-parancsok végrehajtása időigényesebb a többiénél. A Redis-parancsok dokumentációja az egyes parancsok időösszetettségét mutatja. A Redis parancsfeldolgozása egyszálas. Minden olyan parancs, amely hosszú ideig tart a futtatáshoz, blokkolhatja az azt követő összes többi parancsot.

Tekintse át a Redis-kiszolgálónak kiadott parancsokat, hogy megértse a teljesítményre gyakorolt hatásukat. A KEYS parancsot például gyakran használják anélkül, hogy tudná, hogy O(N) műveletről van szó. A KULCSOK elkerülése érdekében a SCAN használatával csökkentheti a processzor kiugró tüskéit.

A SLOWLOG GET paranccsal mérheti a kiszolgálón végrehajtott drága parancsokat.

Az ügyfelek konzolon futtathatják ezeket a Redis-parancsokat a hosszú ideig futó és költséges parancsok vizsgálatához.

  • A SLOWLOG a Redis lassú lekérdezési naplójának olvasására és alaphelyzetbe állítására szolgál. Az ügyféloldalon hosszan futó parancsok vizsgálatára használható. A Redis Slow Log egy olyan rendszer, amely naplózza azokat a lekérdezéseket, amelyek túllépték a megadott végrehajtási időt. A végrehajtási idő nem tartalmaz olyan I/O-műveleteket, mint az ügyféllel való beszélgetés, a válasz elküldése stb., hanem csak a parancs végrehajtásához szükséges idő. Az ügyfelek a parancs használatával mérhetik/naplózhatják a SLOWLOG Redis-kiszolgálón végrehajtott drága parancsokat.
  • A MONITOR egy hibakeresési parancs, amely a Redis-kiszolgáló által feldolgozott összes parancsot streameli. Segíthet megérteni, hogy mi történik az adatbázissal. Ez a parancs igényes, és negatívan befolyásolhatja a teljesítményt. Csökkentheti a teljesítményt.
  • INFO – a parancs olyan formátumban adja vissza a kiszolgáló adatait és statisztikáit, amely a számítógépek által egyszerűen elemezhető és az emberek által könnyen olvasható. Ebben az esetben a CPU-szakasz hasznos lehet a processzorhasználat vizsgálatához. A kiszolgáló 100 -os terhelése (maximális érték) azt jelzi, hogy a Redis-kiszolgáló mindig foglalt volt, és soha nem volt tétlen a kérések feldolgozásakor.

Kimeneti minta:

# CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1
  • ÜGYFÉLLISTA – az ügyfélkapcsolati kiszolgálóra vonatkozó információkat és statisztikákat adja vissza többnyire emberi olvasásra alkalmas formátumban.

Hálózati sávszélesség korlátozása

A különböző gyorsítótárméretek különböző hálózati sávszélesség-kapacitással rendelkeznek. Ha a kiszolgáló túllépi a rendelkezésre álló sávszélességet, a rendszer nem küldi el az adatokat olyan gyorsan az ügyfélnek. Az ügyfélkérések túlléphetik az időkorlátot amiatt, hogy a kiszolgáló nem képes elég gyorsan leküldeni az adatokat az ügyfélnek.

A „Gyorsítótár-olvasás” és a „Gyorsítótárírás” metrika alapján megállapítható a kiszolgálóoldalon felhasznált sávszélesség. Ezeket a metrikákat a portálon tekintheti meg. Hozzon létre riasztásokat olyan metrikákhoz, mint például a gyorsítótár-olvasás vagy a gyorsítótárírás, így idejekorán értesülhet a lehetséges negatív hatásokról.

Olyan helyzetek elhárítása, amikor a hálózati sávszélesség kihasználtsága megközelíti a maximális kapacitást:

StackExchange.Redis időtúllépési kivételek

A StackExchange.Redis használatakor az időtúllépésekkel kapcsolatos további információkért lásd : Időtúllépési kivételek vizsgálata a StackExchange.Redisben.

Kapcsolódó tartalom