Sql-Server

為系統帳戶鎖定記憶體頁面

  • May 24, 2019

是的,那麼從哪裡開始?如果您真的喜歡在 Microsoft Windows Server 上安裝和微調 Microsoft SQL Server 或 Oracle RDBMS 實例,那麼在某些時候您都會遇到***“…鎖定記憶體中的頁面”的建議。***.

鎖定記憶體中的頁面

為方便起見,這裡提供了相關文件的連結以及針對 Oracle RDBMS 和 Microsot SQL Server 描述的步驟。

微軟 SQL 伺服器 2017

  1. 在開始菜單上,點擊執行。在打開框中,鍵入 gpedit.msc。
  2. 在本地組策略編輯器控制台上,展開電腦配置,然後展開 Windows 設置。
  3. 展開安全設置,然後展開本地策略。
  4. 選擇使用者權限分配文件夾。

策略將顯示在詳細資訊窗格中。 5. 在窗格中,點兩下鎖定記憶體中的頁面。 6. 在本地安全設置 - 在記憶體中鎖定頁面對話框中,點擊添加使用者或組。 7. 在“選擇使用者、服務帳戶或組”對話框中,選擇 SQL Server 服務帳戶。 8. 重新啟動 SQL Server 服務以使此設置生效。

甲骨文關係數據庫 18c

  1. 開始菜單中,選擇控制面板

控制面板視窗打開。 2. 點兩下管理工具

“管理工具”視窗打開。 3. 點兩下本地安全策略。

本地安全策略視窗打開。 4. 在本地安全策略視窗的左窗格中,展開本地策略並選擇使用者權限分配。 5. 在 Local Security Policy 視窗的右窗格中,點兩下Lock pages in memory。將打開記憶體中的鎖定頁面屬性視窗。 6. 點擊添加使用者或組。“選擇使用者、電腦、服務帳戶或組”對話框打開。 7. 在Enter the object names to select欄位中輸入 Oracle Home User name,然後點擊Check Names。 8. 點擊“確定”關閉“選擇使用者、電腦、服務帳戶或組”對話框。 9. 點擊確定關閉記憶體中的鎖定頁面屬性視窗。

進一步閱讀

文件How to enable the “locked pages” feature in SQL Server 2012 (Microsoft Support) 指出:

強調我的)

基於 Windows 的應用程序可以使用 Windows AWE(地址視窗擴展)API 來分配物理記憶體並將其映射到程序地址空間。**使用此方法分配的記憶體永遠不會被作業系統調出並被鎖定,直到應用程序顯式釋放它或退出。**應用程序需要授予“Lock Pages In Memory”使用者權限 (LPIM) 才能使應用程序能夠鎖定記憶體中的頁面。

SQL Server 64 位版本使用“鎖定頁面”來防止程序工作集(已送出的記憶體)被作業系統換出或修剪。在 64 位 SQL Server 中使用 AWE API 進行記憶體管理也經常被稱為“鎖定頁面”。您可以結合使用 Windows 使用者權限、修補程序和跟踪標誌,在 SQL Server 版本 2005、2008 和 2008 R2 中啟用“鎖定頁面”功能。行為會有所不同,具體取決於這些版本中的 SQL Server 版本。

顯然,如果服務帳戶是Local System,則不需要設置。

在最近的 PASS 會議上參加我的一次演講的一些人問我以下問題:“如果我的 SQL Server 服務在本地系統帳戶下執行,我是否需要使用組策略編輯器來分配記憶體中的鎖定頁面權限?”。這個問題的答案是否定的,這就是為什麼。首先讓我解釋一下,這對於 64 位系統是如何工作的:

$$ long explanation $$ 所以在所有這些之後(但我希望你發現這些細節有幫助)回到最初的問題和我的結論。預設情況下,本地系統帳戶具有“鎖定記憶體頁”權限。對於使用者帳戶,您必須明確授予該帳戶此權限。

鮑勃·沃德,微軟

參考: 我是否必須為本地系統分配記憶體中的鎖定頁面權限?(微軟 | 開發 | CSS SQL Server 工程師)

問題

  1. 鑑於 Microsoft 伺服器(LOCAL SYSTEM?)將回收記憶體,如果作業系統受到壓力,SQL Server 和/或 Oracle(必須)是否會向系統釋放記憶體,因為服務在LOCAL SYSTEM帳戶下執行,即使鎖定頁面In Memory是隱式設置的?

如果1.問題的答案是:

,服務不會釋放記憶體,那麼我的下一個問題是:

  1. 這是因為 SQL Server OS / Oracle OS 已請求將頁面保存在記憶體中並且LOCAL SYSTEM將接受此請求嗎?

