Java virtuális gép beállításai

83.29/3724.32 * 100 = 2.236%

Ha az idő több mint 5 százalékát tölti szemétgyűjtéssel, és gyakran történik szemétgyűjtés, akkor érdemes növelni a Java kupacméretet.

A következő módon állapíthatja meg, hogy a lefoglalt kupac növekszik-e: nézze meg, hogy a kupac hány százaléka marad kiosztatlan az egyes szemétgyűjtések után, és ellenőrizze, hogy ez a százalékérték folyamatosan csökken-e. Ha a szabad terület aránya folyamatosan csökken, az azt jelenti, hogy a kupacméret fokozatosan nő minden egyes szemétgyűjtés alkalmával. Ez arra utalhat, hogy az alkalmazásban memóriaszivárgás van.

A -DhotRestartSync megadásával engedélyezhető a szinkronizálási szolgáltatás forró újraindítási szinkronizálás szolgáltatása. Ez a szolgáltatás jelzi a szinkronizálási szolgáltatásnak, hogy a telepítés olyan környezetben fut, ahol a konfigurációs frissítések nem kerülnek végrehajtásra, ha a telepítéskezelő nem aktív. Ezért a szolgáltatásnak nem kell egy teljes lerakatösszehasonlítást végrehajtani, a ha a telepítéskezelő vagy a csomópontügynök kiszolgálók újraindulnak. A szolgáltatás engedélyezése növeli az első szinkronizálási művelet hatékonyságát, miután a telepítéskezelő vagy a csomópontügynök újraindul, különösen olyan környezetekben, amelyek különböző kiadási cellákat tartalmaznak, sok csomópontot használnak, valamint számos alkalmazást futtatnak.

Állítsa ezt a beállítást true értékre, ha engedélyezni kívánja az IBM SDK and Runtime Environment for AIX, Java Technology Edition alkalmazás 7-es változatával biztosított Speciális titkosítási szabvány (AES) funkciót. Az AES szimmetrikus blokkrejtjeleket alkalmaz, amelyek több körben titkosítják és fejtik vissza az adatokat. A funkció engedélyezése teljesítményjavulást eredményezett a WebSphere Application Server SSL feldolgozásában.

Az -Xverify:none paraméter segítségével kihagyható az osztályellenőrzés az osztálybetöltés során. Az -Xverify:none beállítás letiltja a Java osztályellenőrzést, ami 10-15 százalékkal javíthatja az indítási időt. A rendszer azonban nem észleli a sérült vagy érvénytelen osztályadatokat, ha ez a paraméter meg van adva. Sérült osztályadatok betöltése esetén a JVM nem várt módon viselkedhet vagy meghibásodhat.

Hiba elkerülése:

• Ne használja ezt az argumentumot, ha bytekód módosításokat végez, mert a JVM meghibásodhat, ha bármilyen felkészítési hiba történik.
• Ha JVM hibát észlel, vagy a JVM váratlan módon viselkedik, mialatt ez az argumentum érvényben van, akkor a JVM hibakeresés első lépéseként távolítsa el ezt az argumentumot.
• Az IBM i rendszer nem támogatja ezt az argumentumot.

gotcha

Az -Xnoclassgc beállítással letiltható az osztályokra vonatkozó szemétgyűjtés. Az argumentum hatására javul az osztályok újrafelhasználása, és némileg a teljesítmény is. Az osztályok tulajdonában lévő erőforrások azonban akkor is használatban maradnak, ha az osztályokat nem hívják meg.

Hiba elkerülése: Az osztályokra vonatkozó szemétgyűjtés hatása a teljesítményre általában minimális, ha azonban kikapcsolja a szemétgyűjtést Java platform, Enterprise Edition (Java EE) alapú rendszeren, mely sokat használja az alkalmazás osztálybetöltőket, akkor ténylegesen létrejöhet az osztályadatok memóriaszivárgása, melynek hatására a JVM Out-of-Memory (elfogyott a memória) kivételt dobhat.gotcha

