How to Configure SAP HANA Memory Limits on SUSE Linux Enterprise Server

SAP HANA memory control on SUSE Linux Enterprise Server works best when you separate two different jobs: limiting what HANA may allocate, and protecting SAP workloads when the Linux host is under memory pressure. SAP HANA handles the first job with database parameters such as global_allocation_limit and statement_memory_limit. SUSE's systemd/cgroup-based Workload Memory Protection handles the second with MemoryLow on SAP.slice. These mechanisms complement each other, but they are not interchangeable.

This guide uses SAP HANA Platform 2.0 SPS 08 documentation and current SUSE Linux Enterprise Server for SAP Applications guidance available in October 2026. Before changing a production system, confirm that your exact HANA revision and SLES service pack are supported. SAP's installation guide points administrators to SAP Note 2235581 for supported operating systems: SAP HANA Server Installation and Update Guide.

Which memory control should you use?

SAP documents global_allocation_limit in MB. With the parameter left at its default value of 0, HANA calculates an automatic limit based on available physical memory; the SPS 08 Administration Guide describes the current formula as 90% of the first 64 GB plus 97% of each additional GB, with special handling for very small systems. The same guide states that changing the parameter does not require a restart. See SAP HANA Administration Guide 2.0 SPS 08.

Step 1: Measure host memory before setting a limit

Start on SLES by checking physical RAM, available memory, swap activity, and whether SAP processes are already grouped in SAP.slice. This gives you the boundary conditions before you decide how much memory HANA may use.

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

Do not choose a HANA limit simply by subtracting a fixed number of gigabytes from installed RAM. Reserve memory for the Linux kernel, SAP Host Agent, monitoring software, backup tools, cluster components, and any co-located application servers. If ABAP and HANA share a host, SAP explicitly requires the sizing of both systems to fit within physical memory and recommends coordinating HANA's global allocation limit with the ABAP PHYS_MEMSIZE setting: SAP Configuring Memory Settings.

Step 2: Read the existing HANA memory parameters

Before changing anything, record the effective configuration. You can inspect M_INIFILE_CONTENTS from SAP HANA Database Explorer, Cockpit SQL console, or another authorized SQL client.

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;

The layer matters. In multi-tenant systems, system-level and database-level settings can have different scope. Do not copy a command from a single-container example without checking whether you are connected to SYSTEMDB or a tenant database and which layer you intend to change.

Step 3: Set the global HANA allocation limit

Use global_allocation_limit when the objective is to bound HANA's total allocation. A value such as 180000 means 180,000 MB; it is only an example, not a universal recommendation. The correct number must come from sizing, workload history, high-availability requirements, and the memory that must remain available to the operating system and other processes.

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

The advantage of a lower global limit is predictable headroom outside HANA. The cost is less room for column-store growth, caches, intermediate query results, and service overhead. If the host is dedicated to HANA, the automatic default may be appropriate after sizing validation. If the host is shared, an explicit limit is usually easier to reason about because every resident workload has a defined budget.

Step 4: Decide whether to limit individual SQL statements

statement_memory_limit controls the maximum memory allocation for a single statement and is expressed in GB. SAP documents the default as 0, meaning no statement-specific limit. A finite value is useful when ad-hoc analytical queries or poorly filtered joins can consume a large portion of the global pool.

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

Компромисс очевиден: более жесткий лимит защищает от параллельного выполнения, но может привести к прерыванию ресурсоемких запросов, допустимых для вашего бизнеса. SAP отмечает, что достижение лимита приводит к прерыванию запроса и может вызвать дамп памяти с compositelimit_oomопределенным именем. Подробности см. в разделе «Управление памятью» руководства по устранению неполадок и анализу производительности SAP HANA .

Шаг 5: Используйте пользовательские ограничения, если одно глобальное значение слишком грубое.

Ограничение на количество запросов в одном запросе просто в использовании, но оно рассматривает учетную запись ETL, используемую в течение ночи, так же, как и учетную запись пользователя для интерактивной отчетности. SAP поддерживает пользовательское ограничение STATEMENT MEMORY LIMIT, которое имеет приоритет над глобальным ограничением на количество запросов для этого пользователя.

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

Этот подход часто лучше, чем снижение глобального лимита для всех. Например, можно ограничить создание отчетов по запросу, оставив при этом больший лимит для пакетных или административных учетных записей. Недостаток заключается в управлении: исключения необходимо документировать, проверять и удалять, когда они больше не нужны. SAP также документирует ограничения для запросов между базами данных и некоторых сценариев XS Classic, где более подходящими могут быть классы рабочей нагрузки. См. SAP Настройка пользовательских параметров для рабочей нагрузки .

