sql >> Databasteknik >  >> RDS >> Sqlserver

Vad ska man säga om väntetypen ASYNC NETWORK IO?

Du har sett den här väntetypen förut, eller hur? Tja, det är verkligen en väntetyp som har orsakat mycket förvirring. Det omedelbara fokus läggs i allmänhet på ordet "NÄTVERK", men oftare än inte har det ingenting med nätverket att göra!
Väntetypen ASYNC_NETWORK_IO kommer vanligtvis att ge två typer av symtom, den första är sessionens arbetsbelastning väntar på att motsvarande klientapplikation bekräftar/bearbetar en given uppsättning data och låter SQL Server veta att den är redo att bearbeta/kvittera mer data. Det andra symptomet är att det kan finnas ett prestandaproblem i nätverket mellan applikationen och databasinstansen. Bakom kulisserna lagrar SQL Server data i en utdatabuffert tills en bekräftelse tas emot från klienten som avgör om förbrukningen av data är komplett. ASYNC_NETWORK_IO är ett kontrolltecken på att applikationen saknar effektivitet när det gäller att läsa data som den kräver från sin backend-databas. Det underliggande nätverket kan också ha problem som kan orsaka längre väntetider medan data bearbetas och signaler skickas tillbaka från klienten till servern.

Möjliga orsaker till denna väntan inkluderar:

  • Applikationskoden hämtar inte data korrekt
  • Stora datamängder som efterfrågas av klienten
  • Överdriven filtrering av data som förekommer på klient- eller programsidan
  • Dåligt konfigurerade nätverksenheter som kort, switchar etc.

På en hög nivå kanske en DBA vill kontrollera dessa saker:

  • Granska programkoden och se till att programmet läser data korrekt/effektivt. Till exempel, drar din applikation tillbaka ett stort antal rader bara för att behandla en rad i taget?
  • Onödig datafiltrering på klient-/applikationssidan? Begränsa raderna.

Om ovanstående poster checkar ut, men problemen med ASYNC_NETWORK_IO kvarstår, kan det bero på nätverket. Här är några saker du kan titta på:

  • Inspektera nätverkskommunikationslänken mellan applikationen och backend-databasinstansen och verifiera bandbredden.
  • Använd sys.dm_io_virtual_file_stats för att testa nätverket för allmän latens på grund av belastning eller avstånd
  • Undersök NIC-konfigurationen på databasservern för att säkerställa att inga fel och/eller inställningar saknas.

ASYNC_NETWORK_IO WAIT TYPE kan verkligen vara ett nätverksrelaterat problem, men ofta kan det bero på en klientapplikation som inte behandlar sina data effektivt. Om det sistnämnda verkligen är fallet är detta en möjlighet för DBAS och utvecklare att arbeta tillsammans för att förstå vad applikationen verkligen behöver för back-end-databasens prestanda. Att säkerställa att det mesta av datafiltreringen görs inom SQL Server är en bästa praxis som kan uppnås genom vyer eller mer specifika var villkor i transaktionssyntaxen.

Även om det finns många sätt att övervaka och mäta ASYNC_NETWORK_IO-väntan genom att använda katalogiserade DMV:er och utökade händelser i SQL Server, uppmuntrar vi vår community av SQL Server DBA:er att titta på Quests Spotlight Cloud som ger effektivitet när det gäller att fastställa grundorsaken till väntetypen konsumtion under en historisk tidsperiod.


  1. Mytop – Ett användbart verktyg för att övervaka MySQL/MariaDB-prestanda i Linux

  2. Android:öppnar och stänger SQLite-databas

  3. Det går inte att kopiera förskapad db från tillgångar

  4. Hur man hanterar MariaDB 10.3 med ClusterControl