Jak skonfigurować limity pamięci SAP HANA w systemie SUSE Linux Enterprise Server

Kontrola pamięci SAP HANA w systemie SUSE Linux Enterprise Server działa najlepiej, gdy rozdziela się dwa różne zadania: ograniczanie zasobów, które HANA może przydzielić, oraz ochronę obciążeń SAP, gdy host Linux jest obciążony pamięcią. SAP HANA obsługuje pierwsze zadanie za pomocą parametrów bazy danych, takich jak global_allocation_limiti statement_memory_limit. Ochrona pamięci obciążenia oparta na systemie SUSE systemd/cgroup obsługuje drugie zadanie za pomocą MemoryLowon SAP.slice. Mechanizmy te uzupełniają się, ale nie są zamienne.

W niniejszym przewodniku wykorzystano dokumentację SAP HANA Platform 2.0 SPS 08 oraz aktualne wytyczne dotyczące systemu SUSE Linux Enterprise Server for SAP Applications, dostępne od października 2026 r. Przed zmianą systemu produkcyjnego należy sprawdzić, czy dana wersja HANA i pakiet serwisowy SLES są obsługiwane. Przewodnik instalacyjny firmy SAP odsyła administratorów do dokumentu SAP Note 2235581 dotyczącego obsługiwanych systemów operacyjnych: SAP HANA Server Installation and Update Guide .

Której kontroli pamięci należy użyć?

Dokumenty SAP global_allocation_limitw MB. Przy domyślnej wartości parametru 0, HANA oblicza automatyczny limit na podstawie dostępnej pamięci fizycznej; w podręczniku SPS 08 Administration Guide opisano obecny wzór jako 90% pierwszych 64 GB plus 97% każdego dodatkowego GB, ze specjalnym uwzględnieniem bardzo małych systemów. W tym samym podręczniku stwierdzono, że zmiana parametru nie wymaga ponownego uruchomienia. Zobacz podręcznik SAP HANA Administration Guide 2.0 SPS 08 .

Krok 1: Zmierz pamięć hosta przed ustawieniem limitu

Zacznij od sprawdzenia w SLES fizycznej pamięci RAM, dostępnej pamięci, aktywności wymiany i tego, czy procesy SAP są już zgrupowane w SAP.slice. Dzięki temu poznasz warunki brzegowe przed podjęciem decyzji, ile pamięci może wykorzystać HANA.

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

Nie należy ustawiać limitu HANA poprzez odejmowanie stałej liczby gigabajtów od zainstalowanej pamięci RAM. Należy zarezerwować pamięć dla jądra Linux, agenta hosta SAP, oprogramowania monitorującego, narzędzi do tworzenia kopii zapasowych, komponentów klastra i wszelkich współlokowanych serwerów aplikacji. Jeśli ABAP i HANA współdzielą hosta, SAP wyraźnie wymaga, aby rozmiar obu systemów mieścił się w pamięci fizycznej i zaleca skoordynowanie globalnego limitu alokacji HANA z ustawieniem ABAP PHYS_MEMSIZE: SAP Configuring Memory Settings (Konfigurowanie ustawień pamięci SAP) .

Krok 2: Odczytaj istniejące parametry pamięci HANA

Przed wprowadzeniem jakichkolwiek zmian należy zapisać obowiązującą konfigurację. Można ją sprawdzić M_INIFILE_CONTENTSw SAP HANA Database Explorer, w konsoli Cockpit SQL lub w innym autoryzowanym kliencie 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;

Warstwa ma znaczenie. W systemach wielodostępnych ustawienia na poziomie systemu i bazy danych mogą mieć różny zakres. Nie kopiuj polecenia z przykładu z pojedynczym kontenerem bez sprawdzenia, czy łączysz się z bazą danych SYSTEMDB, czy z bazą danych dzierżawcy, oraz którą warstwę zamierzasz zmienić.

Krok 3: Ustaw globalny limit alokacji HANA

Użyj tej global_allocation_limitopcji, gdy celem jest ograniczenie całkowitej alokacji HANA. Wartość taka jak 180 000 oznacza 180 000 MB; jest to tylko przykład, a nie uniwersalna rekomendacja. Prawidłowa liczba musi wynikać z rozmiaru, historii obciążenia, wymagań wysokiej dostępności oraz pamięci, która musi pozostać dostępna dla systemu operacyjnego i innych procesów.

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

Zaletą niższego limitu globalnego jest przewidywalny margines bezpieczeństwa poza HANA. Kosztem jest mniejsza przestrzeń na rozbudowę magazynu kolumn, pamięci podręcznej, pośrednie wyniki zapytań i obciążenie usługi. Jeśli host jest dedykowany dla HANA, automatyczne ustawienie domyślne może być odpowiednie po sprawdzeniu rozmiaru. Jeśli host jest współdzielony, zazwyczaj łatwiej jest uzasadnić jawny limit, ponieważ każde obciążenie rezydujące ma zdefiniowany budżet.

