如何在 SUSE Linux Enterprise Server 上設定 SAP HANA 記憶體限制

在 SUSE Linux Enterprise Server 上，SAP HANA 記憶體控制的最佳運作方式是將兩個不同的任務分開：限制 HANA 可分配的內存，並在 Linux 主機記憶體壓力過大時保護 SAP 工作負載。 SAP HANA 透過資料庫參數（例如 `<database_parameters>` 和 `<database_parameters>`）來處理第一項任務global_allocation_limit。 SUSEstatement_memory_limit基於 systemd/cgroup 的工作負載記憶體保護機制則透過 `<database_parameters>` 來處理第二項任務MemoryLow。SAP.slice這些機制相輔相成，但不可互換。

本指南使用 SAP HANA Platform 2.0 SPS 08 文件以及截至 2026 年 10 月的最新 SUSE Linux Enterprise Server for SAP Applications 指南。在更改生產系統之前，請確認您的 HANA 版本和 SLES 服務包是否受支援。 SAP 安裝指南建議管理者參考 SAP Note 2235581，以了解支援的作業系統：SAP HANA Server 安裝和更新指南。

應該使用哪種記憶體控制方式？

SAP 文檔global_allocation_limit以 MB 為單位。如果此參數保持預設值 0，HANA 會根據可用實體記憶體自動運算限制；SPS 08 管理指南將目前運算公式描述為：前 64 GB 的 90%，加上每增加 1 GB 的 97%，並對非常小的系統進行特殊處理。該指南還指出，更改此參數無需重新啟動。請參閱SAP HANA 管理指南 2.0 SPS 08。

步驟 1：在設定限制之前測量主機記憶體。

首先在 SLES 上檢查實體記憶體、可用記憶體、交換活動以及 SAP 進程是否已分組SAP.slice。這樣可以確定 HANA 可以使用的記憶體大小的邊界條件。

free -h
grep MemTotal /proc/meminfo
systemctl status SAP.slice

不要簡單地從已安裝的 RAM 中減去固定的 GB 數來設定 HANA 記憶體限制。應為 Linux 核心、SAP Host Agent、監控軟體、備份工具、叢集元件以及任何位於相同位置的應用程式伺服器預留記憶體。如果 ABAP 和 HANA 共用相同主機，SAP 明確要求兩個系統的大小都必須符合實體記憶體的限制，並建議將 HANA 的全域分配限制與 ABAPPHYS_MEMSIZE設定協調一致：請參閱 SAP 設定記憶體設定。

步驟 2：讀取現有 HANA 記憶體參數

在進行任何變更之前，請記錄目前配置。您可以M_INIFILE_CONTENTS透過 SAP HANA 資料庫瀏覽器、Cockpit SQL 控制台或其他授權的 SQL 用戶端進行檢視。

SELECT FILE_NAME, SECTION, KEY, VALUE, LAYER_NAME
FROM M_INIFILE_CONTENTS
WHERE FILE_NAME = 'global.ini'
  AND SECTION = 'memorymanager'
  AND KEY IN ('global_allocation_limit',
              'statement_memory_limit',
              'statement_memory_limit_threshold')
ORDER BY KEY, LAYER_NAME;

層級很重要。在多租戶系統中，系統層級和資料庫層級設定的作用域可能不同。切勿在未確認連線的是 SYSTEMDB 還是租用戶資料庫，以及要變更的層級之前，直接從單容器範例複製指令。

步驟 3：設定全域 HANA 分配限制

當目標是限制 HANA 的總記憶體分配量時，可以使用此方法global_allocation_limit。例如，180000 表示 180,000 MB；這只是一個範例，並非通用建議。正確的數值必須根據容量規劃、工作負載歷史記錄、高可用性要求以及作業系統和其他進程必須使用的記憶體量來確定。

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('memorymanager', 'global_allocation_limit') = '180000'
WITH RECONFIGURE;

降低全域限制的優點在於，HANA 以外的資源餘裕是可預測的。但代價是列式儲存成長、快取、中間查詢結果和服務開銷的空間會減少。如果主機專用於 HANA，則在進行容量規劃驗證後，自動預設值可能就足夠了。如果主機是共享的，則明確設定限制通常更容易理解，因為每個駐留工作負載都有明確的預算。