A verbose:gc konfigurációs beállítás segítségével megfigyelheti a szemétgyűjtést. A keletkező kimenet alapján megállapítható, hogy milyen hatást gyakorol a teljesítményre az erőforrások visszaigénylése.

A -Xnoclassgc argumentum megadása esetén az alkalmazás korábbi verziójához tartozó osztály és statikus adatok törléséhez mindig indítsa újra az alkalmazáskiszolgálót, ha újratelepített egy alkalmazást.

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot. Ezen a platformon a -noclassgc argumentum segítségével kell letiltani a szemétgyűjtést.gotcha

Az -Xgcthreads segítségével egyszerre több szemétgyűjtő szál is használható. Ezt a szemétgyűjtési eljárást párhuzamos szemétgyűjtésnek is nevezik. Ez az argumentum csak az IBM Developer Kit esetén érvényes.

Ha megadja ezt az értéket az Általános JVM argumentumok mezőben, akkor adja meg a gépben levő processzorok számát is.

Adja meg az -Xgcthreads elemet az alábbiak szerint:

-Xgcthreads<processzorok
száma>

Hiba elkerülése: Ne tegyen szóközt az --Xgcthreads és a processzorok n értéke közé.

Az -Xgcthreads5 egy példa az -Xgcthreads megadására 5 processzorral.

gotcha

Követendő eljárás: Ha a gépben több processzor található, akkor alkalmazzon párhuzamos szemétgyűjtést.bprac

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot.gotcha

Az -Xnocompactgc beállítással letiltható a kupactömörítés. A kupac tömörítése a legdrágább szemétgyűjtési művelet. IBM Developer Kit használata esetén kerülje a kupac tömörítését. Ha letiltja a kupac tömörítését, akkor megszünteti az összes ehhez kapcsolódó többletterhelést.

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot.gotcha

Az -Xgcpolicy argumentummal megadható a szemétgyűjtési irányelv. Ez az argumentum csak az IBM Developer Kit esetén érvényes.

Az argumentumot optthruput értékre állítva optimalizálhatja a teljesítményt, és nem keletkezik probléma a hosszú szemétgyűjtési szünetek esetén.

Állítsa az argumentumot gencon értékre, ha generációs szemétgyűjtőt használ. Ez a generációs séma megkísérel magas teljesítményértéket elérni csökkentett szemétgyűjtési szünetek mellett. Ezen cél eléréséhez a kupac új és régi szegmensekre kerül felosztásra. A régóta fennálló objektumok a régi területre kerülnek, míg az újabb objektumokra vonatkozóan gyorsan elvégzésre kerül a szemétgyűjtés az új területen. Ez a gencon irányelv jelentős előnyöket biztosít sok alkalmazás számára. Nem megfelelő azonban minden alkalmazás esetén, és általában nehezebb a behangolása.

Az argumentumot állítsa optavgpause értékre, ha párhuzamos jelölést akar használni a veremből induló alkalmazásszálak követésére, mielőtt a kupac megtelne. Ha ez a paraméter meg van adva, akkor a szemétgyűjtések közti szünetek egyenletessé válnak, és nincsenek hosszú várakozások. Azonban az irányelv használata csökkentheti a teljesítményt, mivel a szálakra több munka hárulhat.

Állítsa ezt az argumentumot subpool értékre, ha növelni akarja a teljesítményt a többprocesszoros rendszereken, amelyek általában több, mint nyolc processzort használnak. Ez az irányelv csak IBM System i, System p és System z processzoroknál érhető el. A subpool irányelv hasonló a optthruput irányelvhez, kivéve, hogy a kupac alkészletekre kerül felosztásra, ami fejlettebb méretezhetőséget biztosít az objektumkiosztáshoz.

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot.gotcha

