Az Azure Managed Redis felügyeleti gyakori kérdések

Ez a cikk az Azure Managed Redis kezelésével kapcsolatos gyakori kérdésekre ad választ.

Mikor érdemes engedélyezni a nem TLS-/SSL-portot a Redishez való csatlakozáshoz?

A TLS használata ajánlott eljárásként gyakorlatilag minden Redis-használati eset esetében ajánlott. A TLS nélküli csatlakozás lehetősége a visszamenőleges kompatibilitás érdekében is elérhető.

Mik az éles környezetben ajánlott eljárások?

• A StackExchange.Redis ajánlott eljárásai
• Konfiguráció és fogalmak
• Teljesítménytesztelés

A StackExchange.Redis ajánlott eljárásai

• Állítsa hamisra AbortConnect , majd hagyja, hogy a ConnectionMultiplexer automatikusan újracsatlakozjon.
• Használjon egyetlen, hosszú élettartamú ConnectionMultiplexer példányt ahelyett, hogy minden kéréshez új kapcsolatot hoz létre.
• A Redis kisebb értékekkel működik a legjobban, ezért fontolja meg a nagyobb adatok több kulcsba való feldarabolását. A Redis-vita során a 100 kb-os méretet nagynak tekintjük. További információ: Ajánlott eljárások fejlesztése.
• Konfigurálja a ThreadPool beállításait az időtúllépések elkerülése érdekében.
• Használja legalább az 5 másodperces alapértelmezett connectTimeout értéket. Ez az intervallum elegendő időt biztosít a StackExchange.Redis számára a kapcsolat újbóli létrehozásához, ha van hálózati három pont.
• Vegye figyelembe a különböző futtatott műveletekhez kapcsolódó teljesítményköltségeket. A parancs például egy O(n) művelet, KEYS amelyet el kell kerülni. A redis.io webhely részletes információkat tartalmaz az egyes támogatott műveletek időbeli összetettségéről. Válassza ki az egyes parancsokat az egyes műveletek összetettségének megtekintéséhez.

Konfiguráció és fogalmak

• Ne feledje, hogy a Redis egy memóriabeli adattár. További információ: Adatvesztés hibaelhárítása az Azure Managed Redisben , hogy tisztában legyen az adatvesztést okozó forgatókönyvekkel.
• Úgy fejlesztheti a rendszert, hogy kezelni tudja a javítás és a feladatátvétel által okozott kapcsolati hibákat.

Teljesítménytesztelés

• Tekintse meg az Azure Managed Redis teljesítménytesztjeit, például a teljesítményteszteket és a saját teljesítménytesztek Azure Managed Redisen való futtatására vonatkozó utasításokat.

Milyen szempontokat érdemes figyelembe venni a gyakori Redis-parancsok használatakor?

• Ne használjon olyan Redis-parancsokat, amelyek végrehajtása hosszú időt vesz igénybe, hacsak nem ismeri teljes mértékben ezeknek a parancsoknak az eredményét. Például ne futtassa a KEYS parancsot éles környezetben. A kulcsok számától függően hosszú időt vehet igénybe a visszatérés. Minden Redis-szegmens egyszálas, és egyenként dolgozza fel a parancsokat. Ha a KULCSok után más parancsok is ki vannak adva, azok nem lesznek feldolgozva, amíg a Redis nem dolgozza fel a KEYS parancsot. A redis.io webhely részletes információkat tartalmaz az egyes támogatott műveletek időbeli összetettségéről. Válassza ki az egyes parancsokat az egyes műveletek összetettségének megtekintéséhez.
• Kulcsméretek – használjon kis kulcsot/értékeket vagy nagy kulcsokat/értékeket? Ez a forgatókönyvtől függ. Ha a forgatókönyv nagyobb kulcsokat igényel, módosíthatja a ConnectionTimeoutot, majd újrapróbálkozhat, és módosíthatja az újrapróbálkozási logikát. A Redis-kiszolgáló szempontjából a kisebb értékek jobb teljesítményt biztosítanak.
• Ezek a szempontok nem jelentik azt, hogy nem tárolhat nagyobb értékeket a Redisben; a következő szempontokat kell figyelembe vennie. A késések magasabbak. Ha egy nagyobb és egy kisebb adatkészlettel rendelkezik, több ConnectionMultiplexer-példányt is használhat. Konfigurálja mindegyiket eltérő időtúllépési és újrapróbálkozási értékekkel az előző Mit tesz a StackExchange.Redis konfigurációs beállításai című szakaszban leírtak szerint.

