Come configurare i limiti di memoria di SAP HANA su SUSE Linux Enterprise Server

Il controllo della memoria di SAP HANA su SUSE Linux Enterprise Server funziona al meglio quando si separano due compiti distinti: limitare la quantità di memoria che HANA può allocare e proteggere i carichi di lavoro SAP quando l'host Linux è sotto pressione per quanto riguarda la memoria. SAP HANA gestisce il primo compito con parametri del database come global_allocation_limite statement_memory_limit. La protezione della memoria dei carichi di lavoro basata su systemd/cgroup di SUSE gestisce il secondo con MemoryLowsu SAP.slice. Questi meccanismi si completano a vicenda, ma non sono intercambiabili.

Questa guida utilizza la documentazione di SAP HANA Platform 2.0 SPS 08 e le linee guida aggiornate di SUSE Linux Enterprise Server per applicazioni SAP, disponibili a ottobre 2026. Prima di modificare un sistema di produzione, verificare che la revisione di HANA e il service pack SLES in uso siano supportati. La guida all'installazione di SAP rimanda gli amministratori alla nota SAP 2235581 per i sistemi operativi supportati: Guida all'installazione e all'aggiornamento di SAP HANA Server .

Quale controllo della memoria dovresti utilizzare?

I documenti SAP global_allocation_limitsono espressi in MB. Lasciando il parametro al valore predefinito di 0, HANA calcola automaticamente un limite in base alla memoria fisica disponibile; la Guida di amministrazione di SPS 08 descrive la formula corrente come il 90% dei primi 64 GB più il 97% di ogni GB aggiuntivo, con una gestione speciale per i sistemi di dimensioni molto ridotte. La stessa guida afferma che la modifica del parametro non richiede un riavvio. Vedere la Guida di amministrazione di SAP HANA 2.0 SPS 08 .

Passaggio 1: Misurare la memoria host prima di impostare un limite

Iniziate con SLES verificando la RAM fisica, la memoria disponibile, l'attività di swap e se i processi SAP sono già raggruppati SAP.slice. Questo vi fornisce le condizioni limite prima di decidere quanta memoria può utilizzare HANA.

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

Non impostare un limite HANA semplicemente sottraendo un numero fisso di gigabyte dalla RAM installata. Riservare memoria per il kernel Linux, SAP Host Agent, il software di monitoraggio, gli strumenti di backup, i componenti del cluster e gli eventuali server applicativi co-ubicati. Se ABAP e HANA condividono un host, SAP richiede esplicitamente che il dimensionamento di entrambi i sistemi rientri nella memoria fisica e raccomanda di coordinare il limite di allocazione globale di HANA con l' PHYS_MEMSIZEimpostazione ABAP: Configurazione delle impostazioni di memoria SAP .

Passaggio 2: Leggere i parametri di memoria HANA esistenti

Prima di apportare qualsiasi modifica, registrate la configurazione effettiva. Potete verificarla M_INIFILE_CONTENTStramite SAP HANA Database Explorer, la console SQL di Cockpit o un altro client SQL autorizzato.

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;

Il livello è importante. Nei sistemi multi-tenant, le impostazioni a livello di sistema e a livello di database possono avere ambiti diversi. Non copiare un comando da un esempio per un singolo container senza prima verificare se sei connesso a SYSTEMDB o a un database tenant e quale livello intendi modificare.

Passaggio 3: Impostare il limite di allocazione globale di HANA

Da utilizzare global_allocation_limitquando l'obiettivo è quello di definire un limite all'allocazione totale di HANA. Un valore come 180000 significa 180.000 MB; si tratta solo di un esempio, non di una raccomandazione universale. Il valore corretto deve essere determinato in base al dimensionamento, alla cronologia dei carichi di lavoro, ai requisiti di alta disponibilità e alla memoria che deve rimanere disponibile per il sistema operativo e gli altri processi.

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

Il vantaggio di un limite globale inferiore è la prevedibilità del margine di sicurezza al di fuori di HANA. Il costo è rappresentato da una minore disponibilità di spazio per la crescita del column-store, delle cache, dei risultati intermedi delle query e dell'overhead dei servizi. Se l'host è dedicato a HANA, il valore predefinito automatico potrebbe essere appropriato dopo la convalida delle dimensioni. Se l'host è condiviso, un limite esplicito è solitamente più facile da gestire perché ogni carico di lavoro residente ha un budget definito.

