Je hebt dit wachttype eerder gezien, nietwaar? Nou, het is zeker een wachttype dat veel verwarring heeft veroorzaakt. De directe focus wordt over het algemeen gegeven aan het woord "NETWERK", maar vaker wel dan niet heeft het niets te maken met het netwerk!
Het wachttype ASYNC_NETWORK_IO levert doorgaans twee soorten symptomen op, waarbij de eerste sessiewerkbelasting wacht tot de bijbehorende clienttoepassing een bepaalde set gegevens bevestigt/verwerkt en SQL Server laat weten dat deze klaar is om meer gegevens te verwerken/bevestigen. Het tweede symptoom is dat er een prestatieprobleem kan zijn in het netwerk tussen de toepassing en het database-exemplaar. Achter de schermen bewaart SQL Server de gegevens in een uitvoerbuffer totdat een bevestiging is ontvangen van de client die bepaalt of het compleet. ASYNC_NETWORK_IO is een veelbetekenend teken dat de toepassing niet efficiënt is in het lezen van gegevens die nodig zijn uit de backend-database. Het onderliggende netwerk kan ook problemen hebben die langere wachttijden kunnen veroorzaken terwijl gegevens worden verwerkt en signalen worden teruggestuurd van de client naar de server.
Mogelijke oorzaken voor deze wachttijd zijn:
- Applicatiecode haalt gegevens niet correct op
- Grote datasets gevraagd door de klant
- Overmatige filtering van gegevens aan de client- of applicatiezijde
- Slecht geconfigureerde netwerkapparaten zoals kaarten, switches, enz.
Op een hoog niveau wil een DBA deze dingen misschien controleren:
- Controleer de applicatiecode en zorg ervoor dat de applicatie gegevens correct/efficiënt leest. Trekt uw toepassing bijvoorbeeld een groot aantal rijen terug om één rij tegelijk te verwerken?
- Onnodige data-filtering aan de client/applicatie kant? Beperk de rijen.
Als de bovenstaande items uitchecken, maar de problemen met ASYNC_NETWORK_IO blijven bestaan, kan dit aan het netwerk liggen. Hier zijn enkele dingen waar u naar kunt kijken:
- Inspecteer de netwerkcommunicatieverbinding tussen de applicatie en de back-enddatabase-instantie en verifieer de bandbreedte.
- Gebruik de sys.dm_io_virtual_file_stats om het netwerk te testen op algemene latentie als gevolg van belasting of afstand
- Bekijk de NIC-configuratie op de databaseserver om er zeker van te zijn dat er geen fouten en/of instellingen ontbreken.
Het ASYNC_NETWORK_IO WAIT TYPE kan inderdaad een netwerkgerelateerd probleem zijn, maar vaak kan het te wijten zijn aan een clienttoepassing die de gegevens niet efficiënt verwerkt. Als dit laatste inderdaad het geval is, is dit een kans voor DBAS en ontwikkelaars om samen te werken om te begrijpen wat de applicatie echt nodig heeft in het belang van de prestaties van de back-enddatabase. Ervoor zorgen dat de meeste gegevensfiltering binnen SQL Server wordt gedaan, is een best practice die kan worden bereikt via views of meer specifieke waar-voorwaarden in de transactiesyntaxis.
Hoewel er veel manieren zijn om de ASYNC_NETWORK_IO-wachttijd te bewaken en te meten door het gebruik van gecatalogiseerde DMV's en uitgebreide gebeurtenissen in SQL Server, moedigen we onze gemeenschap van SQL Server-DBA's aan om naar Quest's Spotlight Cloud te kijken, die efficiëntie biedt bij het bepalen van de hoofdoorzaak van het type wacht. verbruik over een historische periode.