步驟 4：決定是否要限制單一 SQL 語句

statement_memory_limit此參數控制單一語句的最大記憶體分配量，單位為 GB。 SAP 文件中預設值為 0，表示沒有語句特定的限制。當臨時分析查詢或過濾不充分的連接操作可能消耗大量全域記憶體池時，設定一個有限的值非常有用。

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('memorymanager', 'statement_memory_limit') = '5'
WITH RECONFIGURE;

這種權衡顯而易見：更嚴格的限制可以保護並發性，但可能會導致一些對您的業務至關重要的記憶體密集型語句被中止。 SAP 指出，達到限制後語句將被中止，並且可能會產生一個包含轉儲名稱的檔案。有關詳細信息，請參閱《SAP HANA 故障排除和效能分析指南》compositelimit_oom中的記憶體管理部分。

步驟 5：當全域值過於粗略時，使用使用者自訂的限制。

單一的報表限額操作簡便，但它將隔夜 ETL 帳戶與互動式報表使用者同等對待。 SAP 支援使用者專屬的報表限額STATEMENT MEMORY LIMIT，該限額優先於該使用者的全域報表限額。

ALTER USER REPORT_USER
SET PARAMETER STATEMENT MEMORY LIMIT = '2';

這種方法通常比降低所有人的全局限制更好。例如，您可以限制臨時報表的使用，同時為批次或管理帳戶保留更大的額度。缺點在於管理：例外情況必須記錄、審核，並在不再需要時清除。 SAP 還記錄了跨資料庫查詢和某些 XS Classic 場景的限制，在這些情況下，工作負載類別可能更合適。請參閱SAP 設定工作負載的使用者參數。

步驟 6：在 SUSE 系統上使用 MemoryLow 保護 SAP 內存，而不是設定第二個硬性限制。

在 SLES 上，SUSE 建議透過 systemd 和 cgroup v2 實現工作負載記憶體保護。 SAP 實例位於 [此處應填寫特定位置] SAP.slice，SUSE 表示，對於 SAP HANA，HANA 全域分配限制可以作為 [此處應填寫特定位置] 的基礎MemoryLow。

sudo systemctl set-property SAP.slice MemoryLow=180G
systemctl show SAP.slice -p MemoryLow

MemoryLow這是一個保護閾值：在記憶體壓力下，核心會嘗試為 cgroup 保護該閾值。它與 HANA 自身的記憶體分配器不同MemoryMax，也不會取代 HANA 自身的記憶體分配器。這種區別至關重要，因為作業系統層面的硬性記憶體限制可能會導致與 HANA 內部分配控制不同的故障模式。

SUSE 也警告不要將記憶體佔用設定MemoryLow得接近或超過實體記憶體總量，因為系統服務和其他已安裝的軟體也需要記憶體。最新的指導資訊請參閱《SUSE Workload Memory Protection for SLES for SAP 15 SP6》。

步驟 7：確認您沒有意外新增衝突的 cgroup 上限。

設定完成後MemoryLow，檢查相關的 systemd 屬性。如果您的設計並非有意使用MemoryHigh或MemoryMax，請確認它們並非由本地插件、自動化系統或無關的調優策略引入。

systemctl show SAP.slice | grep -E 'MemoryLow|MemoryHigh|MemoryMax'

對於由配置自動化管理的共享主機而言，這一點尤其重要。 SUSE 的工作負載記憶體保護旨在保護 SAP 免受受保護 cgroup 以外的工作負載的壓力；但當所有 SAP 系統或 SAP 實例共享相同記憶體時，它無法保護它們彼此免受影響SAP.slice。這意味著即使啟用了 cgroup 保護，應用程式層級的記憶體容量規劃仍然至關重要。

步驟 8：驗證 HANA 設定並觀察實際工作負載下的運作。

更改後重新查詢M_INIFILE_CONTENTS並確認預期層級和值。然後在正常負載和高峰負載期間監控系統。僅僅因為 SQL 語句執行無誤並不意味著配置成功。