Krok 4: Zdecyduj, czy ograniczyć liczbę pojedynczych poleceń SQL

statement_memory_limitKontroluje maksymalny przydział pamięci dla pojedynczego polecenia i jest wyrażony w GB. SAP dokumentuje wartość domyślną jako 0, co oznacza brak limitu specyficznego dla polecenia. Skończona wartość jest przydatna, gdy doraźne zapytania analityczne lub źle filtrowane łączenia mogą zużywać dużą część puli globalnej.

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

Kompromis jest bezpośredni: ściślejszy limit chroni współbieżność, ale może przerwać wykonywanie instrukcji wymagających dużej ilości pamięci, które są ważne dla Twojej firmy. SAP zauważa, że ​​osiągnięcie limitu przerywa wykonywanie instrukcji i może spowodować wygenerowanie zrzutu pamięci z compositelimit_oomnazwą. Szczegółowe informacje można znaleźć w sekcji poświęconej zarządzaniu pamięcią w podręczniku SAP HANA Troubleshooting and Performance Analysis Guide .

Krok 5: Użyj limitów specyficznych dla użytkownika, gdy jedna z wartości globalnych jest zbyt ogólna

Pojedynczy limit wyciągów jest prosty w obsłudze, ale traktuje konto ETL z dnia na dzień tak samo, jak interaktywnego użytkownika raportującego. SAP obsługuje limit specyficzny dla użytkownika STATEMENT MEMORY LIMIT, który ma pierwszeństwo przed globalnym limitem wyciągów dla tego użytkownika.

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

To podejście jest często lepsze niż obniżenie globalnego limitu dla wszystkich. Na przykład można ograniczyć raportowanie ad-hoc, pozostawiając kontom wsadowym lub administracyjnym większy limit. Wadą jest zarządzanie: wyjątki muszą być dokumentowane, sprawdzane i usuwane, gdy nie są już potrzebne. SAP dokumentuje również ograniczenia dotyczące zapytań międzybazowych i niektórych scenariuszy XS Classic, w których klasy obciążenia mogą być bardziej odpowiednie. Zobacz SAP: Ustawianie parametrów użytkownika dla obciążenia .

Krok 6: Chroń pamięć SAP w systemie SUSE za pomocą funkcji MemoryLow, a nie drugiego twardego limitu

W przypadku aplikacji SAP w systemie SLES firma SUSE zaleca ochronę pamięci obciążenia za pomocą systemd i cgroup v2. Instancje SAP są umieszczane w SAP.slice, a firma SUSE twierdzi, że w przypadku SAP HANA globalny limit alokacji HANA może być podstawą dla MemoryLow.

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

MemoryLowto próg ochrony: pod presją pamięci jądro próbuje chronić tę ilość dla grupy cgroup. Nie jest to to samo MemoryMax, co i nie zastępuje własnego alokatora HANA. To rozróżnienie jest istotne, ponieważ sztywny limit na poziomie systemu operacyjnego może powodować inny tryb awarii niż wewnętrzne mechanizmy alokacji HANA.

Firma SUSE ostrzega również, aby nie ustawiać MemoryLowlimitu pamięci fizycznej na poziomie bliskim lub przekraczającym całkowitą pamięć fizyczną, ponieważ usługi systemowe i inne zainstalowane oprogramowanie również potrzebują pamięci. Aktualne wytyczne są dostępne w dokumencie SUSE Workload Memory Protection for SLES for SAP 15 SP6 .

Krok 7: Sprawdź, czy przypadkowo nie dodałeś kolidującego capa cgroup

Po ustawieniu MemoryLowsprawdź odpowiednie właściwości systemd. Jeśli w Twoim projekcie celowo nie użyto MemoryHighlub MemoryMax, sprawdź, czy nie zostały one wprowadzone przez lokalny moduł, system automatyzacji lub niezwiązaną z nim politykę dostrajania.

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

Jest to szczególnie ważne w przypadku hostów współdzielonych zarządzanych przez automatyzację konfiguracji. Ochrona pamięci obciążenia SUSE została zaprojektowana w celu ochrony SAP przed obciążeniami pochodzącymi spoza chronionej grupy cgroup; nie może ona chronić systemów SAP ani instancji SAP przed sobą, gdy wszystkie korzystają z tej samej grupy cgroup SAP.slice. Oznacza to, że skalowanie na poziomie aplikacji nadal ma znaczenie, nawet gdy włączona jest ochrona grupy cgroup.

Krok 8: Sprawdź ustawienia HANA i obserwuj zachowanie przy rzeczywistym obciążeniu

Po zmianie należy ponownie wykonać zapytanie M_INIFILE_CONTENTSi potwierdzić zamierzoną warstwę oraz wartości. Następnie monitorować system podczas normalnego i szczytowego obciążenia. Konfiguracja nie powiedzie się tylko dlatego, że polecenie SQL zostało wykonane bezbłędnie.

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

