Už jste tento typ čekání viděli, že? No, je to určitě typ čekání, který způsobil spoustu zmatků. Bezprostřední pozornost je obecně věnována slovu „SÍŤ“, ale vícekrát to nemá se sítí nic společného!
Typ čekání ASYNC_NETWORK_IO obvykle způsobí dva typy příznaků, prvním je pracovní zátěž relace čeká na odpovídající klientskou aplikaci, aby potvrdila/zpracovala danou sadu dat a dala SQL Server vědět, že je připraven zpracovat/potvrdit další data. Druhým příznakem je, že může existovat problém s výkonem v síti mezi aplikací a instancí databáze. V zákulisí SQL Server uchovává data ve výstupní vyrovnávací paměti, dokud klient neobdrží potvrzení, které určí, zda je spotřeba dat kompletní. ASYNC_NETWORK_IO je signálem, že aplikace postrádá efektivitu při čtení dat, která vyžaduje ze své backendové databáze. Základní síť může mít také problémy, které mohou způsobit delší čekání na zpracování dat a signály jsou odesílány z klienta zpět na server.
Mezi možné příčiny tohoto čekání patří:
- Kód aplikace nenačítá data správně
- Velké datové sady požadované klientem
- Nadměrné filtrování dat na straně klienta nebo aplikace
- Špatně nakonfigurovaná síťová zařízení, jako jsou karty, přepínače atd.
Na vysoké úrovni může DBA chtít zkontrolovat tyto věci:
- Zkontrolujte kód aplikace a ujistěte se, že aplikace čte data správně/efektivně. Stahuje vaše aplikace například velký počet řádků, aby zpracovala pouze jeden řádek najednou?
- Zbytečné filtrování dat na straně klienta/aplikace? Omezte počet řádků.
Pokud jsou výše uvedené položky zkontrolovány, ale problémy s ASYNC_NETWORK_IO přetrvávají, může to být způsobeno sítí. Zde je několik věcí, na které se můžete podívat:
- Zkontrolujte síťové komunikační spojení mezi aplikací a instancí backendové databáze a ověřte šířku pásma.
- Pomocí sys.dm_io_virtual_file_stats otestujte síť na obecnou latenci v důsledku zatížení nebo vzdálenosti
- Zkontrolujte konfiguraci NIC na databázovém serveru a ujistěte se, že nechybí žádné chyby nebo nastavení.
ASYNC_NETWORK_IO WAIT TYPE může skutečně souviset se sítí, ale často může být způsobeno klientskou aplikací, která nezpracovává svá data efektivně. Pokud tomu tak skutečně je, pak je to příležitost pro DBAS a vývojáře spolupracovat, aby pochopili, co aplikace skutečně potřebuje v nejlepším zájmu výkonu back-end databáze. Zajištění toho, že většina filtrování dat se provádí na serveru SQL Server, je osvědčeným postupem, kterého lze dosáhnout prostřednictvím zobrazení nebo konkrétnějších podmínek v syntaxi transakce.
Přestože existuje mnoho způsobů, jak monitorovat a měřit čekání ASYNC_NETWORK_IO pomocí katalogizovaných DMV a Extended Events na SQL Server, doporučujeme naší komunitě SQL Server DBA, aby se podívala na Quest's Spotlight Cloud, který poskytuje efektivitu při určování hlavní příčiny typu čekání. spotřeba za historické časové období.