Hogyan mérhetem fel és tesztelhetem a gyorsítótáram teljesítményét?

• Engedélyezze a gyorsítótár-diagnosztikát, hogy figyelhesse a gyorsítótár állapotát. A mérőszámokat megtekintheti az Azure Portalon, illetve többféle eszközzel is letöltheti és áttekintheti őket.
• Tekintse meg az Azure Managed Redis teljesítménytesztjeit, például a teljesítményteszteket és a saját teljesítménytesztek Azure Managed Redisen való futtatására vonatkozó utasításokat.

A ThreadPool növekedésének fontos részletei

A CLR ThreadPool két száltípussal rendelkezik: feldolgozó és I/O befejezési port (IOCP) szálak.

• A feldolgozószálak olyan dolgokhoz használatosak, mint a feldolgozás vagy Task.Run(…) a ThreadPool.QueueUserWorkItem(…)metódusok. Ezeket a szálakat a CLR különböző összetevői is használják, amikor egy háttérszálon kell dolgozni.
• Az IOCP-szálak akkor használatosak, ha aszinkron IO történik, például a hálózatról való olvasáskor.

A szálkészlet igény szerint (szabályozás nélkül) új feldolgozószálakat vagy I/O-befejezési szálakat biztosít, amíg el nem éri a "Minimum" beállítást az egyes száltípusokhoz. Alapértelmezés szerint a szálak minimális száma a rendszer processzorainak számára van beállítva.

Miután a meglévő (foglalt) szálak száma eléri a szálak "minimális" számát, a ThreadPool szabályozza azt a sebességet, amelyen 500 ezredmásodpercenként egy szálba injektálja az új szálakat. Ha a rendszer általában egy IOCP-szálat igénylő munkakitörést kap, az gyorsan feldolgozza a működést. Ha azonban a kipukkadás nagyobb, mint a konfigurált "Minimum" beállítás, a munka egy részének feldolgozása késik, mivel a ThreadPool a két lehetőség egyikére vár:

• Egy meglévő szál szabadon feldolgozhatja a munkát.
• Egyetlen meglévő szál sem lesz ingyenes 500 ms-ra, és létrejön egy új szál.

Alapvetően, ha a foglalt szálak száma nagyobb, mint a Min szál, valószínűleg 500 ms késleltetést kell fizetnie, mielőtt az alkalmazás feldolgozná a hálózati forgalmat. Továbbá, ha egy meglévő szál 15 másodpercnél hosszabb ideig tétlen marad, megtisztítja, és ez a növekedési és zsugorodási ciklus ismétlődhet.

Ha megnézzük a StackExchange.Redis (1.0.450-ös vagy újabb build) egy példa hibaüzenetét, láthatjuk, hogy a ThreadPool statisztikáit nyomtatja. A cikk későbbi részében lásd az IOCP és a WORKER részleteit.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

A példában látható, hogy az IOCP-szál esetében hat foglalt szál van, és a rendszer úgy van konfigurálva, hogy négy minimális szálat engedélyezzen. Ebben az esetben az ügyfél két 500 ms-os késést látna, mert 6 > 4.

Megjegyzés:

A StackExchange.Redis időtúllépéseket okozhat, ha az IOCP- vagy a WORKER-szálak növekedése szabályozva lesz.

Ajánlás

