Dotaz: Java a parametr MaxPermSize

[PMartinek]

Dobry den,

nejak z dokumentace k Jave nechapu, co presne znamena tento argument:

-XX:MaxPermSize=128m

Dale bych se chtel zeptat, na jakou hodnotu je optimalni tento parametr nastavit v pripade server s 4GB RAM.

---

---

Odpovědi

[Filip Jirsák]

Týká se to JVM HotSpot od Sunu (teď Oracle). Některé garbage collectory rozlišují různé generace objektů – podle toho, jak „staré“ objekty jsou – u čerstvých objektů se předpokládá, že budou zase brzo smazány, teprve když nějaký objekt vydrží déle, dostane se do jiné generace. Hodnota MaxPermSize určuje velikost paměti pro generaci „permanent“, tj. objektů, který existují dlouho.

Určit optimální hodnotu parametru pro „server se 4 GB RAM“ nejde – záleží na aplikaci, na typu zátěže… JVM má nějakou heuristiku, kterou tenhle parametr určí. Pokud nevíte, co znamená, nebo nemáte doporučení od autora aplikace na jeho změnu, nenastavujte jej a nechte JVM, ať si s tím poradí.

[kuka]

Myslim ze zadna heuristika zde nehraje roli. Default je 64m, coz byva casto malo, proto se podobne radky vyskytuji ve vetsine defaultnich konfiguraci aplikacnich serveru apod.

[cronin]

Ten popis sa skor hodi na Survivor Space. AFAIK, Permanent Space stoji uplne mimo pamate podliehajucej garbace collectingu, t.j. heapu, a to nezavisle od pouzeteho garbage collectora. Permanent space sa pouziva na interne alokacie v JVM pri classloadingu, su tam napr. informacie o triedach a metodach. Preto k OOME na Permanent Space dochadza zvycajne u aplikacii, ktore maju vela pluginov. "Normalne" objekty bezne vytvarane cez operator new sa na Permanent Space neukladaju.

JVM od Sun/Oracle je taky laskavy, ze pri OOME aspon povie, ze nenastal na heape, ale na permspace. Zato JVM od IBM - aspon v casoch, ked som ich naposledy pouzival - toto nerozlisovali, a najst pricinu OOME bolo tazsie.

[kuka]

No jo laskavy, nejlepsi by mozna bylo, kdyby to proste nepadalo, neni uplne lehke takovy parametr "naladit". Napr. JRockit to resi jinak.

[cronin]

Ten parameter ale velmi "ladit" netreba. V 98% pripadov default vyhovuje. V 98% zo zvysnych 2% proste staci nastavit dostatocne vysoku hodnotu. A kvoli zvysku sa neoplati robit zlozitu a na chyby nachylnu adaptivnu logiku.

Ako to riesi JRockit?

[kuka]

Proste to takto neomezuje, z aplikacniho hlediska je uplne jedno, co je na heapu a co nekde jinde. Osobne nevidim duvod to specialne nastavovat (mozna v nejakem debug rezimu, kdybych chtel drsnym zpusobem "monitorovat" velikost permgen). Je dost suche, kdyz na serveru s nekolika GB RAM padne aplikace kvuli par retezcovym konstantam ve tridach. Ono to taky muze padnout treba po mesici, kdyz se aktivuje nejaka mene pouzivana cast aplikace, a to neni na produkci uplne ono.

[Filip Jirsák]

Máte pravdu, nespojil jsem si to s chybou PermGen space:

The permanent generation is a non-heap memory area in the HotSpot VM implementation that stores per-class structures as well as interned strings. When the permanent generation is full, the application will fail to load a class or to allocate an interned string, and an OutOfMemoryError will be thrown with the following error message: java.lang.OutOfMemoryError: PermGen space

[cronin]

Dale bych se chtel zeptat, na jakou hodnotu je optimalni tento parametr nastavit v pripade server s 4GB RAM.

As less as possible, as high as necessary.

[XY]

na nastavovanie optimalnej hodnoty pamate pre javu sa celkom hodia tooly ako napr. jconsole a jstat. spustite si aplikaciu, a odmonitorujete kolko pamate potrebuje, ci pridat heap alebo perm alebo obe atd...