Comment configurer les limites de mémoire SAP HANA sur un serveur SUSE Linux Enterprise ?

La gestion de la mémoire SAP HANA sur SUSE Linux Enterprise Server est optimale lorsqu'elle sépare deux tâches distinctes : limiter les ressources allouées par HANA et protéger les charges de travail SAP lorsque le système Linux hôte est soumis à une forte pression sur la mémoire. SAP HANA gère la première tâche à l'aide de paramètres de base de données tels que `<limits_mémoire_allouée>` global_allocation_limitet `<limits_mémoire_allouée>` statement_memory_limit. La protection de la mémoire des charges de travail (Workload Memory Protection) de SUSE, basée sur systemd/cgroup, gère la seconde avec `< MemoryLowlimits_mémoire_allouée SAP.slice>`. Ces mécanismes sont complémentaires, mais non interchangeables.

Ce guide utilise la documentation de SAP HANA Platform 2.0 SPS 08 et les recommandations actuelles pour SUSE Linux Enterprise Server for SAP Applications (disponibles en octobre 2026). Avant toute modification d'un système de production, assurez-vous que votre version exacte de HANA et votre Service Pack SLES sont compatibles. Le guide d'installation de SAP renvoie les administrateurs à la note SAP 2235581 pour connaître les systèmes d'exploitation pris en charge : Guide d'installation et de mise à jour de SAP HANA Server .

Quel contrôle de mémoire devez-vous utiliser ?

Les documents SAP global_allocation_limitsont exprimés en Mo. Si le paramètre conserve sa valeur par défaut de 0, HANA calcule une limite automatique en fonction de la mémoire physique disponible. Le guide d'administration SPS 08 décrit la formule actuelle comme suit : 90 % des 64 premiers Go, plus 97 % de chaque Go supplémentaire, avec un traitement spécifique pour les systèmes de très petite taille. Ce même guide précise que la modification de ce paramètre ne nécessite pas de redémarrage. Voir le guide d'administration SAP HANA 2.0 SPS 08 .

Étape 1 : Mesurer la mémoire hôte avant de définir une limite

Commencez par vérifier, sur SLES, la RAM physique, la mémoire disponible, l'activité du swap et si les processus SAP sont déjà regroupés SAP.slice. Cela vous donnera les conditions limites avant de décider de la quantité de mémoire que HANA peut utiliser.

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

Ne définissez pas la limite HANA en soustrayant simplement un nombre fixe de gigaoctets à la RAM installée. Prévoyez de la mémoire pour le noyau Linux, l'agent hôte SAP, les logiciels de surveillance, les outils de sauvegarde, les composants du cluster et les serveurs d'applications colocalisés. Si ABAP et HANA partagent un hôte, SAP exige explicitement que la taille des deux systèmes tienne dans la mémoire physique et recommande de coordonner la limite d'allocation globale de HANA avec le PHYS_MEMSIZEparamètre ABAP : Configuration des paramètres de mémoire SAP .

Étape 2 : Lire les paramètres de mémoire HANA existants

Avant toute modification, notez la configuration actuelle. Vous pouvez la consulter à l'aide M_INIFILE_CONTENTSde SAP HANA Database Explorer, de la console SQL Cockpit ou d'un autre client SQL autorisé.

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;

Le niveau de configuration est important. Dans les systèmes mutualisés, les paramètres système et les paramètres de base de données peuvent avoir une portée différente. Ne copiez pas une commande d'un exemple mono-conteneur sans vérifier si vous êtes connecté à SYSTEMDB ou à une base de données client et quel niveau vous souhaitez modifier.

Étape 3 : Définir la limite d’allocation globale HANA

Utilisez cette méthode global_allocation_limitlorsque l'objectif est de limiter l'allocation totale de HANA. Une valeur comme 180 000 correspond à 180 000 Mo ; il s'agit d'un exemple et non d'une recommandation universelle. La valeur appropriée dépend du dimensionnement, de l'historique de la charge de travail, des exigences de haute disponibilité et de la mémoire qui doit rester disponible pour le système d'exploitation et les autres processus.

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

L'avantage d'une limite globale plus basse est une marge de manœuvre prévisible en dehors de HANA. En contrepartie, la capacité disponible pour la croissance du stockage en colonnes, les caches, les résultats de requêtes intermédiaires et la surcharge du service est réduite. Si l'hôte est dédié à HANA, la valeur par défaut automatique peut convenir après validation du dimensionnement. Si l'hôte est partagé, une limite explicite est généralement plus facile à justifier, car chaque charge de travail résidente dispose d'un budget défini.