Javasoljuk, hogy az ügyfelek az IOCP- és WORKER-szálak minimális konfigurációs értékét az alapértelmezett értéknél nagyobb értékre állítsa. Ehhez az értékhez nem adhatunk teljes körű útmutatást, mert az egyik alkalmazás megfelelő értéke túl magas vagy alacsony lehet egy másik alkalmazáshoz. Ez a beállítás a bonyolult alkalmazások más részeinek teljesítményét is befolyásolhatja. Minden ügyfélnek finomhangolnia kell ezt a beállítást a saját igényeinek megfelelően. Egy jó kiindulási hely 200 vagy 300, majd tesztelje és finomhangolás szükség szerint.

A beállítás konfigurálása:

Javasoljuk, hogy programozott módon módosítsa ezt a beállítást a ThreadPool.SetMinThreads (...) metódussal a .NET-keretrendszerben és a .NET Core-alkalmazásokban.

A NET-keretrendszerben például a következő metódusban Global.asax.csApplication_Start állíthatja be:

```csharp
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ThreadPool.SetMinThreads(minThreads, minThreads);
}
```

Ha .NET Core-t használ, a következő hívás előtt állítsa be Program.csa következőre WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Megjegyzés:

A metódus által megadott érték egy globális beállítás, amely a teljes AppDomainre hatással van. Ha például négy maggal rendelkező gépe van, és a futási idő alatt processzoronként 50-et szeretne beállítani minWorkerThreadsminIoThreads , használja ThreadPool.SetMinThreads(200, 200).

A minimális szálbeállítást is megadhatja a következő konfigurációs elem konfigurációs elemének vagy konfigurációs beállításának használatával: .> Machine.config általában a következő helyen található: %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.

A szálak minimális számának ilyen módon történő beállítása nem ajánlott, mert ez egy rendszerszintű beállítás. Ha így állítja be, újra kell indítania az alkalmazáskészletet.

Megjegyzés:

Az ebben a konfigurációelemben megadott érték magonkénti beállítás. Ha például négy magos géppel rendelkezik, és azt szeretné, hogy a minIoThreads beállítás futásidőben 200 legyen, használja a következőt <processModel minIoThreads="50">: .

Engedélyezze a kiszolgálói GC-t, hogy több átviteli sebességet kapjon az ügyfélen a StackExchange.Redis használatakor

A kiszolgálói GC engedélyezése optimalizálhatja az ügyfelet, és jobb teljesítményt és átviteli sebességet biztosíthat a StackExchange.Redis használatakor. A kiszolgálói csoportházirend-objektumról és annak engedélyezéséről az alábbi cikkekben talál további információt:

• Kiszolgálói csoportházirend-objektum engedélyezése
• Szemétgyűjtés alapjai
• Szemétgyűjtés és teljesítmény

A kapcsolatok teljesítményével kapcsolatos szempontok

A különböző termékváltozatok eltérő korlátozásokkal rendelkezhetnek az ügyfélkapcsolatokra, a memóriára és a sávszélességre vonatkozóan. Bár a gyorsítótár minden mérete legfeljebb néhány kapcsolatot tesz lehetővé, a Redishez való minden kapcsolat többletterheléssel jár. Ilyen többletterhelésre példa a processzor- és memóriahasználat a TLS/SSL-titkosítás miatt. Egy adott gyorsítótárméret maximális kapcsolati korlátja enyhén betöltött gyorsítótárat feltételez. Ha a kapcsolat többletterhelése és az ügyfélműveletek terhelése meghaladja a rendszer kapacitását, a gyorsítótár kapacitásproblémákat tapasztalhat akkor is, ha nem lépi túl az aktuális gyorsítótárméret csatlakozási korlátját.

Az egyes szintek különböző kapcsolati korlátairól további információt az Azure Managed Redis díjszabásában talál.

Kapcsolódó tartalom

• További információ az Azure Managed Redis egyéb gyakori kérdésekről.

Ez a cikk az Azure Managed Redis kezelésével kapcsolatos gyakori kérdésekre ad választ.