Passaggio 4: Decidere se limitare le singole istruzioni SQL

statement_memory_limitControlla l'allocazione massima di memoria per una singola istruzione ed è espressa in GB. SAP documenta il valore predefinito come 0, il che significa che non esiste un limite specifico per istruzione. Un valore finito è utile quando query analitiche ad hoc o join con filtri inadeguati possono consumare una grande porzione del pool globale.

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

Il compromesso è diretto: un limite più restrittivo protegge la concorrenza, ma può interrompere istruzioni che richiedono molta memoria e che sono valide per la tua attività. SAP fa notare che il raggiungimento del limite interrompe l'istruzione e può generare un dump con un errore compositelimit_oomnel nome. Per ulteriori dettagli, consultare la sezione sulla gestione della memoria della Guida alla risoluzione dei problemi e all'analisi delle prestazioni di SAP HANA .

Passaggio 5: Utilizzare limiti specifici dell'utente quando un valore globale è troppo approssimativo

Un limite per singola istruzione è semplice da gestire, ma tratta un account ETL overnight allo stesso modo di un utente di reporting interattivo. SAP supporta un limite specifico per l'utente STATEMENT MEMORY LIMITche ha la precedenza sul limite globale per le istruzioni per quell'utente.

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

Questo approccio è spesso preferibile rispetto all'abbassamento del limite globale per tutti. Ad esempio, è possibile limitare la creazione di report ad hoc, lasciando al contempo una maggiore capacità agli account batch o amministrativi. Lo svantaggio risiede nella gestione: le eccezioni devono essere documentate, esaminate e cancellate quando non sono più necessarie. SAP documenta anche le limitazioni per le query tra database e per alcuni scenari XS Classic, dove le classi di carico di lavoro potrebbero essere più appropriate. Vedere la documentazione SAP sull'impostazione dei parametri utente per il carico di lavoro .

Passaggio 6: Proteggere la memoria SAP su SUSE con MemoryLow, non con un secondo limite massimo.

Su SLES per applicazioni SAP, SUSE raccomanda la protezione della memoria del carico di lavoro tramite systemd e cgroup v2. Le istanze SAP vengono posizionate in SAP.slicee SUSE afferma che per SAP HANA il limite di allocazione globale di HANA può essere utilizzato come base per MemoryLow.

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

MemoryLowè una soglia di protezione: in caso di pressione sulla memoria, il kernel tenta di proteggere tale quantità per il cgroup. Non è la stessa cosa di MemoryMax, e non sostituisce l'allocatore interno di HANA. Questa distinzione è importante perché un limite rigido a livello di sistema operativo può creare una modalità di errore diversa dai controlli di allocazione interni di HANA.

SUSE avverte inoltre di non impostare MemoryLowun valore vicino o superiore alla memoria fisica totale, poiché anche i servizi di sistema e gli altri software installati necessitano di memoria. Le linee guida aggiornate sono disponibili in SUSE Workload Memory Protection for SLES for SAP 15 SP6 .

Passaggio 7: Verificare di non aver aggiunto accidentalmente un limite cgroup in conflitto

Dopo aver impostato MemoryLow, ispeziona le proprietà systemd pertinenti. Se il tuo progetto non utilizza intenzionalmente MemoryHigho MemoryMax, verifica che non siano stati introdotti da un componente aggiuntivo locale, da un sistema di automazione o da una policy di ottimizzazione non correlata.

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

Questo è particolarmente importante sugli host condivisi gestiti tramite automazione della configurazione. La protezione della memoria del carico di lavoro di SUSE è progettata per proteggere SAP dalla pressione dei carichi di lavoro esterni al cgroup protetto; non può proteggere i sistemi SAP o le istanze SAP l'una dall'altra quando condividono tutti lo stesso SAP.slicecgroup. Ciò significa che il dimensionamento a livello di applicazione rimane importante anche quando la protezione del cgroup è abilitata.

Passaggio 8: Verificare le impostazioni di HANA e monitorare il comportamento sotto carico di lavoro reale.

Eseguire nuovamente la query M_INIFILE_CONTENTSdopo la modifica e confermare il livello e i valori desiderati. Quindi monitorare il sistema durante il normale e il picco di carico di lavoro. Una configurazione non è considerata corretta solo perché l'istruzione SQL è stata eseguita senza errori.

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

