Ta strona umożliwia wyświetlanie i zmianę ustawień konfiguracyjnych wirtualnej maszyny języka Java związanych z procesem serwera aplikacji.
Aby wyświetlić tę stronę Konsoli administracyjnej, należy nawiązać połączenie z Konsolą administracyjną i przejść do panelu wirtualnej maszyny języka Java.
W przypadku systemu
IBM
i oraz platform rozproszonych kliknij opcję
Serwery > Typy serwerów > Serwery aplikacji
WebSphere > nazwa_serwera.
Następnie w sekcji Infrastruktura serwera kliknij opcję
Język Java i zarządzanie procesami > Definicja procesu
> Wirtualna maszyna języka Java.
Serwer aplikacji | Kliknij opcję Serwery>Typy serwerów>Serwery aplikacji WebSphere> nazwa_serwera. Następnie w sekcji Infrastruktura serwera kliknij opcję Język Java i zarządzanie procesami > Definicja procesu > Sterowanie > Wirtualna maszyna języka Java . |
Menedżer wdrażania | Kliknij opcję Administrowanie systemem > Menedżer wdrażania. Następnie w sekcji Infrastruktura serwera kliknij opcję Język Java i zarządzanie procesami > Definicja procesu > Sterowanie > Wirtualna maszyna języka Java . |
Agent węzła | Kliknij opcję Administrowanie systemem > Agent węzła > agent_węzła. Następnie w sekcji Infrastruktura serwera kliknij opcję Język Java i zarządzanie procesami > Definicja procesu > Wirtualna maszyna języka Java. |
Serwer aplikacji | Serwery > Typy serwerów > Serwery aplikacji WebSphere > nazwa_serwera. Następnie w sekcji Infrastruktura serwera kliknij opcję Język Java i zarządzanie procesami > Definicja procesu > Wirtualna maszyna języka Java. |
Menedżer wdrażania | Administrowanie systemem > Menedżer wdrażania. Następnie w sekcji Infrastruktura serwera kliknij opcję Język Java i zarządzanie procesami > Definicja procesu > Wirtualna maszyna języka Java. |
Agent węzła | Administrowanie systemem > Agent węzła > agent_węzła. Następnie w sekcji Infrastruktura serwera kliknij opcję Język Java i zarządzanie procesami > Definicja procesu > Wirtualna maszyna języka Java. |
Określa standardową ścieżkę klasy, w której kod wirtualnej maszyny języka Java szuka klas.
Aby dodać ścieżkę klasy do tego pola, należy wprowadzić każdą ścieżkę klasy w oddzielnym wierszu tabeli. Nie trzeba dodawać dwukropka ani średnika na końcu każdej pozycji.
Typ danych | String |
Określa klasy i zasoby programu startowego dla kodu wirtualnej maszyny języka Java. Ta opcja jest dostępna tylko dla instrukcji maszyny JVM, które obsługują klasy i zasoby programu startowego.
Aby dodać ścieżkę klasy do tego pola, należy wprowadzić każdą ścieżkę klasy w oddzielnym wierszu tabeli. Na końcu każdej pozycji nie trzeba dodawać dwukropka ani średnika.
Aby dodać wiele ścieżek klas do tego pola, w celu ich rozdzielenia należy użyć dwukropka (:) lub średnika (;), w zależności od systemu operacyjnego, w którym rezyduje maszyna JVM.
Aby dodać wiele ścieżek klas do tego pola, w celu ich rozdzielenia należy użyć dwukropka (:) lub średnika (;), w zależności od systemu operacyjnego, w którym rezyduje węzeł.
Określa, czy podczas ładowania klas mają być generowane szczegółowe dane wyjściowe debugowania. Domyślnie szczegółowe komunikaty ładowania klas nie są włączone.
Jeśli szczegółowe komunikaty ładowania klas są włączone, dane wyjściowe debugowania
są wysyłane do jednego z dzienników procesu rodzimego.
Typ danych | Boolean |
Wartość domyślna | fałsz |
Określa, czy podczas czyszczenia pamięci mają być generowane szczegółowe dane wyjściowe debugowania. Domyślnie opcja szczegółowego czyszczenia pamięci jest wyłączona.
Jeśli szczegółowe komunikaty czyszczenia pamięci są włączone, dane wyjściowe debugowania
są wysyłane do jednego z dzienników procesu rodzimego.
Typ danych | Boolean |
Wartość domyślna | fałsz |
Jeśli to pole jest aktywne, podczas każdego uruchomienia czyszczenia pamięci do strumienia wyjściowego zapisywany jest raport. Ten raport pozwala uzyskać informacje na temat przebiegu procesu czyszczenia pamięci środowiska Java.
83,29/3724,32 * 100 = 2,236 %
Jeśli na czyszczenie pamięci jest poświęcane więcej niż 5% czasu użytkownika i jest ono wykonywane często, może być konieczne zwiększenie wielkości sterty Java.
Aby określić, czy przydzielony obszar sterty zwiększa się, należy sprawdzić, jaki procent sterty po każdym cyklu czyszczenia pamięci pozostaje nieprzydzielony, a następnie sprawdzić, czy ten procent nie zmniejsza się. Jeśli procent wolnego miejsca zmniejsza się, oznacza to występuje stopniowy wzrost obszaru sterty po każdym czyszczeniu pamięci. Może to wskazywać na występowanie w aplikacji przecieku pamięci.
Na platformie
z/OS
można także użyć komendy konsoli
MVS modify display,
jvmheap, aby wyświetlić informacje o stercie maszyny JVM. Dodatkowo
można też sprawdzić działanie serwera i przedział między rekordami SMF. Wielkość
sterty maszyny JVM jest również dostępna dla infrastruktury monitorowania wydajności
(PMI) i może być monitorowana przy użyciu przeglądarki Tivoli Performance
Viewer.
Określa, czy podczas wywoływania metod rodzimych mają być generowane szczegółowe dane wyjściowe debugowania. Domyślnie opcja szczegółowego wywoływania działania interfejsu Java Native Interface (JNI) jest wyłączona.
Typ danych | Boolean |
Wartość domyślna | fałsz |
Służy do określania (w megabajtach) początkowej wielkości sterty dostępnej dla kodu maszyny JVM. Jeśli to pole pozostanie puste, zostanie użyta wartość domyślna.
W systemie z/OS domyślna początkowa wielkość sterty dla kontrolera
wynosi 48 MB, a dla elementu podrzędnego 128 MB. Te wartości
domyślne mają zastosowanie zarówno do 31-bitowych, jak i 64-bitowych konfiguracji.
W systemie IBM i oraz na platformach rozproszonych
domyślna początkowa wielkość sterty wynosi 50 MB.
Zwiększenie wartości tego ustawienia może poprawić uruchamianie. Liczba zdarzeń czyszczenia pamięci zostaje zredukowana i uzyskiwany jest wzrost wydajności o 10%.
Zwiększenie wielkości sterty Java zwiększa przepustowość, dopóki sterta nie stanie się zbyt duża, aby rezydować w pamięci fizycznej. Jeśli jednak wielkość sterty przekracza wielkość dostępnej pamięci fizycznej i występuje stronicowanie, następuje zauważalne zmniejszenie wydajności.
Służy do określania w megabajtach maksymalnej wielkości sterty dostępnej dla kodu maszyny JVM. Jeśli to pole pozostanie puste, zostanie użyta wartość domyślna.
Domyślna maksymalna wielkość sterty wynosi 256 MB. Wartość ta dotyczy zarówno konfiguracji 31-bitowych, jak i 64-bitowych.
Zwiększenie maksymalnej wielkości sterty może poprawić uruchamianie. Zwiększając wielkość sterty, można zmniejszyć liczbę zdarzeń czyszczenia pamięci i uzyskać wzrost wydajności o 10 procent.
Zwiększenie tego ustawienia zwykle zwiększa przepustowość, dopóki sterta nie stanie się zbyt duża, aby rezydować w pamięci fizycznej. Jeśli jednak wielkość sterty przekracza wielkość dostępnej pamięci fizycznej i występuje stronicowanie, następuje zauważalne zmniejszenie wydajności. Z tego powodu ważne jest, aby wartość określona dla tej właściwości umożliwiała przechowywanie sterty w pamięci fizycznej.
W celu zapobieżenia stronicowaniu należy tak ustawić wartości tej właściwości, aby
zostało przydzielone co najmniej 256 MB pamięci fizycznej na każdy procesor oraz 512 MB pamięci fizycznej na każdy serwer
aplikacji. Jeśli użycie procesora jest niskie z powodu stronicowania, należy
zwiększyć dostępną pamięć, zamiast zwiększać maksymalną wielkość sterty. Zwiększenie maksymalnej wielkości sterty może zmniejszyć wydajność.
Jeśli w systemie IBM i ta właściwość jest ustawiona na wartość 0, funkcja
czyszczenia pamięci jest uruchamiana tylko po przekroczeniu progu czyszczenia pamięci. Jeśli zostanie podana wartość różna od 0,
czyszczenia pamięci jest uruchamiane po osiągnięciu przez stertę określonej
wielkości maksymalnej. Mimo to, inaczej niż w przypadku normalnego czyszczenia
pamięci, po osiągnięciu maksymalnej wielkości sterty wszystkie wątki aplikacji
muszą zaczekać na zakończenie procesu czyszczenia pamięci, zanim będą mogły
kontynuować działanie. Może to powodować niepożądane przerwy. Z tego powodu
wartości maksymalnej wielkości sterty należy używać jako zabezpieczenia
umożliwiającego obsługiwanie wystąpień nieoczekiwanych przyrostów wielkości sterty
i jako środka uniemożliwiającego zwiększenie wielkości sterty do wartości
przekraczającej ilość dostępnej pamięci. W
normalnych warunkach osiągnięcie określonej maksymalnej wartości sterty nie
powinno nastąpić nigdy.
Określa, czy ma być używany klasyfikator HProf. Aby korzystać z innego klasyfikatora, określ ustawienia klasyfikatora niestandardowego za pomocą ustawienia Argumenty klasyfikatora HProf. Domyślnie opcja obsługi klasyfikatora HProf jest wyłączona.
Jeśli opcja Uruchom klasyfikator HProf zostanie ustawiona na wartość true (prawda), należy podać argumenty klasyfikatora wiersza komend jako wartości właściwości Argumenty klasyfikatora HProf.
Typ danych | Boolean |
Wartość domyślna | fałsz |
Określa argumenty profilu wiersza komend, które są przekazywane do kodu maszyny JVM uruchamiającej proces serwera aplikacji. W celu określenia argumentów należy włączyć obsługę klasyfikatora HProf.
Argumenty klasyfikatora HProf są wymagane tylko wtedy, gdy właściwość Uruchom klasyfikator HProf zostanie ustawiona na wartość true (prawda).
Określa, czy maszyna JVM ma być uruchamiana w trybie debugowania. Domyślnie obsługa trybu debugowania jest wyłączona.
Jeśli opcja Tryb debugowania zostanie ustawiona na wartość true (prawda), należy podać argumenty debugowania wiersza komend jako wartości właściwości Argumenty debugowania.
Typ danych | Boolean |
Wartość domyślna | fałsz |
Określa argumenty wiersza komend trybu debugowania, które są przekazywane do kodu maszyny JVM uruchamiającej proces serwera aplikacji. Argumenty można określić, gdy właściwość Tryb debugowania jest ustawiona na wartość true (prawda).
Jeśli włączona jest opcja debugowania na wielu serwerach aplikacji w tym samym węźle, sprawdź, czy dla argumentu adresu nie jest ustawiona ta sama wartość. Argument adresu definiuje port używany do debugowania. Jeśli dwa serwery, dla których debugowanie jest włączone, są skonfigurowane tak, że używają tego samego portu debugowania, mogą nie zostać odpowiednio uruchomione. Na przykład oba serwery mogą być skonfigurowane z zastosowaniem tego samego argumentu debugowania adres=7777, który jest domyślną wartością argumentu adresu debugowania.
Jeśli włączona jest opcja debugowania na wielu serwerach aplikacji, sprawdź, czy dla argumentu adresu nie jest ustawiona ta sama wartość. Argument adresu definiuje port używany do debugowania. Jeśli dwa serwery, dla których debugowanie jest włączone, są skonfigurowane tak, że używają tego samego portu debugowania, mogą nie zostać odpowiednio uruchomione. Na przykład oba serwery mogą być skonfigurowane z zastosowaniem tego samego argumentu debugowania adres=7777, który jest domyślną wartością argumentu adresu debugowania.
Typ danych | String |
Jednostki | Argumenty wiersza komend języka Java |
Określa argumenty wiersza komend, które mają być przekazywane do kodu wirtualnej maszyny języka Java uruchamiającego proces serwera aplikacji.
Określ opcję hotRestartSync, aby włączyć funkcję szybkiej synchronizacji restartu w usłudze synchronizacji. Ta funkcja wskazuje usłudze synchronizacji, że instalacja działa w środowisku, w którym aktualizacje konfiguracji nie są przeprowadzane, gdy menedżer wdrażania jest nieaktywny. Dlatego po zrestartowaniu serwera menedżera wdrażania lub agenta węzła nie jest konieczne przeprowadzanie pełnego porównania repozytoriów. Włączenie tej funkcji poprawia efektywność pierwszej operacji synchronizacji po restarcie menedżera wdrażania lub agenta węzła, zwłaszcza w przypadku instalacji zawierających komórki mieszanych wersji, kilka węzłów lub kilka uruchomionych aplikacji.
Ten argument ma zastosowanie tylko w systemie z/OS. Określ argument -Dcom.ibm.CORBA.RequestTimeout=okres_limitu_czasu, aby ustawić limit czasu odpowiedzi na żądania wysyłane przez klienta. Argument ten korzysta z opcji -D. Okres_limitu_czasu to limit czasu w sekundach. Jeśli w sieci występują bardzo duże opóźnienia, należy podać dużą wartość, by zapobiec przekroczeniom limitu czasu. Jeśli podasz zbyt małą wartość, serwer aplikacji uczestniczący w zarządzaniu obciążeniem może przekroczyć limit czasu przed otrzymaniem odpowiedzi.
Ustaw ten argument tylko wtedy, gdy w aplikacji występują problemy z limitami czasu. Nie istnieją zalecane wartości dla tego argumentu.
Ten argument ma zastosowanie tylko w systemie z/OS. Określ argument -Dcom.ibm.websphere.wlm.unusable.interval=okres_limitu_czasu, aby zmienić wartość dla właściwości com.ibm.websphere.wlm.unusable.interval, jeśli stan zarządzania obciążeniem klienta jest odświeżany zbyt wcześnie lub zbyt późno. Ta właściwość określa w sekundach czas, przez który uruchamianie klienta zarządzania obciążeniem czeka od chwili, gdy oznacza ono serwer jako niedostępny, do próby ponownego kontaktu z serwerem. Argument ten korzysta z opcji -D. . Wartością domyślną jest 300 sekund. Jeśli dla właściwości tej zostanie ustawiona zbyt wysoka wartość, serwer zostaje oznaczony jako niedostępny przez długi okres czasu. Zapobiega to odświeżaniu stanu zarządzania obciążeniem klienta przez protokół odświeżania zarządzania obciążeniem, dopóki nie upłynie dany okres czasu.
Ten argument ma zastosowanie tylko w systemie z/OS. Określ argument -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= w celu wskazania, że pamięć masowa dla indywidualnych buforów bezpośrednich bajtów powinna zostać zwolniona w momencie, gdy bufor staje się zbędny. Jedyna obsługiwana wartość dla tego argumentu to com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
Na platformie z/OS konieczne jest także określenie tego argumentu. Ma to miejsce wtedy, gdy określona jest
właściwość niestandardowa zaioFreeInitialBuffers dla kanału TCP w celu
zwolnienia przez ten kanał początkowych buforów odczytu używanych w przypadku
nowych połączeń, tak szybko jak te bufory przestaną być niezbędne dla połączenia.
Technologia Java HotSpot w środowisku Java SE 6 korzysta z adaptacyjnych algorytmów maszyny JVM, które z czasem umożliwiają optymalizację wykonywania kodu bajtowego. Maszyna JVM działa w dwóch trybach, -server (serwer) i -client (klient). W większości przypadków użyj trybu -server zapewniającego efektywniejszy czas wykonywania w dłuższych okresach.
Jeśli używany jest domyślny tryb -client, czas uruchamiania będzie krótszy, a ślad w pamięci mniejszy. Jednak wydajność w dłuższym czasie będzie niższa. Użyj trybu -server, który zwiększa wydajność, chyba że czas uruchamiania serwera jest bardziej istotny niż wydajność. Można monitorować wielkość procesu oraz czas uruchamiania serwera w celu sprawdzenia różnicy między trybami -client i -server.
Określ opcję -Xverify:none, aby zignorować etap weryfikacji klasy podczas ładowania klas. Użycie opcji -Xverify:none powoduje wyłączenie weryfikacji klas języka Java, co umożliwia skrócenie czasu uruchamiania o 10-15 procent. Jednak w przypadku określenia tego argumentu uszkodzone lub niepoprawne klasy danych nie są wykrywane. W przypadku załadowania uszkodzonej klasy danych wirtualna maszyna języka Java może zachowywać się w nieoczekiwany sposób lub może dla niej wystąpić niepowodzenie.
Określ argument -Xnoclassgc, aby wyłączyć czyszczenie pamięci klasy. Użycie tego argumentu prowadzi do większego stopnia ponownego wykorzystania klasy i nieco zwiększa wydajność. Jednak zasoby zajęte przez te klasy są używane nawet wtedy, gdy klasy nie są wywoływane.
Można użyć ustawienia konfiguracji verbose:gc, aby monitorować czyszczenie pamięci. Powstających danych wyjściowych można użyć do określenia wpływu odzyskania tych zasobów na wydajność.
Jeśli podczas ponownego wdrożenia aplikacji zostanie podany argument -Xnoclassgc, należy zrestartować serwer aplikacji w celu wyczyszczenia klas i danych statycznych, które pozostały po poprzedniej wersji aplikacji.
Określ argument -Xgcthreads, aby użyć wielu wątków czyszczenia pamięci równocześnie. Ta technika czyszczenia pamięci jest określana jako równoległe czyszczenie pamięci. Ten argument jest poprawny tylko dla pakietu IBM Developer Kit.
Wpisując tę wartość w polu Ogólne argumenty wirtualnej maszyny języka Java, należy wpisać także liczbę procesorów znajdujących się w komputerze. Jeśli na przykład w komputerze znajdują się trzy procesory, wprowadź wartość -Xgcthreads 3. W węźle z liczbą procesorów wynoszącą n, domyślna liczba wątków wynosi n.
Określ argument -Xnocompactgc, aby wyłączyć kompaktowanie sterty. Kompaktowanie sterty to najbardziej kosztowna operacja przy czyszczeniu pamięci. Używając pakietu IBM Developer Kit, należy unikać kompaktowania sterty. Wyłączając kompaktowanie sterty, eliminujesz cały związany z tym nakład pracy.
Określ argument-Xgcpolicy, aby ustawić strategię czyszczenia pamięci. Ten argument jest poprawny tylko dla pakietu IBM Developer Kit.
Ustaw ten argument na wartość optthruput, aby zoptymalizować przepustowość, jeśli nie występuje problem dotyczący długich przerw w czyszczeniu pamięci. Jest to parametr domyślny, zalecane ustawienie.
W przypadku używania funkcji generacyjnego czyszczenia pamięci ustaw ten argument na wartość gencon. Schemat generacyjny dąży do osiągnięcia wysokiej przepustowości oraz ograniczenia liczby przerw w czyszczeniu pamięci. W tym celu sterta jest dzielona na nowe i stare segmenty. Obiekty o długim czasie życia są awansowane do starego obszaru, natomiast szybkie czyszczenie pamięci obejmujące obiekty o krótkim czasie życia odbywa się w nowym obszarze. Strategia gencon przynosi znaczące korzyści wielu aplikacjom. Nie jest ona jednak odpowiednia dla wszystkich aplikacji i z reguły trudniej ją dostroić.
Ustaw ten argument na wartość optavgpause, aby wykorzystać znaczniki równoległe do śledzenia wątków aplikacji począwszy od stosu przed zapełnieniem sterty. Po określeniu tego parametru pauzy w operacji czyszczenia pamięci stają się ujednolicone, a długie przerwy nie występują. Jednak użycie tej strategii powoduje zmniejszenie przepustowości, ponieważ wątki mogą wykonywać dodatkową pracę.
Ustaw ten argument na wartość subpool, aby podnieść wydajność w systemach wieloprocesorowych (z reguły takich, w których używanych jest ponad osiem procesorów). Ta strategia jest dostępna wyłącznie w procesorach systemów IBM System i, System p oraz System z. Strategia subpool jest podobna do strategii optthruput, z tym że w przypadku strategii subpool sterta jest dzielona na podpule, co umożliwia lepszą skalowalność dla przydzielania obiektów.
Środowisko Java Platform, Standard Edition 6 (Java SE 6) ma funkcję czyszczenia pamięci, co umożliwia występowanie obiektów w różnym wieku w osobnych pulach pamięci. Cykl czyszczenia pamięci gromadzi obiekty niezależnie od siebie według ich wieku. Dzięki dodatkowym parametrom istnieje możliwość indywidualnego ustawienia wielkości pul pamięci. Aby uzyskać lepszą wydajność, ustaw wielkość puli zawierającej obiekty o krótkim czasie życia tak, aby czas życia obiektów w puli nie przekraczał czasu jednego cyklu czyszczenia pamięci. Za pomocą parametrów NewSize i MaxNewSize można określić wielkość nowej puli pokolenia.
-XX:NewSize=dolna_granica -XX:MaxNewSize=górna_granica -XX:SurvivorRatio=nowy_współczynnik
Innym rozwiązaniem jest ustawienie od 50% do 60% łącznej wielkości sterty pamięci na potrzeby nowej puli generowania.
Określ argument -Xminf, aby zmienić minimalny procent wolnego miejsca w stercie. Sterta rośnie, gdy ilość wolnego miejsca jest poniżej podanej ilości. W trybie z włączonym resetowaniem ten argument określa minimalny procent wolnej pamięci dla warstwy pośredniej i sterty przejściowej w procentach. Wartość określona dla tego argumentu jest liczbą zmiennopozycyjną w zakresie 0 do 1. Domyślna wartość wynosi 0,3 (30 procent).
Określ argument -Xshareclasses:none, aby wyłączyć opcję współużytkowania klas dla procesu. Opcja współużytkowania klas, dostępna w środowisku Java SE 6, umożliwia współużytkowanie klas w pamięci podręcznej. Współużytkowanie klas w pamięci podręcznej może skrócić czas uruchamiania i zmniejszyć ślad w pamięci. Z opcji współużytkowania pamięci podręcznej mogą korzystać procesy w rodzaju serwerów aplikacji, agentów węzła i menedżerów wdrażania.
Jeśli korzystasz z tej opcji, powinieneś usuwać zawartość pamięci podręcznej podczas niekorzystania z procesu. Aby usunąć zawartość pamięci podręcznej, wywołaj program narzędziowy app_server_root/bin/clearClassCache.bat/sh lub zatrzymaj proces, a następnie go restartuj.
Typ danych | String |
Jednostki | Argumenty wiersza komend języka Java |
Określa pełną ścieżkę do pliku wykonywalnego JAR, który jest używany przez kod maszyny JVM.
Typ danych | String |
Jednostki | Nazwa ścieżki |
Określa, czy opcja kompilatora JIT ma być wyłączona dla kodu maszyny JVM.
Jeśli wyłączysz kompilator JIT, odczuwalnie obniży się przepustowość. Dlatego, ze względu na wydajność, pozostaw kompilator JIT włączony.
Typ danych | Boolean |
Wartość domyślna | fałsz (kompilator JIT włączony) |
Zalecane | Kompilator JIT włączony |
Określa ustawienia maszyny JVM dla danego systemu operacyjnego.
Kiedy zostaje uruchomiony proces, korzysta on z ustawień wirtualnej maszyny języka Java określonych dla serwera jako ustawienia wirtualnej maszyny języka Java dla systemu operacyjnego.
Kiedy zostaje uruchomiony proces, korzysta on z ustawień wirtualnej maszyny języka Java określonych dla węzła jako ustawienia wirtualnej maszyny języka Java dla systemu operacyjnego.
Zaznaczone odsyłacze (online) wymagają dostępu do Internetu.