Cum se configurează limitele de memorie SAP HANA pe serverul SUSE Linux Enterprise

Controlul memoriei SAP HANA pe SUSE Linux Enterprise Server funcționează cel mai bine atunci când separați două joburi diferite: limitarea a ceea ce HANA poate aloca și protejarea sarcinilor de lucru SAP atunci când gazda Linux se află sub presiune a memoriei. SAP HANA gestionează primul job cu parametri ai bazei de date, cum ar fi global_allocation_limitși statement_memory_limit. Protecția memoriei sarcinii de lucru bazată pe systemd/cgroup de la SUSE îl gestionează pe al doilea cu MemoryLowactivat SAP.slice. Aceste mecanisme se completează reciproc, dar nu sunt interschimbabile.

Acest ghid utilizează documentația SAP HANA Platform 2.0 SPS 08 și îndrumările actuale SUSE Linux Enterprise Server for SAP Applications disponibile în octombrie 2026. Înainte de a modifica un sistem de producție, confirmați că revizia exactă HANA și pachetul service pack SLES sunt acceptate. Ghidul de instalare SAP îi îndrumă pe administratori către Nota SAP 2235581 pentru sistemele de operare acceptate: Ghid de instalare și actualizare SAP HANA Server .

Ce control al memoriei ar trebui să utilizați?

Documente SAP global_allocation_limitîn MB. Cu parametrul lăsat la valoarea implicită 0, HANA calculează o limită automată bazată pe memoria fizică disponibilă; Ghidul de administrare SPS 08 descrie formula curentă ca fiind 90% din primii 64 GB plus 97% din fiecare GB suplimentar, cu o gestionare specială pentru sistemele foarte mici. Același ghid precizează că modificarea parametrului nu necesită o repornire. Consultați Ghidul de administrare SAP HANA 2.0 SPS 08 .

Pasul 1: Măsurați memoria gazdă înainte de a seta o limită

Începeți pe SLES verificând memoria RAM fizică, memoria disponibilă, activitatea de swap și dacă procesele SAP sunt deja grupate în SAP.slice. Aceasta vă oferă condițiile limită înainte de a decide câtă memorie poate utiliza HANA.

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

Nu alegeți o limită HANA pur și simplu scăzând un număr fix de gigaocteți din memoria RAM instalată. Rezervați memorie pentru kernelul Linux, agentul gazdă SAP, software-ul de monitorizare, instrumentele de backup, componentele clusterului și orice servere de aplicații colocate. Dacă ABAP și HANA partajează o gazdă, SAP solicită în mod explicit dimensionarea ambelor sisteme pentru a se încadra în memoria fizică și recomandă coordonarea limitei globale de alocare HANA cu PHYS_MEMSIZEsetarea ABAP: Configurarea setărilor de memorie SAP .

Pasul 2: Citiți parametrii de memorie HANA existenți

Înainte de a modifica orice, înregistrați configurația efectivă. Puteți inspecta M_INIFILE_CONTENTSdin SAP HANA Database Explorer, consola Cockpit SQL sau alt client SQL autorizat.

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;

Stratul contează. În sistemele cu mai mulți chiriași, setările la nivel de sistem și la nivel de bază de date pot avea domenii de aplicare diferite. Nu copiați o comandă dintr-un exemplu cu un singur container fără a verifica dacă sunteți conectat la SYSTEMDB sau la o bază de date cu chiriași și ce strat intenționați să modificați.

Pasul 3: Setați limita globală de alocare HANA

Se utilizează global_allocation_limitatunci când obiectivul este de a limita alocarea totală a HANA. O valoare precum 180000 înseamnă 180.000 MB; este doar un exemplu, nu o recomandare universală. Numărul corect trebuie să provină din dimensionare, istoricul încărcării de lucru, cerințele de disponibilitate ridicată și memoria care trebuie să rămână disponibilă sistemului de operare și altor procese.

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

Avantajul unei limite globale inferioare este spațiul previzibil în afara HANA. Costul constă în mai puțin spațiu pentru creșterea stocării în coloane, cache-uri, rezultate intermediare ale interogărilor și costuri suplimentare de serviciu. Dacă gazda este dedicată HANA, valoarea implicită automată poate fi potrivită după validarea dimensionării. Dacă gazda este partajată, o limită explicită este de obicei mai ușor de abordat, deoarece fiecare sarcină de lucru rezidentă are un buget definit.

Pasul 4: Decideți dacă să limitați instrucțiunile SQL individuale

