Megosztás a következőn keresztül:

Az Azure Cosmos DB .NET SDK-kérelmek időtúllépési kivételeinek diagnosztizálása és elhárítása

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

A 408-as HTTP-hiba akkor fordul elő, ha az SDK nem tudja az időkorlát túllépése előtt befejezni a kérés feldolgozását.

Fontos meggyőződni arról, hogy az alkalmazás tervezése az Azure Cosmos DB SDK-kkal rendelkező rugalmas alkalmazások tervezésére vonatkozó útmutatónk szerint történik, hogy megfelelően reagáljon a különböző hálózati feltételekre. Az alkalmazásnak újrapróbálkozást kell használnia az időtúllépési hibák esetére, mert ezek az elosztott rendszerekben általában várhatóak.

Időtúllépési hibák esetén az eset kiértékelésekor:

  • Mi a mért hatás az érintett műveletek számát a sikeres műveletek számával összehasonlítva? A szolgáltatás SLA-kon belül van?
  • Befolyásolja a P99 késése/ rendelkezésre állása?
  • A hibák az összes alkalmazáspéldányt érintik, vagy csak egy részüket? Ha a probléma csak a példányok egy részére korlátozódik, a probléma általában az adott példányokkal kapcsolatos.

Időtúllépés testreszabása az Azure Cosmos DB .NET SDK-n

Az SDK-nak két különböző alternatívája van az időtúllépések szabályozására, amelyek mindegyike eltérő hatókörrel rendelkezik.

Kérelemszintű időtúllépések

ConnectionPolicy.RequestTimeout Az CosmosClientOptions.RequestTimeout SDK v2 konfigurációjával időtúllépést állíthat be a hálózati kéréshez, miután a kérés elhagyta az SDK-t, és a hálózaton van, amíg a rendszer nem kap választ.

ConnectionPolicy.OpenTcpConnectionTimeout Az CosmosClientOptions.OpenTcpConnectionTimeout SDK v2 konfigurációjával időtúllépést állíthat be a kezdeti kapcsolat megnyitásához. A kapcsolat megnyitása után a további kérések a kapcsolatot fogják használni.

A felhasználó által indított műveletek több hálózati kérésre is kiterjedhetnek, például újrapróbálkozhatnak. Ez a két konfiguráció kérésenként, nem pedig végpontok közötti művelet.

CancellationToken

Az SDK összes aszinkron művelete rendelkezik opcionális CancellationToken paraméterrel. Ez a CancellationToken paraméter a teljes művelet során, az összes hálózati kérés és újrapróbálkozás során használatos. A hálózati kérelmeknél a rendszer ellenőrizheti a visszavonási jogkivonatot, és megszakíthat egy műveletet, ha a kapcsolódó jogkivonat lejárt. A visszavonási jogkivonattal hozzávetőlegesen megállapíthatja a művelet hatókörére vonatkozó várható időtúllépést.

Feljegyzés

A CancellationToken paraméter egy olyan mechanizmus, amelyben a kódtár ellenőrzi a lemondást, ha az nem okoz érvénytelen állapotot. Előfordulhat, hogy a művelet nem pontosan a visszavonásban meghatározott időpontban szakad meg. Ehelyett a rendszer akkor szakítja meg a művelet, ha az idő letelt, és ha a megszakítást biztonságosan el lehet végezni.

Hibaelhárítási lépések

Az alábbi lista a kérelem-időtúllépési kivételekkel kapcsolatos hibák ismert okait és megoldásait tartalmazza.

CosmosOperationCanceledException

Ilyen típusú kivétel akkor fordul elő gyakran, amikor az alkalmazás CancellationToken paramétereket továbbít az SDK-műveletek számára. Az SDK ellenőrzi a CancellationToken két újrapróbálkozás közötti állapotot, és ha a CancellationToken művelet megszakad, ezzel a kivétellel megszakítja az aktuális műveletet.

A kivétel az MessageToString() / átvétel CancellationToken Cancellation Token has expired: true állapotát is jelzi, és a diagnosztika is tartalmazza az érintett kérések lemondásának kontextusát.

Ezek a kivételek biztonságosan újrapróbálkozhatnak, és az újrapróbálkozás szempontjából időtúllépésként kezelhetők .

Megoldás

Ellenőrizze, hogy a konfigurált idő CancellationTokennagyobb-e, mint a RequestTimeout és a CosmosClientOptions.OpenTcpConnectionTimeout (ha Direct módot használ). Ha a rendelkezésre álló idő kisebb, CancellationToken mint a konfigurált időtúllépések, és az SDK átmeneti csatlakozási problémákkal szembesül, az SDK nem fog tudni újra próbálkozni, és dobni CosmosOperationCanceledExceptionfog.

Magas processzorkihasználtság

A leggyakoribb ok a magas processzorkihasználtság. Az optimális késéshez a processzorkihasználtságnak nagyjából 40 százalékosnak kell lennie. A maximális (nem átlagos) processzorkihasználtságot 10 másodperces időközönként monitorozza. Kiugróan magas processzorhasználat gyakrabban fordulhat elő a többpartíciós lekérdezéseknél, amelyek során több kapcsolat is létesülhet egyetlen lekérdezéshez.