如果1.問題的答案是:

的,服務會釋放記憶體,那麼我的下一個問題是:

  1. 要顯式鎖定記憶體中的頁面,最好使用 Windows 帳戶執行服務並授予它們“**記憶體中的鎖定頁面”**權限,以便真正鎖定記憶體?

$$ With LPIM $$將 SQL Server$$ … $$向系統釋放記憶體

是的。SQL Server 偵聽來自 Windows 的記憶體不足通知,並自願修剪其記憶體作為響應。這個過程是自願和非同步的,不能保證其他程序不會有記憶體分配失敗。請參閱記憶體管理架構

使用 Windows 帳戶執行服務並授予它們記憶體中的鎖定頁面是否更好

此行為不取決於服務如何獲取 LPIM 權限,並且由於許多其他原因,您不應使用 LOCAL SYSTEM 作為您的 SQL Server 服務帳戶。

TL / 博士:

鑑於 Microsoft 伺服器(本地系統?)將回收記憶體,如果作業系統受到壓力,SQL Server 和/或 Oracle(必須)向系統釋放記憶體,因為服務在本地系統帳戶下執行,甚至雖然記憶體中的鎖定頁面是隱式設置的?

不知道,我不使用該LOCAL SYSTEM帳戶,您也不應該使用。

要顯式鎖定記憶體中的頁面,最好使用 Windows 帳戶執行服務並授予它們“記憶體中的鎖定頁面”權限,以便真正鎖定記憶體?

是的,使用 AD 帳戶,我強烈建議您查看Group Managed Service Accounts。他們最大限度地減少了管理成本。

更長的答案(但根據我的經驗,只有更多關於 LPIM 的資訊):

如果您還沒有偶然發現這篇文章,Great SQL Server Debates: Lock Pages in Memory by Jonathan Kehayias,我建議您閱讀一下。它更老了,但我仍然認為它是相當相關的,因為 Windows 如何徹底改變它的記憶體管理是 Windows 2008(例如在 Windows 2008 之前它很糟糕,但在它變得更好之後,在我厭倦的意見中)。

話雖如此,我啟用 LPIM 的環境仍然會被作業系統修剪並釋放記憶體,但它們不會像舊版本的 Windows 那樣釋放大量記憶體。我一次可能會看到 1 - 10 MB 的記憶體分配移動,但沒有什麼瘋狂的。不過這裡的關鍵是穩定作業系統上的記憶體使用,因此不經常發生修剪操作。Jonathan 的文章,我的 SQL Server 實際需要多少記憶體?很好地概述了應該分配多少 SQL 以及應該留給作業系統使用多少。我認為這個過程比文章中指出的更符合邏輯,所以根據需要進行微調。不過,這裡的重點是,如果您為作業系統保留了適當的數量,則修剪操作不應該經常發生。

在我看來,對於較新版本的 Windows(例如 Windows 2012 和 2016),不需要 LPIM,但它確實改變了 SQL Server 分配記憶體的方式,這可能會影響工作負載。正如Joe Obbish 指出的,一些工作負載可能會從 LPIM 中受益:

即使沒有分頁到磁碟,記憶體中的鎖定頁面也會對工​​作負載性能產生顯著影響。這一定是過於簡單化了,但是對於 LPIM,SQL Server 使用不同的作業系統呼叫來管理記憶體,並且這些呼叫的差異可能會導致使用和不使用 LPIM 的可伸縮性問題。例如,已經觀察到呼叫 HASHBYTES 的高並發工作負載可以通過 LPIM 獲得更好的吞吐量。

此外,在 Joe 在我當地的SQL 星期六發表的精彩會議中,他確實表明 LPIM 也可以有效地解決RESERVED_MEMORY_ALLOCATION_EXT某些工作負載的等待問題(幻燈片第 126 頁)。我不知道我是否會說在這裡啟用它是一種千篇一律的解決方案,因為我必須相信其他工作負載也有缺點。

最後,正如最初在 Jonahan 的Great SQL Server Debate論文中指出的那樣,無論是否啟用 LPIM,Windows 分配記憶體的方式都會有所不同。我看到的副產品是傳統的記憶體使用報告通常是不准確的。我經常與我的 VMWare 管理員發生爭執,因為他們不認為我的 SQL Server 服務正在使用所有分配的記憶體。我很想看到一些關於 LPIM 在報告記憶體使用情況方面的影響的正式文件,但這是我能想出的唯一解釋,為什麼他們的記憶體使用情況圖表與我自己的不匹配。

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