A Java Platform, Standard Edition 6 (Java SE 6) generációs szemétgyűjtéssel rendelkezik, ami lehetővé teszi, hogy külön memóriatárakba kerüljenek a különböző korú objektumok. A szemétgyűjtő az egymástól eltérő korú objektumokat egymástól függetlenül gyűjti be. További paraméterekkel az egyes memóriatárak mérete külön állítható. A jobb teljesítmény érdekében úgy állítsa be a rövid életciklusú objektumokat tartalmazó tár méretét, hogy az abban tárolt objektumokat ne őrizze meg egy szemétgyűjtési ciklusnál tovább. Az új generációs tár méretének meghatározásához használja a NewSize és a MaxNewSize paramétereket.

-XX:NewSize=alsó_határ 
-XX:MaxNewSize=felső_határ
 -XX:SurvivorRatio=új_arány_mérete 

Követendő eljárás: Ha azonban a JVM kupacmérete 1 GB-nál nagyobb, akkor használja az alábbi értékeket:

• -XX:NewSize=640m
• -XX:MaxNewSize=640m
• -XX:SurvivorRatio=16

bprac

Ennek alternatívájaként beállíthatja a teljes kupacméret 50-60 százalékát az új generációs tárnak.

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot.gotcha

Az -Xminf paraméter segítségével módosíthatja a minimális szabad kupacméret arányát. Ha a szabad terület a megadott érték alá megy, akkor a kupac megnő. Visszaállítás engedélyezése módban ez az argumentum meghatározza a szabad terület minimális arányát a köztes és az átmeneti kupacok számára. Az argumentum értéke egy 0 és 1 közötti lebegőpontos szám. Az alapérték .3 (30%).

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot.gotcha

A Java SE 6 kiadásban alkalmazott Java HotSpot technológia bevezet egy adaptív Java virtuális gépet, amely a bytekód végrehajtását futás közben optimalizálni képes algoritmusokat tartalmaz. A JVM két módban futhat: -server és -client módban. A legtöbb esetben a -server mód használandó, amely hatékonyabb futás közbeni teljesítményt biztosít hosszú időn keresztül.

Az alapértelmezett -client mód használatával rövidebb lesz a kiszolgáló indítási ideje, és kisebb lesz a memóriaigény. Ez a mód azonban csökkenti a hosszútávú teljesítményt. Inkább a -server módot használja, ami javítja a teljesítményt, kivéve ha a kiszolgáló indítási ideje fontosabb mint a teljesítmény. Ha kíváncsi a -client és a -server mód közötti teljesítménykülönbségre, akkor figyelje meg a folyamat méretét és a kiszolgáló indulási idejét.

Hiba elkerülése: Az IBM i rendszer nem támogatja ezt az argumentumot.gotcha

A -Dcom.ibm.CORBA.RequestTimeout=időkorlát argumentum segítségével meghatározhatja az ügyfelektől jövő kérésekre adott válasz időkorlátját. Ez az argumentum a -D paramétert használja. Az időkorlát az időtúllépés értéke másodpercben. Ha a használt hálózaton nagyobb várakozási idő tapasztalható, akkor adjon meg egy nagyobb értéket, hogy megelőzze az időtúllépéseket. Ha túl kicsi értéket ad meg, akkor egy terheléskezelésben résztvevő alkalmazáskiszolgáló átlépheti az időkorlátot, mielőtt megkapná a választ.

Csak akkor adja meg ezt a paramétert, ha az alkalmazásban időtúllépési problémákat tapasztal. Ennek az argumentumnak nincs javasolt értéke.

A -Dcom.ibm.server.allow.sigkill=true paraméter lehetővé teszi a csomóponti ügynökfolyamat számára, hogy egy folyamat lezárási metódusát alkalmazza, ha a leállítási metódus nem fejeződik be a Ping időköz számára megadott időtartam alatt. Ez a beállítás akkor hasznos, amikor a csomóponti ügynök egy alkalmazáskiszolgálót figyel meg, és elveszti a kapcsolatot azzal az alkalmazáskiszolgálóval.

