除作業系統資源外，什麼會影響 Normal 或 Distributed AG 中的 log_send_rate？
我在分佈式 AG 設置中觀察到低 log_send_rate。我知道 AG 使用日誌流，所以我認為它不應該與數據有關，但我想知道這是否與它正在傳輸的數據有關，而不僅僅是作業系統資源（網路、I/O）？
供考慮的基本指標：
- SQL Server 2019-CU16
- 源 RAM 1.5 TB，48 個 CPU <> 目標 RAM 128 GB，48 個 CPU - 記憶體差異在這裡有什麼影響嗎？
- 兩台伺服器在同一個 DC，ping 延遲小於 1ms。目標伺服器是 VM。
- ROBOCOPY 測試顯示文件傳輸速率約為 100 MB/s
- 當高事務日誌生成活動（如索引維護或創建）被發送到其他副本時 - 它以最大 20 MB/s 的速率傳輸（這不是預期的）。這是 log_send_queue 堆積的時候。
- 另一邊的REDO率很好，沒有REDO隊列堆積在那裡。
在源 AG 上，我沒有看到“發送到傳輸/秒的字節數”計數器的任何內容，因此我無法確定這是否是瓶頸。
如果我錯過了我應該包括的任何內容，請提出建議。
Sean Gallardy 的文章是深入研究這一點的一個很好的資源：網路吞吐量歇斯底里
首先要確保您正在比較等效的事物。從文章：
我幾乎從未見過有人像 SQL Server 將其用於 AG 流量那樣測試他們的網路，正如我之前所說，每個數據庫副本一個執行緒。
Sean 建議使用ntttcp來測量單執行緒、單核網路吞吐量。這樣做會給你一個更好的基線來比較 20 MB/s。
如果仍然需要解釋一個非常大的差距，您可能需要更深入地研究延遲發生在過程中的確切位置。這是一篇來自 Microsoft 支持的優秀文章：
同步送出 AlwaysOn 可用性組之間的數據移動延遲故障排除
從圖中可以看出，將日誌塊傳輸和強化到輔助節點的過程中有很多步驟。放緩可能在其中的任何地方。該部落格文章末尾有一個免費工具的連結，該工具將為您分析擴展事件跟踪，僅供參考。
就您提供的數據而言：
從故障轉移的角度來看，目標上的記憶體差異並不理想（您的工作負載能否使用 1/12 的 RAM 有效執行？），但由於您沒有看到高 REDO 隊列，如果它有助於您看到的發送隊列堆積如山。
副本在同一個 DC 中是件好事——這樣就不太可能歸咎於整體網路延遲（您不是試圖複製到雲中，或者在世界的另一端）。
再一次，ROBOCOPY 測試可能不是一個很好的比較。
低 SQL Server 可用性組日誌發送率需要考慮的一些其他因素。
本文針對可能導致可用性組流控制和低於預期的日誌發送速率的許多情況提供了很好的描述和故障排除步驟。
如果可用性組是同步的，則預設禁用發送前壓縮（節省一點時間和一點 CPU，使用更多頻寬）。如果可用性組是非同步的，則預設啟用發送前壓縮（需要更多時間，使用更多 CPU 以減少頻寬需求）。對於給定的工作負載，折衷可能不會順利進行。跟踪標誌可用於在同步和非同步可用性組發送之前覆蓋預設的壓縮狀態。
對於 SQL Server 虛擬機，我總是建議增加網路適配器的 TCP 接收緩衝區。如果這是一個 VMware VM，我強烈推薦 vmxnet3 網路適配器。對於 VM 中的每個 vmxnet3 適配器，當參數“small rx buffers”和“rx ring #1 size”從預設值增加到最大值時，vm 內 vRAM 使用的淨差異小於 18 mb。（如果“Jumbo Packet”參數的值是“Standard 1500”或任何接近 1500 的值（如 1512），這些是要更改的參數。如果“Jumbo Packet”是 8000，則必須找到要修改的巨型數據包 TCP 接收參數。）在這種情況下在可用性組中，確保輔助伺服器上有足夠的 TCP 接收資源可以減少傳輸過程中由於封包遺失而導致的傳輸速度下降。
在 ESXi 中使用 VMXNET3 的來賓作業系統中出現大量封包遺失 (2039495)
確保電源計劃在可用性組的發送和接收端具有高性能。對於 VM 次要目標，可能需要在 VM 和主機級別進行驗證。對於較舊的處理器，如果插槽上少於一半的核心處於忙碌狀態，則插槽上的所有核心都可能會變慢（而不是像後來的處理器中那樣對單個核心進行功率調整）。當核心速度變慢時，網路適配器等其他組件也會變慢（甚至記憶體訪問時間也會因某些電源計劃實施而變慢）。
最後，雖然日誌發送速率低於預期，但對於該工作負載，它可能處於峰值。由於壓力，許多站點在可用性組中盡可能避免大型索引重建，而是專注於索引重組。