A TLS használata ajánlott eljárásként gyakorlatilag minden Redis-használati eset esetében ajánlott. A TLS nélküli csatlakozás lehetősége a visszamenőleges kompatibilitás érdekében is elérhető.

• A StackExchange.Redis ajánlott eljárásai
• Konfiguráció és fogalmak
• Teljesítménytesztelés

A StackExchange.Redis ajánlott eljárásai

• Állítsa hamisra AbortConnect , majd hagyja, hogy a ConnectionMultiplexer automatikusan újracsatlakozjon.
• Használjon egyetlen, hosszú élettartamú ConnectionMultiplexer példányt ahelyett, hogy minden kéréshez új kapcsolatot hoz létre.
• A Redis kisebb értékekkel működik a legjobban, ezért fontolja meg a nagyobb adatok több kulcsba való feldarabolását. A Redis-vita során a 100 kb-os méretet nagynak tekintjük. További információ: Ajánlott eljárások fejlesztése.
• Konfigurálja a ThreadPool beállításait az időtúllépések elkerülése érdekében.
• Használja legalább az 5 másodperces alapértelmezett connectTimeout értéket. Ez az intervallum elegendő időt biztosít a StackExchange.Redis számára a kapcsolat újbóli létrehozásához, ha van hálózati három pont.
• Vegye figyelembe a különböző futtatott műveletekhez kapcsolódó teljesítményköltségeket. A parancs például egy O(n) művelet, KEYS amelyet el kell kerülni. A redis.io webhely részletes információkat tartalmaz az egyes támogatott műveletek időbeli összetettségéről. Válassza ki az egyes parancsokat az egyes műveletek összetettségének megtekintéséhez.

Konfiguráció és fogalmak

• Ne feledje, hogy a Redis egy memóriabeli adattár. További információ: Adatvesztés hibaelhárítása az Azure Managed Redisben , hogy tisztában legyen az adatvesztést okozó forgatókönyvekkel.
• Úgy fejlesztheti a rendszert, hogy kezelni tudja a javítás és a feladatátvétel által okozott kapcsolati hibákat.

Teljesítménytesztelés

• Tekintse meg az Azure Managed Redis teljesítménytesztjeit, például a teljesítményteszteket és a saját teljesítménytesztek Azure Managed Redisen való futtatására vonatkozó utasításokat.

• Ne használjon olyan Redis-parancsokat, amelyek végrehajtása hosszú időt vesz igénybe, hacsak nem ismeri teljes mértékben ezeknek a parancsoknak az eredményét. Például ne futtassa a KEYS parancsot éles környezetben. A kulcsok számától függően hosszú időt vehet igénybe a visszatérés. Minden Redis-szegmens egyszálas, és egyenként dolgozza fel a parancsokat. Ha a KULCSok után más parancsok is ki vannak adva, azok nem lesznek feldolgozva, amíg a Redis nem dolgozza fel a KEYS parancsot. A redis.io webhely részletes információkat tartalmaz az egyes támogatott műveletek időbeli összetettségéről. Válassza ki az egyes parancsokat az egyes műveletek összetettségének megtekintéséhez.
• Kulcsméretek – használjon kis kulcsot/értékeket vagy nagy kulcsokat/értékeket? Ez a forgatókönyvtől függ. Ha a forgatókönyv nagyobb kulcsokat igényel, módosíthatja a ConnectionTimeoutot, majd újrapróbálkozhat, és módosíthatja az újrapróbálkozási logikát. A Redis-kiszolgáló szempontjából a kisebb értékek jobb teljesítményt biztosítanak.
• Ezek a szempontok nem jelentik azt, hogy nem tárolhat nagyobb értékeket a Redisben; a következő szempontokat kell figyelembe vennie. A késések magasabbak. Ha egy nagyobb és egy kisebb adatkészlettel rendelkezik, több ConnectionMultiplexer-példányt is használhat. Konfigurálja mindegyiket eltérő időtúllépési és újrapróbálkozási értékekkel az előző Mit tesz a StackExchange.Redis konfigurációs beállításai című szakaszban leírtak szerint.

