JBossDeveloper

JBossAS hangolása és karcsúsítása

a JBoss 3.2.6 alapján

FELÜLVIZSGÁLVA A 4.0.4+ JBoss4Slimming verzióhoz

Előszó

Ez a tanács elsősorban a JBossAS hangolására és/vagy karcsúsítására vonatkozik. A két fogalom a legtöbb esetben merőleges. Bár a tétlen szolgáltatási szálak karcsúsítással történő csökkentése nem lesz nagy hatással a teljesítményre, a kevesebb memória és erőforrás használata lehetővé teheti más teljesítmény-szempontok hangolását. Természetesen ez csökkenti az indítási időt. Ezenkívül általános biztonsági koncepcióként távolítsa el azokat a szolgáltatásokat, amelyeket nem használ. Különválasztjuk a két kategóriát: karcsúsító és tuningoló. Először az alapértelmezett konfigurációt és az onnan történő vágást használjuk (fürtözéshez, amely egy későbbi wiki oldal témája lesz). Ez a tanács nem foglalja magában a fejlesztő és az adminisztrátori szerepkörök közötti átmetszés területeit (az alkalmazások hangolása, például a gyorsítótár méretei). Ez elsősorban tanács az adminisztratív hangoláshoz.

Megjegyzés az érintettek számára: ez a tanács technikailag nem J2EE-kompatibilis JBoss-példányt hoz létre (a 3.2.6 így sem felel meg), mivel a J2EE kulcsszolgáltatások eltávolításával a JBoss meghiúsul a TCK-val. A valós installációkban elvégzett teljesítmény-hangolási/adminisztrációs feladatok többsége technikailag ebbe a kategóriába tartozik.

Tegyük fel, hogy a szerver/alapértelmezett könyvtárat és annak alkönyvtárait átmásolta a server/slim könyvtárba.

Hangolás

Java virtuális gép

Használjon 64 bites gépet és 64 bites virtuális gépet, hogy nagy, általában 2-4 GB-nál nagyobb méretű kupacokat használhasson. 64 bites támogatás érhető el az összes legújabb SPARC/Solaris dobozon, amely futtatja a Solaris 9-et vagy újabbat, az Itanium JDK 1.4-gyel vagy a JDK 5-et Linux x64-en.

NE HASZNÁLJA a -d64-et (64 bites), ha nem használja a FELETT maximális 32 bites halomterületet (2–4 GB halom). A 64 bites címzés használata TÖBB memóriát igényel ugyanolyan munka elvégzéséhez, és nem jelent előnyt azoknak az alkalmazásoknak, amelyeknek nincs szüksége ekkora memóriára.

Kerülje az extra nagy halmokat, de kerülje az extra kis halmokat. (Nem tudjuk megmondani, mi minősül, mert ez attól függ, hogy mit csinálsz). Ez kihat a generációs szemétgyűjtésre és a kupac átvizsgálásának teljes idejére. Nehéz egy kis kupacot hatékonyan hangolni (még akkor is, ha az alkalmazás csak 200 MB-ot használ, ha párhuzamos szemétgyűjtést + CMS-t használ, akkor jóval 512 MB-ra lesz szüksége). A nagyméretű halmok felesleges időt töltenek a memória átkutatásával a szemétgyűjtés érdekében.

Kerülje a Nap 1,4 virtuális gépet. A JDK 5 végképp jobb, különösen a szemétszállítás területén.

Használja a -server opciót, de használja az -XX egyikét: ThreadStackSize = 128k (Solaris) vagy -Xss128k (minden más platform). A Solaris -Xss128k készüléken nem csinál semmit (csak a LARGER szálköteg méretét állíthatja be). Ez lehetővé teszi, hogy több szálat hozzon létre kevesebb szálonkénti memória felhasználásával, de rendkívül rekurzív kóddal fújt kötegeket eredményezhet. Ennek ellenére a 128 ezer köteg még mindig semmi, amivel botot lehet rázni.

Ahhoz, hogy ezt megfelelően beállítsd, valóban meg kell értened a generációs szemétgyűjtőket, és valóban meg kell vizsgálnod a terhelést (OpenSTA, JMeter stb.), Hogy biztosan tudd.

Valójában többprocesszoros gépet kell használnia, több mint 2 processzorral, és különféle párhuzamos és egyidejű szemétgyűjtési lehetőségeket kell használnia (ezt az Advanced JBoss Training tipp tippjében tárgyaljuk) a maximális teljesítmény és a magas szemétszállítási teljesítmény érdekében. Ahhoz azonban, hogy ezt jól hangolhassa, meg kell értenie, hogyan működik a szemétszállítás. A JDK 5 többnyire önhangoló.

A JDK 1.4 alapértelmezett NewSize nem jó tipp. Rossz ökölszabály: JBoss/Java Linuxon

Ha JBoss AS-t futtat Linux szerveren, olvassa el ezt a cikket, amelyet Andrew Oliver, a JBoss egyik munkatársa, a Red Hat részlege tanácsadói írtak arról, hogyan hangolják a JBoss/Java-t egy Linux-kiszolgálón.

Kandúr

Szerkessze a szerverét/slim/jbossweb-tomcat5? .Sar/server.xml

Ellenőrizze az XML dokumentumot, hogy vannak-e csatlakozók. Például a HTTP-csatlakozó:

Elegendő szálnak (maxThreads) kell lennie ahhoz, hogy kezelje (ökölszabály) 25% -kal többet, mint a várt maximális terhelés (egyidejűleg egyszerre érkező találatok)

A minSpareThreads-nek csak valamivel nagyobbnak kell lennie, mint a normál terhelésnek

A maxSpareThreads-nek csak valamivel nagyobbnak kell lennie, mint a csúcsterhelése

azt jelenti, hogy "induláskor legalább ennyi szálat tétlenül várjon"

jelentése: "ha valaha a minSpareThreads fölé megyünk, akkor a maxSpareThreads mindig tétlenül marad"

Távolítsa el a felesleges szelepeket és a naplózást. Ha nem a JBoss biztonságát használja, távolítsa el a biztonsági szelepet (lásd alább).

JSP előfordítása. (A beépített fordító meglehetősen gyors, lehet, hogy nem éri meg a kis webhelyeket.)

Kapcsolja ki a "fejlesztés" módot a sever/slim/jbossweb-tomcat50.sar/conf/web.xml fájlban

JBoss 4.0.5 esetén:

A fejlesztési mód letiltása a Tomcat programban:

Szerkessze a $ JBOSS_HOME/server/slim/deploy/jbossweb-tomcat55.sar/conf/web.xml fájlt, és keresse meg a jsp

Hozzáadás:

RMI távoli meghívásokhoz

Alapértelmezés szerint a JBoss minden bejövő RMI kéréshez új szálat hoz létre. Ez általában nem hatékony egy nagy rendszerben. Másodszor, veszélyes lehet a korlátlan kapcsolatok engedélyezése teljesítmény, forgalmi csúcsok vagy elfutott kapcsolat létrehozó ügyfelek esetén. Ennek orvoslásához fontolóra kell vennie az összevont invokerre való átállást.

Az összes proxy-kötést módosítsa az összesített invokerre azáltal, hogy megváltoztatja az összes XML-töredék olvasását:

A JBoss rendelkezik egy többnyire dokumentáció nélküli PooledInvokerHA-val is, amelyet kipróbálhat.

Log4j

A naplózás mély hatást gyakorol a teljesítményre. Ha a naplózási szintet TRACE-re változtatja, akkor a JBossAS bejárhat. ERROR-ra (vagy WARN-ra) változtatva ez drámai módon felgyorsulhat.

Alapértelmezés szerint a JBoss mind a konzolba, mind a server.logba naplóz, és alapértelmezés szerint az "INFO" szintet használja.

Fontolja meg, hogy ne jelentkezzen be a System.out oldalra (érdemes lehet átirányítania a JVM hibák elkapására)

Fontolja meg a naplószint megváltoztatását ERROR-ra. Ne feledje, hogy a JBoss figyeli a log4j konfigurációs fájlt a változások miatt, és mindig konfigurálhatja futás közben.

Adjon hozzá kategóriaszűrőt a Java osztály hierarchiájához.