河南省濮阳市建设局网站,做网站什么公司好,设计方案汇报,深圳福田商城网站建设文章目录 客户端应用程序出现问题网络问题 ASYNC_NETWORK_IO 是一种经常被DBA看到的等待类型#xff0c;当其数值过高时可能会让人担忧#xff0c;因为这是最难解决的等待类型之一。 需要知道的是#xff0c;从 SQL Server 2005 开始#xff0c;这种等待类型被命名为 ASYNC… 文章目录 客户端应用程序出现问题网络问题 ASYNC_NETWORK_IO 是一种经常被DBA看到的等待类型当其数值过高时可能会让人担忧因为这是最难解决的等待类型之一。 需要知道的是从 SQL Server 2005 开始这种等待类型被命名为 ASYNC_NETWORK_IO而在 SQL Server 2000 中这种等待类型称为 NETWORKIO。这一等待类型的原始名称源自 10M和 100 M慢速以太网速度的时代这些速度通常在 2000 年代中期之前广泛使用。 大多数情况下该等待类型的过高数值实际上与网路问题无关或这是一个非常罕见的情况尤其是在如今 40Gb、100Gb 的超高速以太网时代甚至目前正在开发的 200Gb 和 400Gb 速度的网络中。 ASYNC_NETWORK_IO 等待过高可能发生在以下两种情况下 客户端应用程序需要处理从 SQL Server 接收到的数据然后才能向 SQL Server 发送信号表示它可以接受新数据进行处理。这是一种常见的情况通常反映出应用程序设计不佳这也是导致 ASYNC_NETWORK_IO 等待过高的最常见原因。网路带宽已达到极限。一个拥堵的以太网将导致应用程序之间数据传输变慢从而降低应用程序的效率。
客户端应用程序出现问题
SQL Server 中 ASYNC_NETWORK_IO 等待类型过高的最常见原因是应用程序无法快速处理从 SQL Server 接收的数据。当应用程序请求大量数据结果集时缓慢的数据处理会导致数据缓冲区被填满从而阻止 SQL Server 向客户端发送新数据。「逐行痛苦处理」Row by Agonizing Row简称 RBAR往往是导致此类行为和高 ASYNC_NETWORK_IO 等待类型的原因。在 RBAR 应用程序编程中每次只处理 SQL Server 发送的结果集中一行数据。在这种情况下可处理的完整结果集会被缓存然后通知 SQL Server 该数据集已经「处理完毕」。这将允许 SQL Server 在应用程序处理缓存的结果集数据时发送新的数据集。
当使用 RBAR 处理的应用程序必须处理非常大的数据库环境 (VLDB) 时往往会遇到数据处理问题。执行批处理的伺服器进程SPID将被迫等待直到应用程序开始处理缓冲区中的数据这样 SQL Server 才能通过缓冲区将新的结果集发送到客户端。在等待将应用程序请求的新数据发送到缓冲区进行进一步处理的过程中会产生 ASYNC_NETWORK_IO 等待类型。 当 SQL Server 上出现高 ASYNC_NETWORK_IO 等待类型值时DBA 应该调查导致过高 ASYNC_NETWORK_IO 等待类型值的应用程序通常还需要与开发该应用程序的开发人员进行协调。在调查高 ASYNC_NETWORK_IO 等待类型值时应检查以下内容
检查应用程序是否请求了来自 SQL Server 实例的大量数据集然后在客户端对这些数据进行过滤。特别要留意诸如 Microsoft Access 或 ORM 软件对象关系映射之类的第三方应用程序它们可能请求了大量数据集并在客户端进行过滤。使用“立即读取之后处理”的编程方法通常可以避免出现过高的 ASYNC_NETWORK_IO 等待类型值。确保为客户端应用程序创建了适当的视图以确保数据过滤在 SQL Server 实例上完成从而显著减少传输到客户端应用程序的数据量。确保应用程序正在提交已打开的事务并且及时提交它们。检查是否可以通过直接在 SQL Server 上进行数据过滤来减少请求的数据集。对于个别或临时查询确保尽可能添加 WHERE 子句并适当优化查询以限制请求的数据集只包含所需的数据。 检查是否可以在查询中使用“TOP n”以减少查询返回的行数。 标量值用户定义函数UDF由于逐行处理RBAR通常是导致高 ASYNC_NETWORK_IO 等待类型的原因因此要查找这些影响性能的对象实例。 使用带有用户定义函数UDF的计算列并在大数据库中使用通常也是由于 RBAR 导致高 ASYNC_NETWORK_IO 等待类型的原因。 在 SQL Server 2016 中可以使用本机编译的 UDF(用户自定义函数)通常可以显著减少 RBAR 并将执行速度提高多达 100%。这在无法将 UDF 重构为table-valued(表值)函数的情况下特别有用。 注意 SQL Server Management Studio (SSMS) 是一个恶名昭彰的客户端应用程式因为它会产生大量ASYNC_NETWORK_IO 等待类型。SSMS 以逐行的方式读取资料流并在处理每一行后才检索下一行。
此外当在处理 SQL Server 上的大量数据加载过程中遇到过度的 ASYNC_NETWORK_IO 等待时也可以通过直接调整 SQL Server 来进行一些其他操作
如果尚未启用为该 SQL Server 实例启用 Shared memory protocol 。 使用以下查询来确定当前连接使用的协议
SELECT net_transport
FROM sys.dm_exec_connections
WHERE session_id SPID;確保客戶端使用 net_transport‘Shared memory’ 進行連接。
如果以上所有检查都完成但 SQL Server 仍然受到高 ASYNC_NETWORK_IO 等待值的影响那么就该检查可能导致这种行为的网络相关问题了。这些问题通常由物理网络的限制、故障或仅仅是错误的网络设置引起。为了排除网络引起的 ASYNC_NETWORK_IO 等待应仔细检查以下内容。
网络问题
检查 SQL Server 和客户端之间的网络带宽。网络适配器速度慢且带宽与客户端应处理的数据量不匹配通常是造成高 ASYNC_NETWORK_IO 等待值的常见原因。100 兆位的适配器仍然存在并且通常无法满足现代 SQL Server 数据库和处理数据的需求。即使切换到 1 千兆位适配器对于许多环境来说系统仍然达不到当前的要求。使用 10 千兆位网络适配器被认为是大多数环境的最低标准而 200 千兆位和 400 千兆位是许多企业在不久的将来必须切换的标准如果他们还没有这么做的话。检查每秒批量请求Batch requests per second的计数器值因为这通常可以表明高 ASYNC_NETWORK_IO 等待的原因。在检查批量请求时需要检查的是 SQL Server 处理的 T-SQL 批量数量因为这将决定 SQL Server 每秒处理的批量数量。每秒批量请求值超过 1000 的服务器被认为是“繁忙”的。建议的值会依赖于实际的系统配置、活动水平和处理的事务数量。在高峰时段这个值显著增加并不罕见。 当每秒批量请求Batch requests per second的计数器值接近或超过 3,000 并且使用的是 100 兆位网络时这几乎可以肯定地表明网络速度是瓶颈并导致高 ASYNC_NETWORK_IO 等待值。如今的服务器每秒轻松处理超过 20,000 批量请求因此考虑将 1 千兆位或更低的网络升级到 10 千兆位以满足 SQL Server 数据处理日益增长的需求是明智的选择。检查网卡NIC带宽利用率是明智的但经常被忽视。 使用 Perfmon 工具可以通过以下公式轻松计算网络利用率 Network utilization % ((Total Bytes\Sec * 8)/current bandwidth) * 100 如果利用率的数值经常超过 60%那么建议切换到更快的网卡或提高网络带宽以确保在需要时能够分配足够的带宽来进行数据处理。确保网卡的自动协商功能正确检测到网络带宽。 要检查所有活动网络连接的当前速度可以使用以下命令行命令。 Get-WmiObject -namespace root\cimv2 -query select * from Win32_NetworkAdapter| Where-Object { $_.NetEnabled -eq $true } | Select-Object Name, Speedoutput:
Name Speed
---- -----
Hyper-V Virtual Ethernet Adapter 10000000000
Realtek PCIe GBE Family Controller 1000000000
Npcap Loopback Adapter 1215752192
Microsoft KM-TEST Loopback Adapter 1215752192
Hyper-V Virtual Ethernet Adapter #2 10000000000
Hyper-V Virtual Ethernet Adapter #3 10000000000
Hyper-V Virtual Ethernet Adapter #4 10000000000
VirtualBox Host-Only Ethernet Adapter 1000000000
Hyper-V Virtual Ethernet Adapter #5 10000000000如果特定适配器的自动协商未选择正确的网络速度则可以在 NIS 属性中手动设置 NIC 速度