Шаг 6: Защитите память SAP в SUSE с помощью MemoryLow, а не второго жесткого ограничения.

В SLES для приложений SAP компания 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. Это различие важно, поскольку жесткое ограничение на уровне ОС может привести к иному режиму отказа, чем внутренние механизмы управления распределением памяти 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.slicecgroup. Это означает, что определение размера на уровне приложения по-прежнему имеет значение, даже если защита 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. Добавляйте ограничение на количество операторов только в том случае, если история рабочей нагрузки показывает, что отдельные операторы угрожают параллельному выполнению задач. Используйте SUSE, MemoryLowесли хотите защитить рабочую нагрузку SAP от нагрузки на память, не связанной с SAP, на хосте.

Сервер приложений HANA Plus на одном хосте

Используйте явно заданные бюджеты. Координируйте HANA global_allocation_limitс настройками памяти сервера приложений, например, с помощью параметров PHYS_MEMSIZE. Это менее гибко, чем позволить обеим сторонам свободно увеличивать объем памяти, но снижает риск того, что один компонент будет потреблять память, необходимую другому.

Смешанный аналитический подход с непредсказуемыми запросами, выполняемыми по мере необходимости.

Сочетайте разумное глобальное ограничение на выделение памяти с контролем на уровне отдельных запросов. Начинайте с данных, полученных из ресурсоемких запросов и пикового использования памяти, а не с произвольно малого числа. Ограничения для конкретных пользователей или классы рабочей нагрузки предпочтительнее, когда рискованные запросы генерируют только определенные пользователи или приложения.

Системы высокой доступности (HA) или кластерные системы HANA

Рассчитывайте объем памяти как в активном состоянии, так и в состоянии переключения. Вторичный узел, ставший основным, может нуждаться в значительно отличающемся объеме памяти от того, который он использует во время репликации в стационарном режиме. Рассматривайте отказоустойчивую архитектуру, кластерные агенты, стек мониторинга и любые размещенные совместно рабочие нагрузки как часть бюджета памяти, а не настраивайте каждый хост изолированно.

Распространенные ошибки, которых следует избегать

• Функция MemoryLow рассматривается как жесткое ограничение. Она защищает память, но не ограничивает HANA этим объемом.
• Установка параметра MemoryMax обусловлена ​​тем, что это звучит эквивалентно ограничению на выделение памяти в HANA. Однако семантика отличается, и жесткое ограничение, установленное операционной системой, может помешать управлению памятью в HANA.
• Использование одного и того же ограничения на объем памяти для всех пользователей без подтверждения рабочей нагрузки. Запрос на формирование отчета и операция технического обслуживания могут иметь совершенно разные допустимые потребности в памяти.
• В системах MDC игнорируется уровень конфигурации. Убедитесь, изменяете ли вы область действия SYSTEM, HOST или DATABASE, и на какую базу данных ориентирована ваша SQL-сессия.
• Примерные значения копируются в рабочую среду. Приведенные здесь значения 180 ГБ и 5 ГБ являются демонстрационными, а не рекомендациями по выбору объема памяти.
• Это не оставляет места для SUSE и вспомогательных сервисов. HANA — не единственный потребитель физической оперативной памяти.

Окончательная рекомендация

Используйте ограничения SAP HANA global_allocation_limitв качестве основного лимита памяти HANA, добавляйте их statement_memory_limitтолько тогда, когда необходимо контролировать риски отдельных запросов, и используйте политики для конкретных пользователей или классов рабочих нагрузок, когда разные рабочие нагрузки требуют разных ограничений. В SUSE Linux Enterprise Server для приложений SAP используйте это SAP.slice MemoryLowдля защиты рабочей нагрузки SAP от нагрузки на уровне хоста, а не пытайтесь дублировать лимит HANA с помощью жесткого ограничения cgroup.

Наиболее важный компромисс заключается в выборе между максимальной емкостью кэша/запросов HANA и достаточным запасом ресурсов хоста для поддержания работоспособности операционной системы и размещенных на ней сервисов. Окончательные расчеты следует основывать на размерах SAP и наблюдаемых пиковых нагрузках в производственной среде, а затем проверить работоспособность HANA и SLES после внесения изменений.