można wprowadzić następujące opcjonalne argumenty wiersza komend. Jeśli
wpisujesz więcej niż jeden argument, rozdzielaj poszczególne argumenty spacją.
![[z/OS]](../ngzos.gif)
![[AIX Solaris HP-UX Linux Windows]](../dist.gif)
-DhotRestartSync: Określ opcję -DhotRestartSync, 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.
![[8.5.0.1 or later]](../images/ng_v8501.gif)
-Dcom.ibm.crypto.provider.doAESInHardware: Tę opcję należy ustawić na wartość true (prawda), aby
włączyć funkcję AES (Advanced Encryption Standard) dostarczoną z produktem IBM
SDK and Runtime Environment for AIX, Java
Technology Edition 7. Funkcja AES to symetryczny szyfr blokowy, który szyfruje
i deszyfruje dane w kilku rundach. Włączenie tej funkcji ma spowodować poprawę
wydajności w przetwarzaniu protokołu SSL produktu
WebSphere Application Server.
- -Xquickstart
Określ opcję
-Xquickstart, aby użyć
początkowej kompilacji na poziomie optymalizacji niższym niż w trybie domyślnym. Później,
w zależności od wyników próbkowania, można ponownie kompilować na poziom początkowej
kompilacji w trybie domyślnym.
Sprawdzona procedura: Użyj opcji
-Xquickstart w przypadku aplikacji, w których wczesna
umiarkowana prędkość jest ważniejsza niż przepustowość w dłuższym okresie. W określonych scenariuszach debugowania,
zastosowaniach testowych i krótko działających narzędziach, czas uruchamiania można poprawić w granicach
15-20 procent.
bprac![[IBM i]](../iseries.gif)
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- -Xverify:none
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.
Unikanie problemów: - Nie używaj tego argumentu w przypadku wprowadzania modyfikacji kodu bajtowego,
ponieważ w przypadku jakiegokolwiek błędu instrumentacji może wystąpić niepowodzenie wirtualnej maszyny języka Java.
- W przypadku wystąpienia błędu wirtualnej maszyny języka Java lub jej nieoczekiwanego zachowania
po ustawieniu tego argumentu, usuń ten argument w pierwszym kroku
debugowania problemu dotyczącego wirtualnej maszyny języka Java.
- System IBM i nie obsługuje tego argumentu.
gotcha
- -Xnoclassgc
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.
Unikanie problemów: Czyszczenie pamięci klas ma z reguły niewielki wpływ na wydajność, a wyłączenie
funkcji czyszczenia pamięci klas w systemie używającym platformy Java Platform,
Enterprise Edition (Java EE), w którym są intensywnie używane programy ładujące
klasy aplikacji, może spowodować przeciek pamięci danych klas i wywołać w
maszynie JVM wyjątek Brak pamięci.
gotcha
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.
Unikanie problemów: System IBM i nie obsługuje tego argumentu. Aby wyłączyć czyszczenie pamięci klasy na tej platformie, należy użyć argumentu
-noclassgc.
gotcha
- -Xgcthreads
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.
Argument
-Xgcthreads należy
określić w następujący sposób:
-Xgcthreads<liczba_procesorów>
Unikanie problemów: Nie
należy dodawać spacji między argumentem -
-Xgcthreads a wartością
n
oznaczającą liczbę procesorów.
Przykładowy argument -Xgcthreads z określeniem 5
procesorów: -Xgcthreads5.
gotcha
Sprawdzona procedura: Równoległe czyszczenie
pamięci powinno być użyte wtedy, gdy komputer ma więcej niż jeden procesor.
bprac
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- -Xnocompactgc
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.
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- -Xgcpolicy
Określ
argument-Xgcpolicy, aby
ustawić strategię czyszczenia pamięci. Ten argument jest poprawny tylko dla
pakietu IBM Developer Kit.
Temu argumentowi należy nadać wartość
optthruput![[Updated in September 2013]](../images/delta.gif)
, aby zoptymalizować
przepustowość i wyeliminować problem dotyczący długich przerw w czyszczeniu
pamięci.![[Updated in September 2013]](../images/deltaend.gif)
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 tylko dla procesoró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.
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- -XX
Środowisko Java Platform, Standard Edition
6 (Java SE 6) ma funkcję generacyjnego 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.
Obiekty, które
pozostają po pierwszym cyklu czyszczenia pamięci są przenoszone do następnej
puli. Parametr
SurvivorRatio
umożliwia określenie puli obiektów pozostałych.
SurvivorRatio. Do
monitorowania statystyk czyszczenia pamięci można użyć statystyki obiektów
gromadzonej przez przeglądarkę Tivoli Performance Viewer lub użyć argumentu
verbose:gc w ustawieniach konfiguracji. Jeśli czyszczenia pamięci staje się wąskim gardłem, określ następujące
argumenty, aby dostosować ustawienia puli pokolenia w celu ich lepszego dostosowania do środowiska.
-XX:NewSize=dolna_granica
-XX:MaxNewSize=górna_granica
-XX:SurvivorRatio=nowy_współczynnik
Wartości
domyślne to:
- NewSize=2m
- MaxNewSize=32m
- SurvivorRatio=32
Sprawdzona procedura: Jeśli jednak wielkość sterty maszyny JVM
jest większa niż 1 GB, to powinny zostać użyte następujące wartości:
- -XX:NewSize=640m
- -XX:MaxNewSize=640m
- -XX:SurvivorRatio=16
bprac
Innym rozwiązaniem jest ustawienie od 50% do 60% łącznej wielkości sterty pamięci
na potrzeby nowej puli generowania.
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- -Xminf
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).
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- Server a klient
Technologia Java HotSpot
Technology 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.
Unikanie problemów: System IBM i nie obsługuje tego argumentu.
gotcha
- -Dcom.ibm.CORBA.RequestTimeout=okres_limitu_czasu
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.
- -Dcom.ibm.server.allow.sigkill=true
Argument
-Dcom.ibm.server.allow.sigkill=true umożliwia procesowi agenta węzła przerwanie
wykonywania metody
procesu, jeśli metoda zatrzymywania nie zostanie zakończona w czasie określonym przez parametr
Odstęp
czasu między uruchomieniami komendy ping. To
ustawienie jest przydatne, jeśli agent węzła monitoruje serwer aplikacji i utraci kontakt z
tym serwerem aplikacji.
Jeśli strategia monitorowania serwera aplikacji umożliwia agentowi
węzła zrestartowanie serwera aplikacji, ponieważ opcja automatycznego restartowania jest
włączona dla serwera aplikacji, agent węzła wykona metodę zatrzymywania dla procesu serwera
aplikacji. Podczas przetwarzania metody zatrzymywania agent węzła monitoruje serwer aplikacji i
jeśli nie zostanie on zatrzymany w czasie określonym przez parametr
Odstęp
czasu między uruchomieniami komendy ping, a ten argument ma wartość true
(wartość domyślna), agent węzła wykona metodę przerywania dla procesu serwera aplikacji w celu jego
zatrzymania.
Jeśli ten argument zostanie ustawiony na wartość
false, agent węzła kontynuuje monitorowanie procesu zatrzymywania, lecz nie
próbuje zrestartować serwera aplikacji.
Aby wyłączyć ten argument przy użyciu Konsoli
administracyjnej, należy kliknąć opcję Administrowanie systemem
> Agenty węzłów > nazwa_agenta_węzła > Język Java
i zarządzanie procesami > Definicja procesu > Wirtualna maszyna języka Java > Ogólne
argumenty wirtualnej maszyny języka Java.
- -Dcom.ibm.websphere.alarmthreadmonitor.hung_alarm_mute=
Ten argument określa maksymalną liczbę pełnych stosów wywołań raportowanych
przez alarm w komunikatach o zawieszonym wątku w dziennikach systemowych.
Gdy wątek alarmu systemowego jest aktywny dłużej niż wynosi
próg monitora wątku alarmu, serwer aplikacji rejestruje komunikat o zawieszeniu
wątku z nazwą wątku alarmu, czasem trwania aktywności wątku alarmu oraz pełnym
stosem wywołań wyjątków. Pełny stos wywołań jest przydatny przy debugowaniu
przyczyny opóźnienia, ale jeśli komunikaty o zawieszeniu wątku są często
wyzwalane, powtórzone długie komunikaty mogą utrudnić znalezienie w dziennikach
systemowych innych informacji. Należy ustawić ten argument na
wartość całkowitą większą od 0, aby określić maksymalną liczbę pełnych
stosów wywołań raportowanych przez jeden alarm. Po osiągnięciu tej wartości
progowej każdy kolejny komunikat o zawieszeniu wątku będzie zawierać tylko wpis
procedury obsługi alarmu dotyczącego zawieszenia.
Wartość domyślna
wynosząca 0 wskazuje, że wszystkie komunikaty o
zawieszonym wątku dla alarmu będą zawierać pełny stos wywołań.
Uwaga: Ta właściwość określa próg dla każdej klasy procedury obsługi alarmu,
a nie dla łącznej liczby komunikatów ani dla każdej instancji procedury
obsługi alarmu.
- -Dcom.ibm.websphere.native.logging.timestamp=true
Ten argument należy podać, aby przed wszystkimi komunikatami debugowania
serwera wyprowadzanymi do plików dziennika native_stdout i native_stderr był
dodawany znacznik czasu i identyfikator wątku. Znacznika czasu i identyfikatora
wątku można użyć w celu skorelowania zachowań komponentów programu startowego
serwera aplikacji z zachowaniami innych mechanizmów serwera wskazanymi w
plikach dziennika SystemOut oraz SystemErr. Domyślnie to zachowanie jest wyłączone.
Gdy serwer jest skonfigurowany z ogólnym argumentem maszyny JVM
-Dws.ext.debug=true, podczas sekwencji startowej wysyła komunikaty
debugowania do plików dziennika native_stdout.log oraz native_stderr.log. Jeśli
właściwość -Dcom.ibm.websphere.native.logging.timestamp
również ma wartość true, komunikaty debugowania
wyprowadzane przez serwer zawierają znacznik czasu i identyfikator wątku, jak
przedstawiono w przykładzie poniżej:
[6/18/12 16:24:31:453 CDT] 00000000
ws.ext.mains.args[0]=-nosplash
[6/18/12 16:24:31:453 CDT] 00000000
ws.ext.mains.args[1]=-application
[6/18/12 16:24:31:453 CDT] 00000000
ws.ext.mains.args[2]=com.ibm.ws.bootstrap.WSLauncher
[6/18/12 16:24:31:453 CDT] 00000000
ws.ext.mains.args[3]=com.ibm.ws.runtime.WsServer
Uwaga: Właściwość
-Dws.ext.debug=true należy podawać wyłącznie pod nadzorem pracowników
działu wsparcia IBM.
- -Dcom.ibm.websphere.wlm.unusable.interval=okres
Ten argument ma zastosowanie tylko dla systemu 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ść domyślna wynosi
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.
- -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=
Ten argument ma zastosowanie tylko dla systemu 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.
Bezpośrednie
bufory bajtów tworzone przez maszynę JVM do obsługi danych żądań są
przydzielane do sterty środowiska Language
Environment (LE), a nie do sterty maszyny JVM. Zwykle,
zwłaszcza gdy bezpośrednie bufory bajtów nie są już niezbędne, wirtualna maszyna
języka Java nie uwalnia rodzimej pamięci masowej środowiska LE aż do momentu
wystąpienia czyszczenia pamięci. Jeśli serwer obsługuje duże żądania,
pamięć masowa środowiska LE może zostać wyczerpana, zanim maszyna JVM
uruchomi cykl czyszczenia pamięci, co może spowodować nieoczekiwane
zakończenie działania serwera (abend). Skonfigurowanie wirtualnej maszyny języka Java przy użyciu następującego argumentu
zapobiega występowaniu tych nieoczekiwanych zakończeń działania.
-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.
- -DisSipComplianceEnabled=true|false
Określa,
czy na serwerze proxy SIP włączono sprawdzanie zgodności z protokołem
SIP.
Sprawdzanie zgodności z protokołem SIP pozwala zapewnić, że
komunikaty SIP są dostosowane do standardu Session Initiation Protocol (SIP).
Gdy ta właściwość ma wartość true, sprawdzanie zgodności
z protokołem SIP jest włączone.
Unikanie problemów: Jeśli serwer proxy jest uruchomiony w
środowisku z/OS
WebSphere Application Server, Network Deployment i nie jest on częścią klastra, można użyć właściwości
niestandardowej serwera proxy SIP isSipComplianceEnabled w celu włączenia lub
wyłączenia sprawdzania zgodności z protokołem SIP dla danego serwera proxy SIP.
W przypadku korzystania z autonomicznego serwera aplikacji (lub jeśli używany
serwer proxy jest częścią klastra) w celu włączenia lub wyłączenia sprawdzania
zgodności z protokołem SIP należy użyć ogólnego argumentu maszyny JVM.
gotcha
- -Xshareclasses:none
Określ argument
-Xshareclasses:none, aby wyłączyć opcję współużytkowania klas dla
procesu. Opcja współużytkowania klas, która jest 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.
Uwaga: W przypadku używania programu clearclasscache do
wyczyszczenia całej pamięci podręcznej należy zatrzymać wszystkie przyłączone
maszyny JVM.
Unikanie problemów: ![[Solaris]](../solaris.gif)
![[HP-UX]](../hpux.gif)
Produkt IBM JVM for J2SE 5 nie jest
obsługiwany w systemach Solaris, HP oraz IBM i.- Klasy aplikacji Java EE działające w procesach serwera aplikacji nie są
dodawane do pamięci podręcznej współużytkowanych klas.
gotcha
- -XXallowvmshutdown:false
Argumentu -XXallowvmshutdown:false należy użyć,
aby przywrócić poprzednie zachowanie dla niepoprawnej maszyny JVM.
Pakiety poprawek Java 5.0 SR10 i Java 6 SR5
usuwają problemy, które powodują, że wirtualna maszyna języka Java nie jest
zamykana poprawnie. Jeśli używana jest aplikacja, która zależy od starego zachowania, można
przywrócić poprzednie zachowanie, dodając ten argument w sekcji Ogólne argumenty wirtualnej maszyny
języka Java.
Dla przenoszenia użytkowników: