Wprowadzenie
Comarch ERP Enterprise został stworzony w języku programowania Java. Z tego powodu zarządzanie pamięcią operacyjną w trakcie działania serwera aplikacji systemu ERP (SAS) jest w dużej mierze realizowane przez automatyczny mechanizm Garbage Collection (GC) wirtualnej maszyny Java (JVM). Aby zapewnić wysoką wydajność serwera aplikacji systemu ERP (SAS), konieczne jest dostosowanie parametrów wirtualnej maszyny Java, co pozwala na optymalizację działania Garbage Collection. Przy konfigurowaniu parametrów należy uwzględnić częstotliwość występowania i czas trwania Garbage Collection. Niniejszy artykuł prezentuje parametry używane w Comarch ERP Enterprise i podaje wartości referencyjne dla różnych scenariuszy zastosowania.
Grupa docelowa
- Administratorzy
- Konsultanci techniczni
Wymagania systemowe
Opisane parametry dotyczą Oracle Java Development Kit (JDK) w wersji 1.8 oraz implementacji IBM Java na i5. Wcześniejsze wersje JDK nie są już wspierane.
Definicje terminów
Concurrent User
Oznacza liczbę jednocześnie aktywnych, zalogowanych sesji użytkowników na danym SAS. Liczba ta ma jedynie pośredni związek z liczbą licencjonowanych użytkowników, ponieważ każdy licencjonowany użytkownik może uruchomić kilka sesji (logowanie przez jedną instancję przeglądarki).
Do Concurrent User zaliczają się również sesje ERP System Output Manager (SOM), a także sesje innych usług, takich jak serwer księgowości czy Business Integration Server (BIS).
Full Garbage Collection
Full Garbage Collection (FGC) oprócz zwalniania pamięci powoduje również łączenie wolnych obszarów pamięci w większe, ciągłe bloki (defragmentację heap).
Garbage Collection
Proces, w którym JVM ponownie oznacza jako wolną pamięć nieużywaną już przez obiekty, nazywany jest Garbage Collection (GC). Niepotrzebne obiekty (tzw. „śmieci”) są obrazowo mówiąc zbierane i „usuwane”.
Heap
Heap (sterta) to przestrzeń adresowa w obrębie procesu JVM, w której tworzone i zarządzane są obiekty Java. Więcej informacji na temat struktury heap można znaleźć w dokumentacji Oracle dotyczącej Garbage Collection.
Maksymalnie adresowalny heap w systemie 32-bitowym
W każdym systemie operacyjnym proces może zaadresować jedynie teoretycznie określoną maksymalną ilość pamięci. W systemie 32-bitowym wynosi ona 4 GB (2³²).
W praktyce przestrzeń ta jest dodatkowo dzielona przez system operacyjny na dwa obszary po 2 GB. Jedna połowa jest przeznaczona wyłącznie dla części systemowej procesu, a druga dla części użytkownika. Również te 2 GB dostępne dla użytkownika nie są w pełni wykorzystywalne. System operacyjny podczas wykonywania programów ładuje do przestrzeni adresowej niezbędne biblioteki DLL lub inne biblioteki, często tuż powyżej granicy 1,5 GB.
Java wymaga ciągłego (spójnego) obszaru pamięci do adresowania heap, dlatego w praktyce nie może zaadresować więcej niż około 1,5 GB heap. Wymóg ciągłej przestrzeni adresowej uniemożliwia także wykorzystanie mechanizmów systemowych, takich jak paging, które „symulują” aplikacjom przestrzeń adresową użytkownika o wielkości 3 GB. Nie zaleca się stosowania metod zmieniających obszar adresowy, w którym aplikacje ładują biblioteki DLL i inne biblioteki.
Oprócz heap w przestrzeni adresowej użytkownika ładowane są także inne elementy procesu, takie jak pliki wykonywalne (executables) czy pamięć dla thread stacks. Ponieważ Comarch ERP Enterprise w czasie działania tworzy — zależnie m.in. od liczby połączeń — określoną liczbę wątków, również około 1512 MB nie może zostać w pełni wykorzystane.
Jeśli JVM nie dysponuje wystarczającą ilością pamięci — czy to w heap do tworzenia nowych obiektów, czy w pozostałej części procesu do tworzenia nowych wątków systemowych — zatrzymuje wykonywanie ERP SAS z błędem Out of memory. Serwer ulega awarii i wymaga ponownego uruchomienia.
Z tego powodu oraz ze względu na rosnące zapotrzebowanie na pamięć praca SAS na 32-bitowym JDK nie jest już wspierana. Teoretycznie możliwe jest jednak jego uruchomienie, np. w środowisku deweloperskim.
Metaspace
Metaspace to część heap, w której klasy są ładowane do pamięci operacyjnej.
New Generation
New Generation to część heap, w której rezerwowana jest pamięć dla nowych obiektów.
Old Generation
Old Generation to część heap, do której kopiowane są obiekty, które „przetrwały” jeden lub więcej cykli Garbage Collection.
Survivor Spaces
Survivor Spaces to obszar pamięci wykorzystywany przez niektóre algorytmy Garbage Collection, do którego kopiowane są obiekty, jeśli kilkukrotnie „przetrwają” proces odśmiecania pamięci.
Cykl życia obiektu Java
Jeśli w kodzie programu tworzony jest nowy obiekt Java, JVM próbuje przydzielić dla niego wymaganą ilość pamięci w obszarze New Generation sterty. Nowe obiekty są tworzone w tym obszarze tak długo, aż zabraknie wystarczającej ilości wolnego miejsca na utworzenie kolejnego obiektu w tej części sterty.
Gdy w obszarze New Generation nie ma już wystarczająco dużo miejsca, aby zarezerwować pamięć dla nowych obiektów, uruchamiane jest Garbage Collection, które czyści obszar New Generation. Pamięć zajmowana przez obiekty, które nie są już potrzebne, zostaje zwolniona, natomiast obiekty, do których wciąż istnieją referencje, są kopiowane do tzw. Survivor Spaces lub do obszaru Old Generation.
Jeżeli obszar Old Generation jest zapełniony w około 75% lub jeśli dostępna w nim wolna pamięć jest mniejsza niż rozmiar obszaru New Generation, przeprowadzana jest tzw. Full Garbage Collection w obszarze Old Generation.
Większość obiektów tworzonych w czasie działania systemu SAS to obiekty pomocnicze, np. obiekty sterownika JDBC lub związane z obliczaniem graficznego interfejsu użytkownika. Mają one bardzo krótki czas życia, ponieważ po ich użyciu nie istnieje już żadna referencja do tych obiektów. Występują więc wyłącznie w obszarze New Generation.
Z drugiej strony istnieją np. dane podstawowe (master data), które są przechowywane w pamięci podręcznej (cache) i dlatego są referencjonowane przez cały czas działania systemu SAS. Obiekty te trafiają do obszaru Old Generation i nie są już usuwane z pamięci. Również użytkownik zalogowany przez kilka godzin generuje obiekty, które trafiają do tego obszaru.
Memory Checker
W systemie Comarch ERP Enterprise podejmowane są działania mające na celu uniknięcie wyłączenia JVM w wyniku błędu Out of memory, spowodowanego zbyt małą ilością wolnej pamięci heap.
W Comarch ERP Enterprise nad tym, aby nie zabrakło wolnej pamięci w heapie, czuwa Memory Checker Thread. W tym celu Memory Checker stosuje następujące mechanizmy:
- jeśli ilość wolnej pamięci spadnie poniżej określonego poziomu (mniej niż 64 MB wolnej pamięci), następuje zmiana stanu z Ok na Ostrzeżenie. Wówczas wywoływana jest Full Garbage Collection w celu zwolnienia pamięci.
- jeżeli mimo to podejmowane są dalsze próby rezerwowania pamięci, Comarch ERP Enterprise nie dopuszcza nowych logowań użytkowników. Jako kolejne działanie zamykane są aplikacje działające w trybie podglądu (trybie wyświetlania). Dzięki temu nie dochodzi do utraty wprowadzonych danych.
- jeśli wszystkie powyższe środki okażą się nieskuteczne, wylogowywani są również aktualnie zalogowani użytkownicy.
Zalecane parametry JVM
Implementacje JVM w języku Java różnych producentów częściowo różnią się zasadniczo. W kolejnych rozdziałach podano i objaśniono parametry, które należy stosować dla wspieranych implementacji JVM.
Implementacje Oracle JVM
Dla każdego SAS w aplikacji Panel System można zdefiniować osobny zestaw parametrów JVM. Parametry te są analizowane podczas sekwencji uruchamiania SAS i przekazywane do JVM.
Wartości parametrów JVM mogą ulegać zmianie w dowolnym momencie oraz wraz z każdą nową wersją JVM.
Obszar pamięci przeznaczony na załadowane klasy jest od JDK 1.8 zarządzany wewnętrznie w inny sposób. Zamiast nazwy Permanent Space używana jest obecnie nazwa Metaspace. W związku z tym parametr -XX:MaxPermSize=000m nie jest już obsługiwany. Jego podanie w wierszu poleceń powoduje wyświetlenie ostrzeżenia, a wartość zostaje zignorowana.
Przegląd parametrów
| Parametr | Możliwe wartości |
| -server | -server oder –client |
| -Xms000m-Xmx000m | Parametry te określają dolną i górną granicę rozmiaru heap. Obie wartości powinny być takie same. W aplikacji Panel System należy ustawić maksymalny rozmiar heap na taką samą wartość jak w parametrach JVM. W Comarch ERP Enterprise minimalny rozmiar heap wynosi 512 MB. |
| -XX:MaxMetaspaceSize=000m | Parametr określa rozmiar przeznaczonego obszaru pamięci dla załadowanych klas. Jest obsługiwany dopiero od JDK 1.8. |
Implementacja JVM na IBM i5
Zalecana standardowa kombinacja parametrów JVM dla SAS na i5:
-Djava.version=1.8 -msNNNNm -mxNNNNm -Djava.compiler=jitc-de
-Djava.awt.headless=true
Podane wartości zostaną szczegółowo omówione poniżej. Niektóre konkretne wartości, takie jak rozmiar pamięci sterty, muszą być dostosowane do każdej instalacji. Wskazówki dotyczące odpowiednich rozmiarów można znaleźć w rozdziałach Scenariusze zastosowania oraz Cechy specyficzne dla wersji JVM.
Wartości parametrów JVM mogą ulec zmianie w dowolnym momencie i z każdą nową wersją JVM.
Przegląd parametrów
| Parametr | Możliwe wartości |
| -Djava.version=1.8 | Określa wersję Java, która ma być używana. |
| -Xms000m -Xmx000m | Parametry te określają dolną i górną granicę rozmiaru pamięci Heap. Obie wartości powinny być takie same. W aplikacji Panel System należy ustawić maksymalny rozmiar pamięci Heap na tę samą wartość, co w parametrach JVM. W Comarch ERP Enterprise minimalny rozmiar Heap wynosi 300 MB. |
| -Djava.compiler=jitc_de | Określa, że kompilator Just In Time będzie używany, gdy program Java nie jest dostępny. |
| -Djava.awt.headless=true | Ten parametr musi być używany w systemach Unix i iSeries w celu umożliwienia graficznych wyjść. |
Cechy specyficzne dla wersji JVM
Implementacja Oracle
Parametry Xms i Xmx
W 64-bitowej implementacji rozmiar pamięci sterty jest ograniczony wyłącznie przez dostępne fizyczne zasoby, takie jak pamięć RAM i przestrzeń na dysku twardym (pamięć wirtualna).
Dla parametru Xmx należy użyć:
- Minimalnie: 512 MB
- Dla interaktywnych SAS: Do 4 GB
- Dla SAS do przetwarzania w tle: Teoretycznie bez ograniczeń, jednak zalecana wartość to maksymalnie 6 GB. Należy przy tym uwzględnić czas trwania operacji Garbage Collection, który w przypadku bardzo dużych pamięci sterty może prowadzić do przekroczeń limitów czasu (timeout).
Implementacja 64-bitowa IBM i5
W przeciwieństwie do implementacji Oracle, implementacja IBM i5 nie wykorzystuje algorytmów Garbage Collection opartych na generacjach. Powoduje to odmienne zestawy parametrów. Wiele parametrów dostępnych w implementacji Oracle jest tutaj niedostępnych lub niepotrzebnych.
Parametry Xms i Xmx
Wielkość pamięci sterty jest ograniczona jedynie przez rzeczywiste zasoby fizyczne, takie jak pamięć RAM i przestrzeń na dysku twardym (pamięć wirtualna).
Dla parametru Xmx należy użyć:
- Minimalnie: 1 GB + wartość parametru Xms
- Maksymalnie: Wielkość puli pamięci w GB – 2 GB na wewnętrzne informacje administracyjne
Parametr Xms należy ustawić na mniejszą wartość niż Xmx:
- Minimalnie: 0,5 GB
Sprawdzone w praktyce ustawienia to uruchamianie każdej maszyny wirtualnej JVM w oddzielnym podsystemie i utworzenie dla niej dedykowanej puli pamięci. Podane wartości stanowią punkty wyjścia do dalszych optymalizacji.
Ustawienia dla scenariuszy interaktywnych
| Typ SAS | Liczba użytkowników | Wielkość puli (GB) | Parametr -ms (GB) | Parametr -mx (GB) |
| Dialog | 130 | 10 | 2.5 | 9 |
| Dialog | 70 | 6 | 1.5 | 5 |
| Dialog | 40 | 5 | 1 | 4 |
Ustawienia dla przetwarzania wsadowego
| Typ SAS | Liczba kolejek przetwarzania równoległego | Wielkość puli (GB) | Parametr -ms (GB) | Parametr -mx (GB) |
| W tle | 3 | 4.5 | 1 | 4 |
Scenariusze zastosowania
Wartości podane w poniższej tabeli stanowią jedynie orientacyjne wytyczne. Dokładne wartości muszą zostać ustalone w każdym systemie na podstawie konkretnego profilu obciążenia i przeprowadzonych pomiarów.
| Scenariusz | Oracle-JVM (MB) | IBM i5 JVM (MB) |
| Scenariusz | Min. Mem | Max. Mem |
| System demo | 512 | 512 |
| QAS | 512 | 512 |
| Środowisko deweloperskie | 1024 | 1024 |
| Środowisko testowe | 1024 | 1024 |
| Produkcja (do 15 jednoczesnych użytkowników) | 1024 | 1024 |
| Produkcja (do 30 jednoczesnych użytkowników) | 2048 | 2048 |
| Produkcja (powyżej 30 jednoczesnych użytkowników) | 4096 | 4096 |
| Serwer wiadomości | 1024 | 1024 |
| Serwer wiadomości (podczas instalacji) | 1024 | 4096 |
| Serwer logistyki magazynowej | 1024 | 1024 |
| SAS dla ODBC i raportów | 1024 | 1024 |
| Planowanie i sterowanie produkcją | 1024 | 1024 |
Uwagi:
- W przypadku serwera wiadomości zakłada się, że nie będą na nim odbywały się logowania użytkowników.
- Należy uruchomić oddzielny SAS, na którym będzie działał serwer logistyki magazynowej.
- Serwer planowania i sterowania produkcją przechowuje pełną reprezentację zarządzanych danych w pamięci głównej. W związku z tym podane parametry dla sterty należy traktować jako wartości wyjściowe. W zależności od ilości danych, możliwe są również wartości do 6144 MB.
Uwagi
Kopiowanie bazy danych
Aby skopiować bazę danych, używany SAS wymaga co najmniej 1024 MB pamięci sterty.
Wielkość obszaru New-Generation
Podczas definiowania wielkości obszaru New-Generation należy rozważyć kompromis między częstotliwością a czasem trwania Garbage Collection. Szybsze procesory zazwyczaj potrafią szybciej oczyścić ten obszar pamięci.
Dostęp przez ODBC wymaga pamięci
Tworzenie raportów i dokumentów wymaga dostępu przez ODBC w celu pobrania danych. W przypadku obszernych raportów, ilość tych danych może być bardzo duża, co należy uwzględnić w wyliczeniach pamięci sterty.
Pamięć podręczna serwera aplikacyjnego
Ten obszar pamięci, używany w stercie przez Comarch ERP Enterprise, przechowuje dane, które mają być zachowane w pamięci głównej w celu późniejszego dostępu. Wielkość pamięci podręcznych jest określana za pomocą aplikacji Ustawienia serwera aplikacji. Gdy obszar ten zostanie zapełniony, dane są przenoszone do obszaru Old Generation. Ponieważ dane te są przetwarzane przez mechanizm zarządzania pamięcią podręczną w Comarch ERP Enterprise, zajęta pamięć nie jest dostępna dla innych zadań, takich jak sesja interaktywna.
Należy regularnie sprawdzać stopień wypełnienia pamięci podręcznych SAS za pomocą aplikacji Panel System.
Pamięć sterty wymagana dla pamięci podręcznej jest rozszerzana w miarę potrzeb, aż do osiągnięcia maksymalnego rozmiaru. Dopóki pamięć podręczna nie jest pełna, niezajęte miejsce jest dostępne dla innych zadań.
Analiza zużycia pamięci
- Do wyświetlania zużycia pamięci przez Oracle-JVM można użyć narzędzia jconsole.
- W celu dokładniejszej analizy zużycia pamięci przez aplikacje w systemie deweloperskim, zaleca się użycie narzędzi takich jak Memory Analyzer w Eclipse.