statement_memory_limitcontrolează alocarea maximă de memorie pentru o singură instrucțiune și este exprimată în GB. SAP documentează valoarea implicită ca fiind 0, ceea ce înseamnă că nu există o limită specifică instrucțiunii. O valoare finită este utilă atunci când interogările analitice ad-hoc sau joncțiunile filtrate necorespunzător pot consuma o mare parte din pool-ul global.

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

Compromisul este direct: o limită mai strictă protejează concurența, dar poate anula instrucțiunile care consumă multă memorie și care sunt valide pentru afacerea dvs. SAP notează că atingerea limitei anulează instrucțiunea și poate produce o imagine de memorie cu [dump] compositelimit_oomîn numele său. Pentru detalii, consultați secțiunea de gestionare a memoriei din Ghidul de depanare și analiză a performanței SAP HANA .

Pasul 5: Folosiți limite specifice utilizatorului atunci când o valoare globală este prea grosieră

O limită pentru o singură declarație este simplu de utilizat, dar tratează un cont ETL overnight la fel ca un utilizator cu raportare interactivă. SAP acceptă o limită specifică utilizatorului STATEMENT MEMORY LIMITcare are prioritate față de limita globală pentru declarația respectivă.

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

Această abordare este adesea mai bună decât reducerea limitei globale pentru toată lumea. De exemplu, puteți restricționa raportarea ad-hoc, lăsând în același timp conturile de lot sau administrative cu o alocație mai mare. Dezavantajul este guvernanța: excepțiile trebuie documentate, revizuite și șterse atunci când nu mai sunt necesare. SAP documentează, de asemenea, limitările pentru interogările între baze de date și anumite scenarii XS Classic, unde clasele de sarcină de lucru pot fi mai potrivite. Consultați SAP Setarea parametrilor de utilizator pentru sarcină de lucru .

Pasul 6: Protejați memoria SAP pe SUSE cu MemoryLow, nu cu o a doua limitare fixă

Pe SLES pentru aplicații SAP, SUSE recomandă protecția memoriei sarcinii de lucru prin systemd și cgroup v2. Instanțele SAP sunt plasate în SAP.slice, iar SUSE afirmă că pentru SAP HANA, limita de alocare globală HANA poate fi utilizată ca bază pentru MemoryLow.

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

MemoryLoweste un prag de protecție: sub presiunea memoriei, kernelul încearcă să protejeze acea cantitate pentru cgroup. Nu este același lucru cu MemoryMaxși nu înlocuiește propriul alocator al HANA. Această distincție este importantă deoarece o limită rigidă la nivel de sistem de operare poate crea un mod de eroare diferit de controalele interne de alocare ale HANA.

SUSE avertizează, de asemenea, să nu setați MemoryLowo memorie aproape de sau peste valoarea totală, deoarece serviciile de sistem și alte programe software instalate necesită și ele memorie. Îndrumările actuale sunt disponibile în SUSE Workload Memory Protection for SLES pentru SAP 15 SP6 .

Pasul 7: Confirmați că nu ați adăugat accidental un plafon cgroup conflictual

După setare MemoryLow, inspectați proprietățile systemd relevante. Dacă designul dvs. nu utilizează intenționat MemoryHighsau MemoryMax, verificați dacă acestea nu au fost introduse de un drop-in local, un sistem de automatizare sau o politică de optimizare fără legătură.

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

Acest lucru este deosebit de important pe gazdele partajate gestionate prin automatizarea configurării. Protecția memoriei sarcinii de lucru SUSE este concepută pentru a proteja SAP împotriva presiunii exercitate de sarcinile de lucru din afara grupului de control protejat; nu poate proteja sistemele SAP sau instanțele SAP unele de altele atunci când toate au același domeniu SAP.slice. Aceasta înseamnă că dimensionarea la nivel de aplicație contează în continuare chiar și atunci când protecția grupului de control este activată.

Pasul 8: Verificați setările HANA și urmăriți comportamentul în condiții de sarcină de lucru reală

Reinterogați M_INIFILE_CONTENTSdupă modificare și confirmați stratul și valorile dorite. Apoi monitorizați sistemul în timpul sarcinii normale și de vârf. O configurație nu are succes doar pentru că instrucțiunea SQL a fost executată fără erori.

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