Presta attenzione agli eventi di memoria insufficiente, alle cancellazioni delle istruzioni, alla pressione prolungata sulla memoria, allo swapping e alla latenza del carico di lavoro. Se le istruzioni che prima venivano completate correttamente iniziano a fallire con errori di limite di memoria, il valore per istruzione potrebbe essere troppo restrittivo. Se Linux ha un margine di sicurezza molto limitato mentre HANA si avvicina regolarmente al limite globale, il limite globale potrebbe essere troppo elevato per il carico di lavoro combinato dell'host. Se HANA rimane ben al di sotto del suo limite mentre le query critiche vengono sovrascritte o interrotte, il limite potrebbe essere troppo basso oppure il carico di lavoro potrebbe richiedere una policy più mirata.

Scelta di una politica per modelli di implementazione comuni

Host HANA dedicato alla produzione

Privilegiate la gestione dell'allocazione globale di HANA e lasciate un margine sufficiente per il sistema operativo in base al dimensionamento SAP. Aggiungete un limite di istruzioni solo se la cronologia del carico di lavoro mostra che le singole istruzioni minacciano la concorrenza. Utilizzate SUSE MemoryLowquando desiderate proteggere il carico di lavoro SAP dalla pressione sulla memoria non SAP dell'host.

Server applicativo HANA+ su un unico host

Utilizzare budget espliciti. Coordinare HANA global_allocation_limitcon le impostazioni di memoria del server applicativo, ad esempio PHYS_MEMSIZE. Questo approccio è meno flessibile rispetto a lasciare che entrambe le parti crescano liberamente, ma riduce il rischio che un componente consumi memoria necessaria all'altro.

Analisi miste con query ad hoc imprevedibili

Combina un limite di allocazione globale ragionevole con controlli a livello di istruzione. Parti dalle evidenze derivanti da istruzioni onerose e dal picco di utilizzo della memoria, piuttosto che da un numero arbitrariamente piccolo. I limiti specifici per utente o le classi di carico di lavoro sono preferibili quando solo determinati utenti o applicazioni generano query rischiose.

Sistemi HA o HANA in cluster

Dimensionare sia lo stato attivo che quello di subentro. Un nodo secondario che diventa primario potrebbe richiedere una quantità di memoria sostanzialmente diversa da quella utilizzata durante la replica a regime. Considerare la progettazione del failover, gli agenti del cluster, lo stack di monitoraggio e qualsiasi carico di lavoro co-ubicato come parte del budget di memoria, anziché configurare ciascun host in modo isolato.

Errori comuni da evitare

• MemoryLow viene considerato come un limite massimo rigido. Protegge la memoria, ma non limita HANA a tale quantità.
• Impostare MemoryMax perché sembra equivalente al limite di allocazione di HANA. La semantica è diversa e un limite rigido del sistema operativo può interferire con la gestione della memoria di HANA.
• Utilizzare lo stesso limite di istruzioni per ogni utente senza prove del carico di lavoro. Una query di reporting e un'operazione di manutenzione possono avere esigenze di memoria legittime molto diverse.
• Ignorare il livello di configurazione nei sistemi MDC. Verificare se si sta modificando l'ambito SYSTEM, HOST o DATABASE e a quale database è destinata la sessione SQL.
• Copia dei valori di esempio nell'ambiente di produzione. I valori di 180 GB e 5 GB mostrati qui sono valori dimostrativi e non raccomandazioni di dimensionamento.
• Non lasciando alcun margine per SUSE e i servizi di supporto. HANA non è l'unico consumatore di RAM fisica.

Raccomandazione finale

Utilizzare SAP HANA global_allocation_limitcome limite massimo principale per la memoria HANA, aggiungere statement_memory_limitsolo quando è necessario controllare il rischio delle singole query e utilizzare policy specifiche per utente o classe di carico di lavoro quando carichi di lavoro diversi richiedono limiti diversi. Su SUSE Linux Enterprise Server per applicazioni SAP, utilizzare SAP.slice MemoryLowper proteggere il carico di lavoro SAP dalla pressione a livello host anziché tentare di replicare il limite HANA con un limite rigido cgroup.

Il compromesso più importante è quello tra la massima capacità di cache/query di HANA e un margine di risorse host sufficiente a mantenere efficienti il ​​sistema operativo e i servizi co-ubicati. Basare i valori finali sul dimensionamento SAP e sui picchi di produzione osservati, quindi verificare sia HANA che SLES dopo la modifica.