SELECT FILE_NAME, SECTION, KEY, VALUE
FROM M_INIFILE_CONTENTS
WHERE FILE_NAME = 'global.ini'
  AND SECTION = 'memorymanager'
ORDER BY KEY;

密切注意記憶體不足事件、語句取消、持續記憶體壓力、交換以及工作負載延遲。如果原本可以順利完成的語句開始因記憶體限制錯誤而失敗，表示您設定的單一語句記憶體限制值可能過高。如果 Linux 系統記憶體餘裕極低，而 HANA 經常接近全域限制，則表示全域限制對於主機的整體工作負載而言可能過高。如果 HANA 的記憶體使用量遠低於限制值，但關鍵查詢卻出現溢位或中止，則表示限制值可能過低，或工作負載需要更有針對性的策略。

選擇適用於常見部署模式的策略

專用生產 HANA 主機

優先使用 HANA 本身的全域記憶體分配管理，並根據 SAP 的容量規劃預留足夠的作業系統記憶體空間。只有當工作負載歷史記錄顯示單一語句可能威脅並發性時，才會新增語句限制。MemoryLow如果您希望保護 SAP 工作負載免受主機上非 SAP 記憶體壓力的影響，請使用 SUSE。

HANA 和應用程式伺服器位於同一主機上

使用明確的記憶體預算。協調 HANAglobal_allocation_limit與應用程式伺服器的記憶體設置，例如PHYS_MEMSIZE。雖然這種方法不如允許雙方自由增長靈活，但它降低了一個元件佔用另一個元件所需記憶體的風險。

混合分析與不可預測的臨時查詢

將合理的全域記憶體分配限制與語句級控制結合。首先要參考高成本語句和峰值記憶體使用情況，而不是隨意設定一個很小的數值。如果只有特定使用者或應用程式會產生高風險查詢，則最好使用使用者特定的限製或工作負載分類。

HA 或叢集式 HANA 系統

確定活動狀態和接管狀態的記憶體大小。從輔助節點轉變為主節點所需的記憶體可能與穩定複製期間使用的記憶體有很大差異。應將故障轉移設計、叢集代理、監控堆疊以及任何位於相同位置的工作負載視為記憶體預算的一部分，而不是單獨配置每個主機。

避免的常見錯誤

• 將 MemoryLow 視為硬性上限。它用於保護內存，但不會將 HANA 的容量限制在該範圍內。
• 設定 MemoryMax 參數，是因為它聽起來像是 HANA 的記憶體分配限制。但實際上語意不同，作業系統設定的記憶體上限可能會幹擾 HANA 本身的記憶體管理。
• 對所有使用者使用相同的語句限制，卻沒有提供工作負載方面的證據。報表查詢和維護作業的合理記憶體需求可能截然不同。
• 忽略 MDC 系統中的配置層。請確認您變更的是 SYSTEM、HOST 還是 DATABASE 範圍，以及您的 SQL 會話指向哪個資料庫。
• 將範例資料複製到生產環境中。此處顯示的 180 GB 和 5 GB 值僅為範例值，並非容量建議。
• 這樣一來，SUSE及其支援服務就沒有盈餘了。 HANA並非唯一需要實體記憶體的廠商。

最終建議

使用 SAP HANAglobal_allocation_limit作為 HANA 記憶體的主要上限，statement_memory_limit僅在需要控制單一查詢風險時才新增上限，並在不同工作負載需要不同限制時使用使用者特定策略或工作負載類別策略。在 SUSE Linux Enterprise Server for SAP Applications 上，應使用SAP.slice MemoryLowcgroup 硬上限來保護 SAP 工作負載免受主機級壓力的影響，而不是嘗試使用 cgroup 硬上限來複製 HANA 限制。

最重要的權衡在於最大 HANA 快取/查詢容量與足夠的主機資源之間，以確保作業系統和主機服務的健康運作。最終數值應基於 SAP 容量規劃和觀察到的生產峰值，然後在變更後驗證 HANA 和 SLES 的運作情況。