Amikor az alkalmazáskiszolgáló megfigyelési irányelve lehetővé teszi a csomóponti ügynök számára az alkalmazáskiszolgáló újraindítását, mert az automatikus újraindítás engedélyezett az alkalmazáskiszolgáló, a csomóponti ügynök végrehajtja a leállítási metódust az alkalmazáskiszolgáló folyamaton. A leállítási folyamat során a csomóponti ügynök megfigyeli az alkalmazáskiszolgálót, és ha az alkalmazáskiszolgáló nem áll le a Ping időköz számára megadott időtartam alatt, továbbá a paraméter az alapértelmezett true értékre van beállítva, akkor a csomóponti ügynök az alkalmazáskiszolgáló folyamat leállításához végrehajtja azon a lezárási metódust.

Ha a paramétert false értékre állítja be, a csomóponti ügynök folytatja a leállítási folyamat megfigyelését, de nem próbálja újraindítani az alkalmazáskiszolgálót.

A paraméter adminisztrációs konzollal történő tiltásához kattintson a Rendszeradminisztráció > Csomóponti ügynökök >csomóponti_ügynök_neve > Java & Folyamatkezelés > Folyamatmeghatározás > Java virtuális számítógép > Általános JVM paraméterek elemre.

Ez az argumentum azoknak az időpontoknak a maximális számát adja meg, amikor egy riasztás jelenti a teljes verem nyomkövetését a rendszernapló felfüggesztett szálú üzeneteiben.

Ha a rendszer riasztási szála hosszabb ideig aktív, mint a riasztási szál megfigyelési küszöbértéke, akkor az alkalmazáskiszolgáló egy felfüggesztett szálú üzenetet naplóz a riasztási szál nevével, az időtartammal, amíg a riasztási szál aktív volt, illetve a teljes verem kivétel nyomkövetéssel. A teljes verem nyomkövetése a késleltetés okának hibakeresésekor hasznos, de ha gyakran kerülnek aktiválásra felfüggesztett szálú üzenetek, akkor az ismételt hosszú üzenetek más információkat is adhatnak a rendszernaplókba, amelyeket nehéz megtalálni. Ezt az argumentumot egy nullánál nagyobb egész számra állítsa be az időpontok maximális számának megadásához, amikor egy riasztás jelenti a teljes verem nyomkövetését. A küszöbérték elérése után minden egyes soron következő felfüggesztett szál üzenet csak a felfüggesztett riasztás kezelő bejegyzését tartalmazza.

A 0 alapértelmezett érték azt jelzi, hogy egy riasztás minden felfüggesztett szál üzenete tartalmazza a teljes verem nyomkövetést.

Ezt az argumentumot az időpecsét és a szálazonosító hozzáadásához adja meg az összes kiszolgáló hibakeresési üzenet előtt, amely a native_stdout és a native_stderr naplófájl kimenete. Az időpecsét és a szálazonosító segítségével korrelálhatja az alkalmazáskiszolgáló betöltési összetevőinek viselkedéseit a többi kiszolgálómechanizmus viselkedésével, amelyek a SystemOut és a SystemErr naplófájlban vannak jelezve. Ez a viselkedés alapértelmezésben tiltott.

Ha a kiszolgáló egy -Dws.ext.debug=true általános JVM argumentummal van konfigurálva, akkor hibaüzeneteket bocsát ki a sorozat betöltése során a native_stdout.log és a native_stderr.log fájlba. Ha a -Dcom.ibm.websphere.native.logging.timestamp is true értékre van beállítva, akkor a kiszolgáló a hibakeresési üzeneteket az időpecséttel és a szálazonosítóval írja ki, ahogy a következő példában látható:

