Sql-Server

網路問題後的可用性組集群記憶體問題。如何轉儲 HADR 日誌塊消息池?

  • January 17, 2019

我們有一個四節點可用性組,一個站點中有兩個節點,另一個數據中心有兩個異地節點。我注意到在每個 WAN 連接發生抖動的 WAN 問題之後,場外節點不斷斷開並重新連接(使用 AOAG 儀表板中的 AOAG 執行狀況),主伺服器的記憶體被“HADR 日誌塊消息池”消耗

SELECT  *
FROM    sys.dm_os_memory_clerks
ORDER   BY pages_kb DESC

類型:OBJECTSTORE_SERVICE_BROKER

名稱:HADR 日誌塊消息池

在最壞的情況下,當網路抖動幾個小時時,這個記憶體管理員最終會消耗超過 90% 的 SQL Server 記憶體,導致 SQL Server 停止執行(SQL 有 10GB 記憶體“HADR Log Block Msg Pool”正在使用 9.8GB)。

有沒有辦法轉儲這個 HADR 日誌塊消息池?還是首先阻止它變得如此之大?到目前為止,我們唯一的解決方案是故障轉移並重新啟動機器。

沒有錯誤,只有節點斷開連接和重新連接的日誌以及重新連接後重新硬化的數據庫的日誌。

隨著越來越多的記憶體被“HADR 日誌塊消息池”佔用,其他所有內容的可用記憶體都會下降,從而影響性能。通常,這 10GB 的 RAM 適合此 AOAG 組和使用情況。只有當 WAN 抖動一段時間時,我們才會遇到此問題。

我們可以在伺服器上投入更多記憶體,但我認為這不會解決根本問題,它只會在嚴重損害性能之前為我們爭取更多時間。

我同意網路是根本原因,但奇怪的是,在問題得到解決並且 AOAG 重新同步之後,SQL 不會像大多數 SQL 記憶體管理員那樣將 RAM 恢復/重新分配給其他 SQL 記憶體管理員。

日誌傳送不起作用;這是一個事務性環境,我們需要近乎實時的,最好是實時的異地 DR。AOAG 小組 99% 的時間都在工作,並且幾乎總是實時同步。我們正在嘗試與網路團隊合作以改善連接性,和/或可能使它只是斷開連接而不是擺動。

系統資訊

SQL 版本:SQL 2016 SP1 CU6 13.0.4457.0

作業系統版本:Windows 2012 R2 6.3.9600

伺服器記憶體:12GB

SQL 最大記憶體:10GB

可用性組配置資訊

AOAG 中有四個數據庫

AOAG 數據庫總共為 364GB

兩個本地節點處於同步模式,每個節點一票

兩個遠端節點處於非同步模式,零票

還有一個本地文件見證,一票.

我注意到,在每個 WAN 連接出現抖動的 WAN 問題之後,場外節點不斷斷開並重新連接,主伺服器的記憶體被“HADR 日誌塊消息池”消耗

是的,這是目前的設計。預計兩個站點之間的網路可以處理流量並且可用。由於看起來情況並非如此,因此 SQL Server 確實不是這裡的問題,而是表現為一個問題。如果您要繼續通過不可靠且可能具有極高延遲的低頻寬連接工作,那麼我不會使用可用性組。實際上,我不確定您要使用什麼,因為沒有任何東西具有穩固可靠的連接,這似乎是問題的根本原因

有沒有辦法轉儲這個 HADR 日誌塊消息池?

SQL Server 內部?不。

還是首先阻止它變得如此之大?

是的,解決連接問題,它不會增長。如果是長時間的連接問題,則從 AG 中刪除遠端副本,它將停止增長。由於有兩個遠端副本,數據將被發送兩次,這可能會加劇問題,因為在架構時可能沒有考慮到可用的基礎架構。

伺服器記憶體:12GB

對於 364 GB 的數據庫 + 作業系統 + 集群 + AG + 所有已安裝的防病毒和代理程序,這是一個非常小的伺服器記憶體。

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