SQL Server 2016 出現奇怪的性能問題
我們有一個在 VMware 虛擬機中執行的 SQL Server 2016 SP1 實例。它包含 4 個數據庫，每個數據庫用於不同的應用程序。這些應用程序都位於不同的虛擬伺服器上。它們都還沒有投入生產使用。不過，測試應用程序的人正在報告性能問題。
這些是伺服器的統計資訊：
- 128 GB RAM（SQL Server 最大記憶體 110 GB）
- 4 核 @4.6 GHz
- 10 GBit 網路連接
- 所有儲存都是基於 SSD 的
- 程序文件、日誌文件、數據庫文件和 tempdb 位於伺服器的不同分區上
- asd
使用者通過基於 C++ 的 ERP 應用程序執行單屏訪問。
ostress當我使用 Microsoft使用許多小查詢或大查詢對 SQL Server 進行壓力測試時，我得到了最大的性能。唯一節流的是客戶端，因為他不能足夠快地回答。但是當幾乎沒有使用者時，SQL Server 幾乎沒有做任何事情。然而，人們必須永遠等待才能在應用程序中保存任何內容。
根據 Paul Randal 的“告訴我哪裡痛”查詢，所有等待事件中有 50% 是
ASYNC_NETWORK_IO.這可能意味著網路問題或應用程序伺服器或客戶端的性能問題。他們甚至都沒有以最大容量遠端使用他們的資源。大多數情況下，所有機器（客戶端、應用伺服器、數據庫伺服器）上的 CPU 大約為 26%。
網路連接延遲在 1-3ms 左右。在應用程序正常使用期間，數據庫伺服器的 IO 寫入速度最高為 20MB/s（平均為 7-9MB/s）。當我進行壓力測試時，我得到的最大速度約為 5GB/s。
我們的 ERP 系統數據庫的緩衝區記憶體大小為 60GB，我們的財務軟體為 20GB，質量保證軟體為 1GB，文件歸檔系統為 3GB。
我授予 SQL Server 帳戶使用Instant File Initialization的權利。這絲毫沒有提高性能。
在正常使用期間，頁面預期壽命約為 15k+。在重壓測試結束時下降到 0.05k 左右，這是意料之中的。批次/秒約為 2-8k，具體取決於工作量。
我會說 ERP 應用程序寫得不好，但我不能，因為所有應用程序都受到影響。即使在最小的工作量下。
但是我無法確定是什麼原因造成的。是否有任何提示、提示教程、應用程序、最佳/最差實踐文件或你們對這個問題有什麼想法？
這些是來自的結果
sp_BlitzFirst：
我跑了600秒。我是在應用程序的高工作量期間啟動它的。1/3 的時間是
ASYNC_NETWORK_IO.NTttcp我還用、PsPing、ipferf3和測試了網路連接pathping。沒有什麼不尋常的。響應時間最長為 3 毫秒，平均為 0.3 毫秒。吞吐量約為 1000 MB/s。我的調查總是導致
ASYNC_NETWORK_IO成為排名第一的waitstat。
Large-Receive-Offload我們調查了在 VMware中禁用該功能的結果。我們仍在測試，但結果似乎不一致。我們的第一個“基準”產生了 19 分鐘的持續時間（最高結果是 13 分鐘，只有當應用程序在帶有 SQL Server 本身的 VM 上執行時才能實現）。第二個結果是 28 分鐘，這真的很糟糕。我們的“基準”的第一個結果是 19 分鐘。哪個好。因為最高的結果是 13 分鐘（只有當應用程序在帶有 SQL Server 本身的 VM 上進行基準測試時才能實現）。這強烈暗示了一些與網路相關的問題。或者 VMware 配置有問題。
我目前不知道使用什麼方法來確定瓶頸。
只有當應用程序在帶有 SQL Server 本身的 VM 上執行時，才能實現應用程序的最大性能。如果應用程序在任何其他 VM 或虛擬桌面上執行，我們的基準測試的持續時間將增加三倍（從 13 分鐘持續時間到 40 分鐘或更長時間）。所有端點（SQL Server 的 VM、應用伺服器的 VM 和虛擬桌面）都使用相同的物理硬體。我們已將所有其他端點移至其他硬體。
編輯：似乎問題又回來了。在將節能模式從平衡設置為高性能後，我們實際上顯著提高了響應時間。但今天我再次執行 sp_BlitzFirst，樣本為 300 秒。這是結果：
它顯示 ASYNC_NETWORK_IO 的等待時間比 sp_blitzfirst 執行的秒數多。
回答我自己的問題： ASYNC_NETWORK_IO 作為頂級等待類型出現在我們的 SQL Server 上的主要原因是
energy savingWindows 伺服器的設置被設置為'balanced'而不是'high performance'. 之後我們與一些 vm ware 管理員進行了交談，他們都說，這個設置會影響性能。解決方案是：
- 安裝windows server時不要安裝能源控制
- 通過組策略將所有伺服器的節能模式設置為高性能
有關 ASYNC_NETWORK_IO 的所有其他問題/統計數據都與我們的 ERP 應用程序編寫不當有關。感謝所有幫助我解決這個問題的人，您的意見、建議和建議非常受歡迎和有幫助！
如果您的主要等待是
ASYNC_NETWORK_IO，則問題不在於 SQL Server。這幾乎總是由於應用程序瓶頸。我不是指應用程序伺服器上的瓶頸，而是應用程序中的瓶頸。應用程序瓶頸通常是由於 SQL Server 發送數據時的逐行處理：
- 應用程序正在從 SQL Server 請求數據
- SQL Server 正在快速發送數據
- 應用程序告訴 SQL Server 在處理每一行時等待
ASYNC_NETWORK_IOSQL Server在應用程序告訴它等待時記錄等待時間取而代之的是，應用程序需要使用 SQL Server 中的所有數據，然後進行逐行處理。那時 SQL Server 已經不存在了。
sp_BlitzFirst輸出
LCK_M_S等待並不高。30 秒的樣本只有 2 秒在上面，平均只有 400 毫秒。這是非常非常不可能的問題。ASYNC_NETWORK_IO是您在該樣本中的首要等待。還是應用問題。如果您需要有關這些LCK東西的幫助，我們需要查看所涉及的查詢。即使
ASYNC_NETWORK_IO在那個樣本中也沒有那麼糟糕。當等待時間等於或大於樣本量時，我的眼睛會變大。那是我探勘的時候。你的整個問題是
ASYNC_NETWORK_IO. 這不是 SQL Server 問題。這是應用程序（在 SQL Server 發送數據時進行逐行處理）、應用程序伺服器（您已經說過沒問題）或網路（您已經說過網路沒問題）的問題。所以問題出在應用程序上。C++ 應用程序需要修復。