Az időtúllépések diagnosztikát tartalmaznak, amelyek a következőket tartalmazzák:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • Ha az cpu értékek több mint 70%-osak, az időtúllépést valószínűleg a processzorkimerülés okozza. Ebben az esetben a megoldás a magas CPU-kihasználtság forrásának vizsgálata és a kihasználtság csökkentése, vagy a gép felskálázása egy nagyobb erőforrás-méretre.
  • Ha a threadInfo/isThreadStarving csomópontok értékekkel rendelkeznek True , az ok a szál éhezése. Ebben az esetben a megoldás a szál erőforráshiányát (esetlegesen zárolt szálakat) előidéző ok kivizsgálása, vagy a gép(ek) felskálázása egy nagyobb erőforrás-méretre.
  • Ha a dateUtc mérések közötti idő nem körülbelül 10 másodperc, az a szálkészlet versengését is jelezné. A processzor mérése független feladatként megy végbe, amely várólistára helyezve 10 másodpercenként kerül be a szálkészletbe. Ha a mérések közötti idő hosszabb, az azt jelzi, hogy az aszinkron feladatok nem dolgozhatók fel időben. A leggyakoribb forgatókönyvek aszinkron kódon végzett hívásblokkolással járnak az alkalmazáskódban.

Megoldás

Az SDK-t használó ügyfélalkalmazást horizontálisan vagy vertikálisan fel kell skálázni.

A szoftvercsatorna vagy a port rendelkezésre állása alacsony

Azure-beli futtatáskor a .NET SDK-t használó ügyfelek azt tapasztalhatják, hogy kifogytak az Azure SNAT (PAT)-portokból.

1\. megoldás

Ha Azure-beli virtuális gépeken fut, kövesse az SNAT portkimerülési útmutatóját.

2\. megoldás

Ha Azure-alkalmazás Szolgáltatáson fut, kövesse a csatlakozási hibák hibaelhárítási útmutatóját, és használja az App Service-diagnosztikát.

3\. megoldás

Ha az Azure Functionsben fut, ellenőrizze, hogy követi-e az Azure Functions azon javaslatát , amely szerint az összes érintett szolgáltatáshoz (beleértve az Azure Cosmos DB-t is) egyetlen vagy statikus ügyfeleket tart fenn. Ellenőrizze a szolgáltatás korlátait a függvényalkalmazás-üzemeltetés típusa és mérete alapján.

4. megoldás

HA HTTP-proxyt használ, győződjön meg arról, hogy támogatja az SDK-ban ConnectionPolicykonfigurált kapcsolatok számát. Ellenkező esetben kapcsolati problémákat fog tapasztalni.

Több ügyfélpéldány létrehozása

Több ügyfélpéldány létrehozása kapcsolati versengéshez és időtúllépéshez vezethet. A diagnosztika két releváns tulajdonságot tartalmaz:

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated nyomon követi, hogy hányszor jött létre egy CosmosClient adott alkalmazás ugyanazon az AppDomainen belül, és NumberOfActiveClients nyomon követi az aktív ügyfeleket (nincs megsemmisítve). Az elvárás az, hogy ha a singleton mintát követi, X az megegyezik az alkalmazás által használható és azzal egyenlő Yfiókok számávalX.

Ha X nagyobb Y, akkor az azt jelenti, hogy az alkalmazás ügyfélpéldányokat hoz létre és bocsát ki. Ez kapcsolati versengést és/vagy CPU-versengést eredményezhet.

Megoldás

Kövesse a teljesítményre vonatkozó tippeket, és használjon fiókonként egyetlen CosmosClient-példányt egy teljes folyamat során. Kerülje az ügyfelek létrehozását és eltávolítását.

Gyakori hozzáférésű partíciókulcs

Az Azure Cosmos DB a teljes kiosztott átviteli sebességet egyenlően osztja el a fizikai partíciók között. Ha van egy gyakori hozzáférésű partíció, a fizikai partíció egy vagy több logikai partíciókulcsa a fizikai partíció összes másodpercenkénti kérelemegységét (RU/s) felhasználja. Ugyanakkor a többi fizikai partíció másodpercenkénti kérelemegysége kihasználatlan marad. Ez azt jelzi, hogy a felhasznált ru/s teljes mennyisége kisebb lesz, mint az adatbázis vagy tároló általánosan kiosztott RU/s értéke, de továbbra is szabályozás (429s) jelenik meg a gyakori elérésű logikai partíciókulcsra irányuló kérelmeken. A Normalized RU Consumption metrika használatával ellenőrizze, hogy a számítási feladat gyakori elérésű partícióval találkozik-e.

Megoldás

Válasszon egy jó partíciókulcsot, amely egyenletesen osztja el a kérelemkötetet és a tárterületet. Megtudhatja, hogyan módosíthatja a partíciókulcsot.

Magas fokú egyidejűség

Az alkalmazás magas szintű egyidejűséget végez, ami versengéshez vezethet a csatornán.

Megoldás

Az SDK-t használó ügyfélalkalmazást horizontálisan vagy vertikálisan fel kell skálázni.

Nagy méretű kérelmek vagy válaszok

A nagy kérések vagy válaszok a csatorna folyamatos blokkolásához és a versengés súlyosbodásához vezethetnek, még viszonylag alacsony fokú egyidejűség esetén is.

Megoldás

Az SDK-t használó ügyfélalkalmazást horizontálisan vagy vertikálisan fel kell skálázni.

A hibaarány az Azure Cosmos DB SLA-ján belül van

Az alkalmazásnak képesnek kell lennie kezelni az átmeneti hibákat, és szükség esetén újra kell próbálkoznia. A rendszer nem próbálkozik újra a 408 kivétellel, mert a létrehozási útvonalakon lehetetlen megállapítani, hogy a szolgáltatás hozta-e létre az elemet, vagy sem. Ha ugyanazt az elemet újra elküldi létrehozásra, ütközési kivételt okoz. Előfordulhat, hogy a felhasználói alkalmazások üzleti logikája egyéni logikával rendelkezik az ütközések kezeléséhez, ami a meglévő elem kétértelműségétől és a létrehozási újrapróbálkozások ütközésétől szakítana.

A hibaarány sérti az Azure Cosmos DB SLA-t

Lépjen kapcsolatba az Azure ügyfélszolgálatával.

Következő lépések