Zwróć uwagę na zdarzenia braku pamięci, anulowanie instrukcji, stałe obciążenie pamięci, zamianę pamięci i opóźnienia obciążenia. Jeśli instrukcje, które wcześniej się kończyły, zaczynają kończyć się błędami limitu pamięci, wartość dla każdej instrukcji może być zbyt restrykcyjna. Jeśli Linux ma bardzo mało miejsca na zapas, a HANA regularnie zbliża się do globalnego limitu, globalny limit może być zbyt wysoki dla łącznego obciążenia hosta. Jeśli HANA utrzymuje się znacznie poniżej limitu, podczas gdy krytyczne zapytania są rozlewane lub przerywane, limit może być zbyt niski lub obciążenie może wymagać bardziej ukierunkowanej polityki.

Wybór zasad dla typowych wzorców wdrażania

Dedykowany host produkcyjny HANA

Preferuj globalne zarządzanie alokacją w HANA i zostaw wystarczającą przestrzeń na system operacyjny w oparciu o rozmiar SAP. Dodaj limit instrukcji tylko wtedy, gdy historia obciążenia pokazuje, że poszczególne instrukcje zagrażają współbieżności. Użyj SUSE, MemoryLowgdy chcesz chronić obciążenie SAP przed obciążeniem pamięci spoza SAP na hoście.

Serwer aplikacji HANA plus na jednym hoście

Używaj jasno określonych budżetów. Koordynuj HANA global_allocation_limitz ustawieniami pamięci serwera aplikacji, takimi jak PHYS_MEMSIZE. Jest to mniej elastyczne niż pozostawienie obu stronom swobodnego rozwoju, ale zmniejsza ryzyko, że jeden komponent zużyje pamięć potrzebną drugiemu.

Analityka mieszana z nieprzewidywalnymi zapytaniami ad hoc

Połącz rozsądny globalny limit alokacji z kontrolami na poziomie instrukcji. Zacznij od dowodów z kosztownych instrukcji i szczytowego wykorzystania pamięci, a nie od dowolnej, małej liczby. Limity specyficzne dla użytkownika lub klasy obciążenia są preferowane, gdy tylko niektórzy użytkownicy lub aplikacje generują ryzykowne zapytania.

Systemy HA lub klastrowe systemy HANA

Określ rozmiar zarówno stanu aktywnego, jak i przejęcia. Węzeł drugorzędny, który staje się węzłem podstawowym, może potrzebować znacznie innej pamięci niż ta, której używa podczas replikacji stacjonarnej. Traktuj projekt trybu failover, agentów klastra, stos monitorowania i wszelkie współlokowane obciążenia jako część budżetu pamięci, zamiast konfigurować każdy host oddzielnie.

Typowe błędy, których należy unikać

• Traktowanie MemoryLow jako sztywnego limitu. Chroni pamięć, ale nie ogranicza HANA do tej ilości.
• Ustawienie parametru MemoryMax jest poprawne, ponieważ brzmi to jak odpowiednik limitu alokacji w systemie HANA. Semantyka jest inna, a sztywny limit systemu operacyjnego może zakłócać zarządzanie pamięcią w systemie HANA.
• Używanie tego samego limitu instrukcji dla każdego użytkownika bez dowodów obciążenia. Zapytanie raportujące i operacja konserwacyjna mogą mieć zupełnie inne uzasadnione zapotrzebowanie na pamięć.
• Ignorując warstwę konfiguracji w systemach MDC. Sprawdź, czy zmieniasz zakres SYSTEM, HOST lub DATABASE oraz do której bazy danych jest kierowana Twoja sesja SQL.
• Kopiowanie przykładowych liczb do produkcji. Podane tutaj wartości 180 GB i 5 GB to wartości demonstracyjne, a nie zalecenia dotyczące rozmiaru.
• Nie pozostawiając marginesu dla SUSE i usług wspierających. HANA nie jest jedynym konsumentem fizycznej pamięci RAM.

Ostateczna rekomendacja

Użyj SAP HANA global_allocation_limitjako głównego limitu pamięci HANA, dodawaj statement_memory_limittylko wtedy, gdy potrzebujesz kontrolować ryzyko związane z indywidualnymi zapytaniami, i stosuj zasady specyficzne dla użytkownika lub klasy obciążenia, gdy różne obciążenia wymagają różnych limitów. W systemie SUSE Linux Enterprise Server for SAP Applications użyj tej opcji, SAP.slice MemoryLowaby chronić obciążenie SAP przed obciążeniem na poziomie hosta, zamiast próbować dublować limit HANA za pomocą sztywnego limitu cgroup.

Najważniejszy kompromis dotyczy maksymalnej pojemności pamięci podręcznej/zapytań HANA a wystarczającą rezerwą mocy obliczeniowej hosta, aby utrzymać system operacyjny i usługi współlokowane w dobrym stanie. Ostateczne wartości należy oprzeć na rozmiarze SAP i zaobserwowanych szczytach produkcyjnych, a następnie zweryfikować zarówno HANA, jak i SLES po zmianie.