sql >> Database teknologi >  >> RDS >> Sqlserver

Hvad skal man sige til ASYNC NETWORK IO-ventetypen?

Du har set denne ventetype før, ikke? Nå, det er bestemt en ventetype, der har forårsaget masser af forvirring. Det umiddelbare fokus er generelt givet til ordet "NETVÆRK", men flere gange har det intet at gøre med netværket!
ASYNC_NETWORK_IO-ventetypen vil typisk give to typer symptomer, hvor den første sessionsarbejdsbelastning venter på, at den tilsvarende klientapplikation anerkender/behandler et givet datasæt og fortæller SQL Server, at den er klar til at behandle/godkende flere data. Det andet symptom er, at der kan være et ydelsesproblem i netværket mellem applikationen og databaseinstansen. Bag kulisserne opbevarer SQL Server dataene i en outputbuffer, indtil der modtages en bekræftelse fra klienten, der afgør, om forbruget af data er komplet. ASYNC_NETWORK_IO er et afslørende tegn på, at applikationen mangler effektivitet i at læse data, den kræver fra sin backend-database. Det underliggende netværk kan også have problemer, som kan give længere ventetider, mens data behandles, og signaler sendes tilbage fra klienten til serveren.

Mulige årsager til denne ventetid omfatter:

  • Applikationskoden henter ikke data korrekt
  • Store datasæt efterspørges af klienten
  • Overdreven filtrering af data, der forekommer på klient- eller applikationssiden
  • Dårligt konfigurerede netværksenheder såsom kort, switches osv.

På et højt niveau vil en DBA måske tjekke disse ting:

  • Gennemgå applikationskoden og sørg for, at applikationen læser data korrekt/effektivt. Trækker din applikation for eksempel et stort antal rækker tilbage for kun at behandle en række ad gangen?
  • Unødvendig datafiltrering på klient-/applikationssiden? Begræns rækkerne.

Hvis ovenstående elementer tjekker ud, men problemerne med ASYNC_NETWORK_IO fortsætter, kan det skyldes netværket. Her er nogle ting, du kan se nærmere på:

  • Inspicer netværkskommunikationsforbindelsen mellem applikationen og backend-databaseinstansen, og bekræft båndbredden.
  • Brug sys.dm_io_virtual_file_stats til at teste netværket for generel latenstid på grund af belastning eller afstand
  • Undersøg NIC-konfigurationen på databaseserveren for at sikre, at ingen fejl og/eller indstillinger mangler.

ASYNC_NETWORK_IO WAIT TYPE kan faktisk være et netværksrelateret problem, men ofte kan det skyldes en klientapplikation, der ikke behandler sine data effektivt. Hvis sidstnævnte faktisk er tilfældet, så er dette en mulighed for DBAS og udviklere til at arbejde sammen for at forstå, hvad applikationen virkelig har brug for i den bedste interesse for back-end-databasens ydeevne. At sikre, at det meste datafiltrering udføres i SQL Server, er en bedste praksis, som kan opnås gennem visninger eller mere specifikke betingelser i transaktionssyntaksen.

Selvom der er mange måder at overvåge og måle ventetiden på ASYNC_NETWORK_IO ved hjælp af katalogiserede DMV'er og udvidede hændelser i SQL Server, opfordrer vi vores fællesskab af SQL Server DBA'er til at se på Quest's Spotlight Cloud, som giver effektivitet til at bestemme årsagen til ventetype forbrug over en historisk periode.


  1. Hvordan clock_timestamp() virker i PostgreSQL

  2. Vælg mellem agentbaseret og agentløs overvågning

  3. Indsættelse af rækker i en tabel med kun én IDENTITY-kolonne

  4. Dumping af datablokke