Étape 4 : Décider s’il faut limiter les requêtes SQL individuelles

statement_memory_limitCe paramètre contrôle la quantité maximale de mémoire allouée à une instruction et est exprimé en Go. SAP indique que la valeur par défaut est 0, ce qui signifie qu'il n'y a pas de limite spécifique à l'instruction. Une valeur finie est utile lorsque des requêtes analytiques ad hoc ou des jointures mal filtrées peuvent consommer une grande partie de la mémoire globale.

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

Le compromis est évident : une limite plus stricte préserve la concurrence, mais peut interrompre des requêtes gourmandes en mémoire pourtant essentielles à votre activité. SAP indique que l’atteinte de cette limite entraîne l’interruption de la requête et peut générer un vidage mémoire compositelimit_oom. Pour plus d’informations, consultez la section relative à la gestion de la mémoire du Guide de dépannage et d’analyse des performances de SAP HANA .

Étape 5 : Utilisez des limites spécifiques à l’utilisateur lorsqu’une valeur globale est trop grossière.

La limite d'instructions unique est simple à utiliser, mais elle traite un compte ETL de nuit de la même manière qu'un utilisateur de reporting interactif. SAP prend en charge une limite d'instructions spécifique à l'utilisateur STATEMENT MEMORY LIMIT, qui prime sur la limite d'instructions globale pour cet utilisateur.

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

Cette approche est souvent préférable à la réduction de la limite globale pour tous. Par exemple, vous pouvez limiter les rapports ad hoc tout en accordant une plus grande marge aux comptes de traitement par lots ou administratifs. L'inconvénient réside dans la gouvernance : les exceptions doivent être documentées, examinées et supprimées lorsqu'elles ne sont plus nécessaires. SAP documente également les limitations des requêtes inter-bases de données et de certains scénarios XS Classic, pour lesquels les classes de charge de travail peuvent s'avérer plus appropriées. Voir « Configuration des paramètres utilisateur pour la charge de travail dans SAP » .

Étape 6 : Protégez la mémoire SAP sur SUSE avec MemoryLow, et non avec une seconde limite matérielle.

Sur SLES pour applications SAP, SUSE recommande la protection de la mémoire de charge de travail via systemd et cgroup v2. Les instances SAP sont placées dans SAP.slice, et SUSE indique que pour SAP HANA, la limite d'allocation globale HANA peut être utilisée comme base pour MemoryLow.

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

MemoryLowIl s'agit d'un seuil de protection : en cas de forte sollicitation de la mémoire, le noyau tente de réserver cette quantité pour le cgroup. Ce seuil est différent de la MemoryMaxlimite de mémoire allouée et ne remplace pas l'allocateur interne de HANA. Cette distinction est importante car une limite stricte au niveau du système d'exploitation peut engendrer un mode de défaillance différent de celui des mécanismes de contrôle d'allocation internes de HANA.

SUSE recommande également de ne pas définir MemoryLowune valeur proche ou supérieure à la mémoire physique totale, car les services système et les autres logiciels installés consomment également de la mémoire. Les recommandations actuelles sont disponibles dans le document « Protection de la mémoire des charges de travail SUSE pour SLES pour SAP 15 SP6 » .

Étape 7 : Vérifiez que vous n’avez pas ajouté par erreur une limitation de cgroup conflictuelle.

Après avoir configuré les paramètres MemoryLow, examinez les propriétés systemd pertinentes. Si votre conception n'utilise pas intentionnellement `systemctl` MemoryHighou MemoryMax`systemctl`, vérifiez qu'elles n'ont pas été introduites par un module local, un système d'automatisation ou une politique de configuration sans rapport.

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

Ceci est particulièrement important sur les hôtes mutualisés gérés par l'automatisation de la configuration. La protection de la mémoire de charge de travail de SUSE est conçue pour protéger SAP contre la pression exercée par les charges de travail situées en dehors du cgroup protégé ; elle ne peut pas protéger les systèmes SAP ou les instances SAP les uns des autres lorsqu'ils partagent le même SAP.slicecgroup. Cela signifie que le dimensionnement au niveau de l'application reste important même lorsque la protection du cgroup est activée.

Étape 8 : Vérifiez les paramètres HANA et observez le comportement en conditions de charge réelle.

Après la modification, effectuez une nouvelle requête M_INIFILE_CONTENTSpour confirmer la couche et les valeurs souhaitées. Surveillez ensuite le système en période de charge normale et de pointe. Une configuration n'est pas réussie simplement parce que la requête SQL s'est exécutée sans erreur.

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

