SUSE Linux Enterprise Server で SAP HANA のメモリ制限を設定する方法

SUSE Linux Enterprise Server 上の SAP HANA のメモリ制御は、HANA が割り当て可能なメモリ量を制限することと、Linux ホストのメモリ負荷が高い場合に SAP ワークロードを保護することという 2 つの異なるタスクを分離することで最も効果的に機能します。SAP HANA は、データベースパラメータ ( や など) を使用して最初のタスクを処理します。SUSEglobal_allocation_limitのsystemd/cgroup ベースのワークロード メモリ保護は、でstatement_memory_limit2 番目のタスクを処理します。これらのメカニズムは互いに補完し合いますが、互換性はありません。MemoryLowSAP.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管理ガイドでは、現在の計算式は最初の64GBの90%に、追加される各GBの97%を加えた値であり、非常に小規模なシステムの場合は特別な処理が行われると説明されています。同ガイドでは、パラメータを変更しても再起動は不要であるとも述べられています。SAP HANA管理ガイド2.0 SPS 08を参照してください。

ステップ1：制限を設定する前にホストメモリを測定する

SLES 上で、まず物理 RAM、利用可能なメモリ、スワップ アクティビティ、および SAP プロセスが既にグループ化されているかどうかを確認しますSAP.slice。これにより、HANA が使用できるメモリ量を決定する前に、境界条件を把握できます。

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

HANA の制限値を、インストールされている RAM から固定のギガバイト数を差し引くだけで決定しないでください。Linux カーネル、SAP Host Agent、監視ソフトウェア、バックアップツール、クラスタコンポーネント、および同じ場所に設置されているアプリケーションサーバー用にメモリを確保してください。ABAP と HANA がホストを共有する場合、SAP は両方のシステムのサイジングが物理メモリ内に収まるようにすることを明示的に要求しており、HANA のグローバル割り当て制限を ABAP のPHYS_MEMSIZE設定と調整することを推奨しています。SAPの「メモリ設定の構成」を参照してください。

ステップ2：既存のHANAメモリパラメータを読み込む

M_INIFILE_CONTENTS変更を加える前に、有効な構成を記録してください。SAP HANA Database Explorer、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,000MBを意味しますが、これはあくまで例であり、普遍的な推奨値ではありません。適切な値は、サイジング、ワークロード履歴、高可用性要件、およびオペレーティングシステムやその他のプロセスで利用可能にしておく必要のあるメモリ量に基づいて決定する必要があります。

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：グローバルな値が粗すぎる場合は、ユーザー固有の制限値を使用する

STATEMENT MEMORY LIMIT単一の明細制限は操作が簡単ですが、夜間ETLアカウントを対話型レポートユーザーと同じように扱います。SAPは、そのユーザーに対してグローバル明細制限よりも優先されるユーザー固有の制限をサポートしています。

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

この方法は、全員のグローバル制限を下げるよりも多くの場合優れています。たとえば、バッチアカウントや管理アカウントにはより大きな許容範囲を残しつつ、アドホックレポートを制限できます。欠点はガバナンスです。例外は文書化、レビューし、不要になったらクリアする必要があります。SAP では、データベース間クエリや特定の XS Classic シナリオにおける制限についても文書化しており、ワークロード クラスの方が適切な場合があります。「SAP ワークロードのユーザー パラメータの設定」を参照してください。

ステップ6：SUSE上のSAPメモリをMemoryLowで保護し、2つ目のハードキャップは使用しない。

SLES for SAP Applications では、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 の保護に利用します。これは とは異なりMemoryMax、HANA 独自の割り当て機能を置き換えるものでもありません。この違いは重要です。なぜなら、OS レベルのハードキャップは、HANA の内部割り当て制御とは異なる障害モードを引き起こす可能性があるからです。

SUSEは、システムサービスやその他のインストール済みソフトウェアもメモリを必要とするため、物理メモリの総容量に近い値またはそれを超える値を設定しないよう警告しています。最新のガイダンスについては、「SUSE Workload Memory Protection for SLES for SAP 15 SP6」MemoryLowを参照してください。