• Engedélyezze a gyorsítótár-diagnosztikát, hogy figyelhesse a gyorsítótár állapotát. A mérőszámokat megtekintheti az Azure Portalon, illetve többféle eszközzel is letöltheti és áttekintheti őket.
• Tekintse meg az Azure Managed Redis teljesítménytesztjeit, például a teljesítményteszteket és a saját teljesítménytesztek Azure Managed Redisen való futtatására vonatkozó utasításokat.

A CLR ThreadPool két száltípussal rendelkezik: feldolgozó és I/O befejezési port (IOCP) szálak.

• A feldolgozószálak olyan dolgokhoz használatosak, mint a feldolgozás vagy Task.Run(…) a ThreadPool.QueueUserWorkItem(…)metódusok. Ezeket a szálakat a CLR különböző összetevői is használják, amikor egy háttérszálon kell dolgozni.
• Az IOCP-szálak akkor használatosak, ha aszinkron IO történik, például a hálózatról való olvasáskor.

A szálkészlet igény szerint (szabályozás nélkül) új feldolgozószálakat vagy I/O-befejezési szálakat biztosít, amíg el nem éri a "Minimum" beállítást az egyes száltípusokhoz. Alapértelmezés szerint a szálak minimális száma a rendszer processzorainak számára van beállítva.

Miután a meglévő (foglalt) szálak száma eléri a szálak "minimális" számát, a ThreadPool szabályozza azt a sebességet, amelyen 500 ezredmásodpercenként egy szálba injektálja az új szálakat. Ha a rendszer általában egy IOCP-szálat igénylő munkakitörést kap, az gyorsan feldolgozza a működést. Ha azonban a kipukkadás nagyobb, mint a konfigurált "Minimum" beállítás, a munka egy részének feldolgozása késik, mivel a ThreadPool a két lehetőség egyikére vár:

• Egy meglévő szál szabadon feldolgozhatja a munkát.
• Egyetlen meglévő szál sem lesz ingyenes 500 ms-ra, és létrejön egy új szál.

Alapvetően, ha a foglalt szálak száma nagyobb, mint a Min szál, valószínűleg 500 ms késleltetést kell fizetnie, mielőtt az alkalmazás feldolgozná a hálózati forgalmat. Továbbá, ha egy meglévő szál 15 másodpercnél hosszabb ideig tétlen marad, megtisztítja, és ez a növekedési és zsugorodási ciklus ismétlődhet.

Ha megnézzük a StackExchange.Redis (1.0.450-ös vagy újabb build) egy példa hibaüzenetét, láthatjuk, hogy a ThreadPool statisztikáit nyomtatja. A cikk későbbi részében lásd az IOCP és a WORKER részleteit.

System.TimeoutException: Timeout performing GET MyKey, inst: 2, mgr: Inactive,
queue: 6, qu: 0, qs: 6, qc: 0, wr: 0, wq: 0, in: 0, ar: 0,
IOCP: (Busy=6,Free=994,Min=4,Max=1000),
WORKER: (Busy=3,Free=997,Min=4,Max=1000)

A példában látható, hogy az IOCP-szál esetében hat foglalt szál van, és a rendszer úgy van konfigurálva, hogy négy minimális szálat engedélyezzen. Ebben az esetben az ügyfél két 500 ms-os késést látna, mert 6 > 4.

Megjegyzés:

A StackExchange.Redis időtúllépéseket okozhat, ha az IOCP- vagy a WORKER-szálak növekedése szabályozva lesz.

Ajánlás

Javasoljuk, hogy az ügyfelek az IOCP- és WORKER-szálak minimális konfigurációs értékét az alapértelmezett értéknél nagyobb értékre állítsa. Ehhez az értékhez nem adhatunk teljes körű útmutatást, mert az egyik alkalmazás megfelelő értéke túl magas vagy alacsony lehet egy másik alkalmazáshoz. Ez a beállítás a bonyolult alkalmazások más részeinek teljesítményét is befolyásolhatja. Minden ügyfélnek finomhangolnia kell ezt a beállítást a saját igényeinek megfelelően. Egy jó kiindulási hely 200 vagy 300, majd tesztelje és finomhangolás szükség szerint.