[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

Ez az argumentum csak z/OS platformon érvényes. A -Dcom.ibm.websphere.wlm.unusable.interval=időkorlát paraméter segítségével megváltoztathatja a com.ibm.websphere.wlm.unusable.interval tulajdonság értékét, ha az ügyfél terheléskezelési állapota túl korán vagy túl későn frissül. Ez a tulajdonság megadja, hogy a terheléskezelő ügyfél hány másodpercig várjon azt követően, hogy egy kiszolgálót elérhetetlennek nyilvánít, mielőtt újra megpróbálna csatlakozni a kiszolgálóhoz. Ez az argumentum a -D paramétert használja. Az alapértelmezett érték 300 másodperc. Ha a tulajdonság értéke túl nagy, akkor a kiszolgáló hosszabb ideig lesz elérhetetlennek jelölve. Ez megakadályozza, hogy a terhelésirányítás frissítési protokollja frissítse az ügyfél terhelésirányítási állapotát, amíg az időtartam nem ér véget.

Ez az argumentum csak z/OS platformon érvényes. A -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= argumentummal megadható, hogy az egyes közvetlen bytepuffereket fel kell szabadítani, amint a pufferre már nincs szükség. Az argumentum egyetlen támogatott értéke: com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.

-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl

z/OS platformon is meg kell adni ezt az argumentumot, ha használja a TCP csatorna zaioFreeInitialBuffers egyéni tulajdonságát, annak érdekében, hogy a csatorna felszabadítsa az új kapcsolatok által használt kezdeti olvasási puffereket, ha a kapcsolatnak már nincs szüksége rájuk.

Megadja, hogy a SIP megfelelés ellenőrzése engedélyezett-e a SIP megbízott kiszolgálón. A SIP megfelelés ellenőrzése biztosítja, hogy a SIP üzenetek megfeleljenek a Munkamenet kezdeményezési protokollnak. Ha a tulajdonság értéke true (igaz), akkor a SIP megfelelés ellenőrzése engedélyezett.

Hiba elkerülése: Ha a megbízott kiszolgálót z/OS WebSphere Application Server, Network Deployment környezetben futtatja, és a megbízott kiszolgáló nem fürt része, akkor használhatja az isSipComplianceEnabled SIP megbízott kiszolgáló egyéni tulajdonságot a SIP megfelelés ellenőrzésének engedélyezéséhez vagy letiltásához az adott megbízott kiszolgálón. Ha azonban önálló alkalmazáskiszolgálót futtat, vagy a megbízott kiszolgáló egy fürt része, akkor az alábbi általános JVM argumentumot kell használnia a SIP megfelelés ellenőrzés engedélyezéséhez és letiltásához.gotcha

Az -Xshareclasses:none argumentum használatával letiltható az osztálymegosztás a folyamatra vonatkozóan. Az osztályok megosztása beállítás, amely elérhető a Java SE 6 változatban, lehetővé teszi az osztályok megosztását a gyorsítótárban. Egy gyorsítótárban az osztályok megosztása gyorsíthatja az indítási időt és csökkentheti a memória erőforrásigényét. A folyamatok, úgymint az alkalmazáskiszolgálók, csomópont ügynökök és telepítéskezelők használhatják az osztálymegosztás lehetőséget.

A beállítás használatakor ürítse ki a gyorsítótárat, amikor a folyamat nincs használatban. A gyorsítótár kiürítéséhez hívja meg a(z) app_server_root/bin/clearClassCache.bat/sh segédprogramot, vagy állítsa le, majd indítsa újra a folyamatot.

Hiba elkerülése:

• Az IBM JVM for J2SE 5 a Solaris, HP és IBM i rendszereken nem támogatott.
• Az alkalmazáskiszolgáló folyamatban futó Java EE alkalmazásosztályok nem kerülnek hozzáadásra a megosztott osztálygyorsítótárhoz.

gotcha

Az -XXallowvmshutdown:false paraméter használatával visszatérhet a JVM egy olyan korábbi viselkedésére, ami nem helyes. A Java 5.0 SR10 és a Java 6 SR5 olyan problémákat javítanak ki, amelyek esetében a Java virtuális gép (JVM) nem fut megfelelően. Ha olyan alkalmazással rendelkezik, amely a régi viselkedésen alapul, akkor a paramétert az Általános JVM paraméterekhez felvéve visszaállhat a korábbi viselkedésre.