ステップ7：競合するcgroup capを誤って追加していないことを確認します。

を設定した後MemoryLow、関連する systemd プロパティを確認してください。設計でMemoryHighや を意図的に使用していない場合はMemoryMax、ローカルのドロップイン、自動化システム、または無関係なチューニング ポリシーによってそれらが導入されていないことを確認してください。

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

これは、構成自動化によって管理される共有ホストでは特に重要です。SUSEのワークロードメモリ保護は、保護対象のcgroup外のワークロードからの負荷からSAPを保護するように設計されています。ただし、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のサイジングに基づいて十分なOSの余裕を確保してください。ワークロード履歴から個々のステートメントが同時実行性を脅かすことが判明した場合にのみ、ステートメント制限を追加してください。SAPMemoryLowワークロードをホスト上の非SAPメモリ負荷から保護したい場合は、SUSEを使用してください。

1台のホスト上でHANAとアプリケーションサーバーが稼働

明確な予算を使用してください。HANAglobal_allocation_limitとアプリケーション サーバーのメモリ設定（例: ）を調整してくださいPHYS_MEMSIZE。これは、両方を自由に拡張させるよりも柔軟性は劣りますが、一方のコンポーネントが他方のコンポーネントに必要なメモリを消費してしまうリスクを軽減します。

予測不可能なアドホッククエリを用いた複合分析

適切なグローバル割り当て制限とステートメントレベルの制御を組み合わせる。恣意的な小さな数値ではなく、高負荷なステートメントやピーク時のメモリ使用量から判断を開始する。特定のユーザーまたはアプリケーションのみがリスクの高いクエリを生成する場合は、ユーザー固有の制限またはワークロードクラスが望ましい。

HAまたはクラスタ化されたHANAシステム

アクティブ状態とテイクオーバー状態の両方のサイズを適切に設定してください。セカンダリノードがプライマリノードになった場合、定常状態のレプリケーション時とは大きく異なるメモリが必要になる可能性があります。フェイルオーバー設計、クラスタエージェント、監視スタック、および同一場所に配置されたワークロードは、各ホストを個別に設定するのではなく、メモリ予算の一部として扱ってください。

避けるべきよくある間違い

• MemoryLowをハードキャップとして扱います。これはメモリを保護するものであり、HANAのメモリ使用量をその量に制限するものではありません。
• MemoryMaxを設定するのは、HANAのメモリ割り当て制限と同義のように聞こえるためです。しかし、意味論は異なり、OSのハードキャップはHANA独自のメモリ管理に干渉する可能性があります。
• ワークロードの証拠がないにもかかわらず、すべてのユーザーに同じステートメント制限を適用しています。レポートクエリとメンテナンス操作では、正当なメモリ要件が大きく異なる場合があります。
• MDCシステムでは構成レイヤーを無視します。変更するスコープがSYSTEM、HOST、またはDATABASEのいずれであるか、またSQLセッションがどのデータベースを対象としているかを確認してください。
• サンプル数値をそのまま製品にコピーします。ここに示されている180GBと5GBの値はあくまでも参考値であり、推奨サイズではありません。
• SUSEとサポートサービスのための余裕が全く残らない。物理RAMを消費するのはHANAだけではない。

最終勧告

SAP HANAglobal_allocation_limitのメモリ上限を HANA の主要な上限として使用し、statement_memory_limit個々のクエリのリスクを制御する必要がある場合にのみ追加し、異なるワークロードに異なる制限が必要な場合は、ユーザー固有またはワークロードクラスのポリシーを使用します。SUSE Linux Enterprise Server for SAP Applications では、SAP.slice MemoryLowcgroup のハードキャップで HANA の制限を複製しようとするのではなく、を使用してホストレベルの負荷から SAP ワークロードを保護します。

最も重要なトレードオフは、HANAのキャッシュ/クエリ容量の最大値と、オペレーティングシステムおよび併設サービスを正常に動作させるためのホストの余裕との間のバランスです。最終的な数値はSAPのサイジングと観測された本番環境のピークに基づいて決定し、変更後にHANAとSLESの両方を検証してください。