Surveillez les erreurs de mémoire insuffisante, les annulations d'instructions, la pression soutenue sur la mémoire, le pagination et la latence des charges de travail. Si des instructions qui s'exécutaient auparavant échouent désormais en raison d'erreurs de limite de mémoire, la valeur par instruction est peut-être trop restrictive. Si Linux dispose de très peu de marge de manœuvre tandis que HANA approche régulièrement la limite globale, cette dernière est peut-être trop élevée pour la charge de travail combinée de l'hôte. Si HANA reste bien en deçà de sa limite alors que des requêtes critiques débordent ou sont interrompues, la limite est peut-être trop basse ou la charge de travail nécessite une politique plus ciblée.

Choisir une politique pour les modèles de déploiement courants

Hôte HANA de production dédié

Privilégiez la gestion globale de l'allocation mémoire de HANA et prévoyez une marge suffisante au niveau du système d'exploitation en fonction du dimensionnement SAP. N'ajoutez une limite d'instructions que si l'historique de charge de travail indique que certaines instructions menacent la concurrence. Utilisez SUSE MemoryLowpour protéger la charge de travail SAP contre les pressions mémoire non liées à SAP sur l'hôte.

Serveur d'applications HANA plus sur un seul hôte

Utilisez des budgets explicites. Coordonnez HANA global_allocation_limitavec les paramètres de mémoire du serveur d'applications PHYS_MEMSIZE. Cette approche est moins flexible que de laisser les deux composants évoluer librement, mais elle réduit le risque qu'un composant consomme la mémoire nécessaire à l'autre.

Analyses mixtes avec des requêtes ad hoc imprévisibles

Combinez une limite d'allocation globale raisonnable avec des contrôles au niveau des instructions. Privilégiez les données issues des instructions coûteuses et des pics de consommation mémoire plutôt qu'une valeur arbitrairement basse. Des limites spécifiques à l'utilisateur ou des classes de charge de travail sont préférables lorsque seuls certains utilisateurs ou applications génèrent des requêtes à risque.

Systèmes HA ou HANA en cluster

Dimensionnez à la fois les états actif et de basculement. Un nœud secondaire devenu primaire peut nécessiter une mémoire sensiblement différente de celle utilisée en régime permanent. Intégrez la conception de basculement, les agents de cluster, la pile de surveillance et les charges de travail colocalisées dans le budget mémoire, plutôt que de configurer chaque hôte individuellement.

Erreurs courantes à éviter

• Le paramètre MemoryLow est considéré comme une limite stricte. Il protège la mémoire, mais ne limite pas HANA à cette quantité.
• Configurer MemoryMax peut sembler équivalent à la limite d'allocation de HANA. Or, la sémantique est différente, et une limite stricte du système d'exploitation peut interférer avec la gestion de la mémoire propre à HANA.
• Appliquer la même limite de requêtes à tous les utilisateurs sans tenir compte de la charge de travail est problématique. Une requête de génération de rapports et une opération de maintenance peuvent avoir des besoins en mémoire légitimes très différents.
• Ignorer la couche de configuration dans les systèmes MDC. Vérifiez si vous modifiez la portée SYSTEM, HOST ou DATABASE et quelle base de données votre session SQL cible.
• Copie des exemples de valeurs en production. Les valeurs de 180 Go et 5 Go affichées ici sont des exemples et ne constituent pas des recommandations de dimensionnement.
• Sans laisser de place à SUSE et aux services associés. HANA n'est pas le seul consommateur de RAM physique.

Recommandation finale

Utilisez la limite de mémoire de SAP HANA global_allocation_limitcomme limite principale, n'ajoutez de la mémoire statement_memory_limitque lorsque cela est nécessaire pour contrôler le risque lié à chaque requête, et appliquez des politiques spécifiques à l'utilisateur ou à la classe de charge de travail lorsque différentes charges de travail requièrent des limites différentes. Sur SUSE Linux Enterprise Server pour applications SAP, utilisez cette méthode SAP.slice MemoryLowpour protéger la charge de travail SAP contre la pression au niveau de l'hôte plutôt que de tenter de reproduire la limite de HANA avec une limite stricte de cgroup.

Le principal compromis réside dans l'équilibre entre la capacité maximale du cache/des requêtes HANA et la marge de manœuvre suffisante sur l'hôte pour garantir le bon fonctionnement du système d'exploitation et des services colocalisés. Basez les valeurs finales sur le dimensionnement SAP et les pics de production observés, puis vérifiez le fonctionnement de HANA et de SLES après la modification.