Fiți atenți la evenimentele de memorie insuficientă, anulările de instrucțiuni, presiunea susținută a memoriei, schimbarea și latența sarcinii de lucru. Dacă instrucțiunile care obișnuiau să se termine încep să eșueze cu erori de limită de memorie, valoarea per instrucțiune poate fi prea restrictivă. Dacă Linux are foarte puțin spațiu de manevră în timp ce HANA se apropie în mod regulat de limita globală, limita globală poate fi prea mare pentru sarcina de lucru combinată a gazdei. Dacă HANA rămâne mult sub limita sa în timp ce interogările critice se revarsă sau sunt abandonate, limita poate fi prea mică sau sarcina de lucru poate necesita o politică mai precisă.

Alegerea unei politici pentru modele comune de implementare

Gazdă HANA dedicată producției

Favorizați gestionarea alocării globale proprie HANA și lăsați suficient spațiu de operare în funcție de dimensionarea SAP. Adăugați o limită de instrucțiuni numai dacă istoricul sarcinii de lucru arată că instrucțiunile individuale amenință concurența. Utilizați SUSE MemoryLowatunci când doriți ca sarcina de lucru SAP să fie protejată de presiunea memoriei non-SAP pe gazdă.

Server de aplicații HANA plus pe o singură gazdă

Folosește bugete explicite. Coordonează HANA global_allocation_limitcu setările de memorie ale serverului de aplicații, cum ar fi PHYS_MEMSIZE. Acest lucru este mai puțin flexibil decât permiterea creșterii libere a ambelor părți, dar reduce riscul ca o componentă să consume memoria necesară celeilalte.

Analize mixte cu interogări ad-hoc imprevizibile

Combinați o limită de alocare globală rezonabilă cu controale la nivel de instrucțiune. Începeți cu dovezi din instrucțiuni costisitoare și utilizare maximă a memoriei, mai degrabă decât cu un număr mic arbitrar. Limitele specifice utilizatorului sau clasele de sarcină de lucru sunt preferabile atunci când doar anumiți utilizatori sau aplicații generează interogări riscante.

Sisteme HA sau HANA în cluster

Dimensionați atât starea activă, cât și starea de preluare. Un nod secundar care devine primar poate necesita o memorie substanțial diferită față de cea utilizată în timpul replicării în stare stabilă. Tratați designul de failover, agenții de cluster, stiva de monitorizare și orice sarcini de lucru colocate ca parte a bugetului de memorie, în loc să configurați fiecare gazdă în mod izolat.

Greșeli frecvente de evitat

• Tratează MemoryLow ca o limită fixă. Protejează memoria; nu limitează HANA la această valoare.
• Setarea MemoryMax deoarece sună echivalent cu limita de alocare a HANA. Semantica este diferită, iar o limitare fixă ​​a sistemului de operare poate interfera cu gestionarea memoriei în sine a HANA.
• Utilizarea aceleiași limite de instrucțiuni pentru fiecare utilizator fără dovezi ale încărcării de lucru. O interogare de raportare și o operațiune de întreținere pot avea nevoi legitime de memorie foarte diferite.
• Ignorarea nivelului de configurare în sistemele MDC. Confirmați dacă modificați domeniul de aplicare SYSTEM, HOST sau DATABASE și ce bază de date vizează sesiunea SQL.
• Copierea numerelor de exemplu în producție. Valorile de 180 GB și 5 GB afișate aici sunt valori demonstrative, nu recomandări de dimensionare.
• Fără a lăsa loc pentru SUSE și serviciile de asistență. HANA nu este singurul consumator de RAM fizic.

Recomandare finală

Folosește SAP HANA global_allocation_limitca plafon principal pentru memoria HANA, adaugă-le statement_memory_limitdoar atunci când trebuie să controlezi riscul individual al interogărilor și folosește politici specifice utilizatorului sau clasei de sarcini de lucru atunci când sarcini de lucru diferite necesită limite diferite. Pe SUSE Linux Enterprise Server for SAP Applications, folosește-le SAP.slice MemoryLowpentru a proteja sarcina de lucru SAP de presiunea la nivel de gazdă, în loc să încerci să duplicezi limita HANA cu un plafon fix pentru grupul de comandă.

Cel mai important compromis este între capacitatea maximă a memoriei cache/interogărilor HANA și suficient spațiu de stocare pentru gazdă pentru a menține sistemul de operare și serviciile colocate în stare bună. Bazați cifrele finale pe dimensionarea SAP și pe vârfurile de producție observate, apoi verificați atât HANA, cât și SLES după modificare.