A beállítás konfigurálása:

Javasoljuk, hogy programozott módon módosítsa ezt a beállítást a ThreadPool.SetMinThreads (...) metódussal a .NET-keretrendszerben és a .NET Core-alkalmazásokban.

A NET-keretrendszerben például a következő metódusban Global.asax.csApplication_Start állíthatja be:

```csharp
private readonly int minThreads = 200;
void Application_Start(object sender, EventArgs e)
{
    // Code that runs on application startup
    AreaRegistration.RegisterAllAreas();
    RouteConfig.RegisterRoutes(RouteTable.Routes);
    BundleConfig.RegisterBundles(BundleTable.Bundles);
    ThreadPool.SetMinThreads(minThreads, minThreads);
}
```

Ha .NET Core-t használ, a következő hívás előtt állítsa be Program.csa következőre WebApplication.CreateBuilder():

```csharp
const int minThreads = 200
              
ThreadPool.SetMinThreads(minThreads, minThreads);

var builder = WebApplication.CreateBuilder(args);
// rest of application setup
```

Megjegyzés:

A metódus által megadott érték egy globális beállítás, amely a teljes AppDomainre hatással van. Ha például négy maggal rendelkező gépe van, és a futási idő alatt processzoronként 50-et szeretne beállítani minWorkerThreadsminIoThreads , használja ThreadPool.SetMinThreads(200, 200).

A minimális szálbeállítást is megadhatja a következő konfigurációs elem konfigurációs elemének vagy konfigurációs beállításának használatával: .> Machine.config általában a következő helyen található: %SystemRoot%\Microsoft.NET\Framework\[versionNumber]\CONFIG\.

A szálak minimális számának ilyen módon történő beállítása nem ajánlott, mert ez egy rendszerszintű beállítás. Ha így állítja be, újra kell indítania az alkalmazáskészletet.

Megjegyzés:

Az ebben a konfigurációelemben megadott érték magonkénti beállítás. Ha például négy magos géppel rendelkezik, és azt szeretné, hogy a minIoThreads beállítás futásidőben 200 legyen, használja a következőt <processModel minIoThreads="50">: .

A kiszolgálói GC engedélyezése optimalizálhatja az ügyfelet, és jobb teljesítményt és átviteli sebességet biztosíthat a StackExchange.Redis használatakor. A kiszolgálói csoportházirend-objektumról és annak engedélyezéséről az alábbi cikkekben talál további információt:

• Kiszolgálói csoportházirend-objektum engedélyezése
• Szemétgyűjtés alapjai
• Szemétgyűjtés és teljesítmény

A különböző termékváltozatok eltérő korlátozásokkal rendelkezhetnek az ügyfélkapcsolatokra, a memóriára és a sávszélességre vonatkozóan. Bár a gyorsítótár minden mérete legfeljebb néhány kapcsolatot tesz lehetővé, a Redishez való minden kapcsolat többletterheléssel jár. Ilyen többletterhelésre példa a processzor- és memóriahasználat a TLS/SSL-titkosítás miatt. Egy adott gyorsítótárméret maximális kapcsolati korlátja enyhén betöltött gyorsítótárat feltételez. Ha a kapcsolat többletterhelése és az ügyfélműveletek terhelése meghaladja a rendszer kapacitását, a gyorsítótár kapacitásproblémákat tapasztalhat akkor is, ha nem lépi túl az aktuális gyorsítótárméret csatlakozási korlátját.

Az egyes szintek különböző kapcsolati korlátairól további információt az Azure Managed Redis díjszabásában talál.

Kapcsolódó tartalom

• További információ az Azure Managed Redis egyéb gyakori kérdésekről.