Sql-Server

即使“執行後忽略結果”也會導致 SELECT 語句執行延遲和高 ASYNC_NETWORK_IO

  • August 30, 2020

我們的 SQL Server 面臨性能問題。

7 台伺服器,都執行相同的應用程序,都有相同的問題。

SELECT @@VERSION
Microsoft SQL Server 2017 (RTM-CU19) (KB4535007) - 14.0.3281.6 (X64)   Jan 23 2020 21:00:04   Copyright (C) 2017 Microsoft Corporation  Standard Edition (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor) 

當您查看累積的總伺服器等待統計資訊時,顯示 99% ASYNC_NETWORK_IO。我們首先假設這是由應用程序引起的。然而:

當我們進行查詢(從應用程序擷取)並從 SSMS 中將其作為測試執行時,執行後忽略結果。我們在 TCP 連接上執行它大約需要 6 秒,在命名管道連接上執行它需要 50 秒。我們得到非常緩慢的結果。

(不考慮執行後的結果,查詢給出的結果為 57k 行 227 列,大小為 221MB。)

它是核心版,所以我們不能使用本地連接。我們測試了使用 TCP 和命名管道進行遠端連接。

通過 TCP

SQL Server parse and compile time: 
  CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
  CPU time = 4 ms, elapsed time = 4 ms.

(57844 rows affected)
Table 'STORE-CUW01$Item'. Scan count 1, logical reads 14774, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

SQL Server Execution Times:
  CPU time = 1359 ms,  elapsed time = 6868 ms.
SQL Server parse and compile time: 
  CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 0 ms.

在此處輸入圖像描述

因此,即使聚集索引掃描只需要 0.62 秒即可完成,但即使在執行檢查後忽略結果,仍需要 6.8 秒才能完成查詢

命名管道

SQL Server parse and compile time: 
  CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 0 ms.
SQL Server parse and compile time: 
  CPU time = 0 ms, elapsed time = 0 ms.

(57844 rows affected)
Table 'STORE-CUW01$Item'. Scan count 1, logical reads 14774, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

SQL Server Execution Times:
  CPU time = 1578 ms,  elapsed time = 54202 ms.
SQL Server parse and compile time: 
  CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:
  CPU time = 0 ms,  elapsed time = 0 ms.

在此處輸入圖像描述

使用命名管道,情況更糟。同樣,完成聚集索引掃描只需要半秒,而完成查詢則需要 54 秒。

如果我將數據庫恢復到我的筆記型電腦並執行相同的查詢,我將獲得 0.4 秒的聚集索引掃描和 1375 毫秒的 CPU 時間,以及 1462 毫秒的執行時間。

通過使用https://www.sqlskills.com/blogs/paul/capturing-wait-stats-for-a-single-operation/

我收集了 TCP 連接和命名管道連接的測試的等待統計資訊:

TCP

在此處輸入圖像描述

命名管道

在此處輸入圖像描述

等待的總時間不加起來。tcp 測試只有 0.472 秒的等待時間和 6.8 秒的執行時間,而 Naped Pipe 測試只有 40.7 秒的等待時間和 54.2 秒的執行時間。

更多相關資訊

  • SQL Server 是虛擬伺服器 VMware
  • 這是windows核心版
  • 4 種顏色
  • 64GB 記憶體,只有 16GB 分配給 SQL Server
  • 應用程序服務與 SQL Server 在同一台伺服器上執行
  • 應用程序本身與 MARS 會話連接

我們不明白時間延遲是從哪裡來的。如果您檢查了忽略結果,查詢不應該更快地完成嗎?

結果仍會使用丟棄結果選項返回給客戶端。丟棄結果的大ASYNC_NETWORK_IO等待時間表明返回 221MB 數據的網路延遲。我建議您將故障排除集中在網路而不是查詢計劃上。

嘗試一個簡單的測試,將一個 200MB 的文件從 SQL 機器複製到客戶端,看看是否得到相似的時間。

引用自:https://dba.stackexchange.com/questions/274649