ahoj,
posílám kus článku, kde bod d to častečně vysvětluje.
JVM stack: Each JVM thread has a private Java virtual machine stack, created at
the same time as the threadIt stores frames.framesStacks are similar to
conventional language(example,) stacksThese store local variables, partial
results and plays part in method invocation and returnSize of JVM stack can be
fix or expandable. If the size is fixed and for some operation memory required
is more than the size then JVM throws StackOverFlowError. If Stack size is
dynamically expandable and now if the required memory is more then the
available then JVM will throw OutOfMemoryError ErrorRadek V
__________________________________________________________
Od: "Jaroslav Hurdes"
Komu:
Datum: 13.04.2012 09:15
Předmět: Re: java.lang.OutOfMemoryError: unable to create new native thread
-Xss znamená velikost zásobníku pro každý thread, pokud jej příliš snížíte, tak riskujete SctackOverflowException, pokud tento parametr zvednete, tak omezíte maximální počet threadu, které jste schopen využít. V mém případě, kdy je maximální počet spuštěných threadů cca 40 je to jedno, jelikož snižování velikosti Xss má význam až od tisíců thready v rámci jedné JVM. Mne by nepřekvapilo, kdyby aplikace spadla na OutOfMemory z nedostatku heap, ale zrovna v případě procesů to prostě nechápu.
Jaroslav Hurdes
Dne 13.4.2012 9:00, arsi napsal(a):
Hi,
Treba nastavit
-Xss set java thread stack size
Nema v zasobniku pre thready dost miesta...
Arsi
On 04/13/2012 07:12 AM, kek forums wrote:Zdravím,- k tomu statickému snímku z
JConsole by asi bylo dobré ještě zaslat snímek s grafy, kde bude vidět vývoj
chování aplikace v čase, třeba tam je nějaký peak, který to položí na lopatky,
protože tady z těch statistik to vypadá v pohodě.- nastavil bych tomu JVMku
-XX:+HeapDumpOnOutOfMemoryError - a výsledný dump analyzoval nějakým
nástrojem, jako http://www.eclipse.org/mat/ - jak již bylo napsáno -
nevytvářel bych vlákna nekontrolovaně, ale raději bych volil nějaký ThreadPool,
tak aby se počet vláken dal limitovat a navíc se zásadně snížila režie spojená
s vytvářením vláken -
např.: http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ThreadPoolExecutor.html-
navyšování různých parametrů Xmx, Xms, Xss, permGen - je sice možné, ale dělám
to vždy až potom, co detekuji v čem je problém - protože v 80% případů je
problém v aplikaci a tato navýš
ení řeší následky, nikoliv příčinu problému, ale především často jen pád
oddálí, ale nic neřeší :). Doporučoval bych nastudovat nějaké materiály kolem
rozložení paměti, jako
například http://avricot.com/blog/index.php?post/2010/05/03/Get-started-with-java-JVM-memory-(heap%2C-stack%2C-xss-xms-xmx-xmn...)
- pak člověk zjistí, že zvyšování HEAPu je naopak kotraproduktivní, protože
Thread Stack se alokuje mimo tuto oblast. Takže naopak je lepší ten Xmx limit
snížit, aby zbylo více na ta vlákna opět v souvislosti s XSS. Jinak tato
oblast paměti je používána i pro JNI, GC, atd. Ale jak koukám, vaše XSS je pro
peak 31 vláken asi taky v pohodě. - a když z toho všeho nic nepomůže - tak
klasika - začít ořezávat aplikaci v testech a izolovat, kde je problém - tady
bych udělal mock na to JNI - JNI vyhodil a zkusil, zda to pomůže - třeba si v
rámci JNI alokujete nějaké velké množství paměti, kter
é vám sebere prostor pro ta vlákna.
Dne 13. dubna 2012 0:15 napsal(a):
Ahoj,
podle mě by mělo stačit zvednout -Xmx1024M třeba na Xmx2048m. Jinak
12 GB RAM je ti pro 32 bitovou javu k nicemu, neboť velikost heapu je omezena.
A to se častečně liší podle systému.
Radek
______________________________________________________________
> Od: "Jaroslav Hurdes"
> Komu:
> Datum: 12.04.2012 22:35
> Předmět: Re: java.lang.OutOfMemoryError: unable to create new native thread
>
Systém má k dispozici 12 GB RAM. Využití paměti je na cca 33% CPU 20%
Procesu cca 70, Threadu cca 5000 na cely OS, takže docela v pohodě.
Jaroslav Hurdes
Dne 12.4.2012 20:59, Peter Hanuliak napsal(a):
> skusali ste pozriet ako vyzeraju zdroje windows systemu? ako on vyzera
> s threadmi? pamatou a pod?
>
>
> 2012/4/12 Roman Pichlík:
>> hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit PermSpace?
>>
>> 2012/4/12 Jaroslav Hurdes:
>>> Ne, tato třída nemá s JNI nic společného. Je to jednoduchý server, který na
>>> požádání vytvoří thread, obslouží požadavek a ukonči se. Tato třída má na
>>> svědomí ten celkový počet spuštěných threadu, které ale žijí jen velmi
>>> krátce (klient se zeptá na stav aplikace a po odeslání zprávy je thread
>>> ukončen). Jaroslav Hurdes
>>>
>>> Dne 12.4.2012 20:13, Roman Pichlík napsal(a):
>>>
>>>> Vola se to JNI v ramci CommandClientsManager$Client.start?
>>>>
>>>> 2012/4/12 Jaroslav Hurdes:
>>>>> Vláken je spuštěno pouze 26, viz výpis z dokumentace k jconsole
>>>>>
>>>>> Threads
>>>>>
>>>>> Live threads: Current number of live daemon threads plus non-daemon
>>>>> threads
>>>>> Peak: Highest number of live threads since JVM started.
>>>>> Daemon threads: Current number of live daemon threads
>>>>> Total started: Total number of threads started since JVM started
>>>>> (including
>>>>> daemon, non-daemon, and terminated).
>>>>>
>>>>>
>>>>> DLL je volána přes JNI a nemělo by tam vzniknout souběžně více vláken
>>>>> (získávání obrazu z frame grabberu).
>>>>>
>>>>> Jaroslav Hurdes
>>>>>
>>>>> Dne 12.4.2012 19:26, Roman Pichlík napsal(a):
>>>>>
>>>>> To je pocet celkove vytvorenych vlaken po dobu behu, nikoliv zivych,
>>>>> tech je tam relativne malo, 67 pokud dobre pocitam.
>>>>>
>>>>> 2012/4/12 Martin Caslavsky:
>>>>>
>>>>> Máte 2.500 vláken a další už nejde vytvořit... První odkaz v Google
>>>>> popisuje tenhle problém:
>>>>>
>>>>>
http://stackoverflow.com/questions/763579/how-many-threads-can-a-java-vm-support
>>>>>
>>>>> Martin Caslavsky
>>>>>
>>>>>
>>>>>
>>>>> On 12 April 2012 18:08, Jaroslav Hurdes wrote:
>>>>>
>>>>> Zdravím, bojuji s vyjímkou, která nastává v mé aplikaci a nedaří se mi
>>>>> objevit příčinu. Vyjímka je následující:
>>>>>
>>>>> Exception in thread "Thread-6" java.lang.OutOfMemoryError: unable to
>>>>> create
>>>>> new native thread
>>>>> at java.lang.Thread.start0(Native Method)
>>>>> at java.lang.Thread.start(Thread.java:640)
>>>>> at
>>>>>
>>>>>cz.nitta.licenceplate.server.business.communicator.CommandClientsManager$Client.start(CommandClientsManager.java:357)
>>>>> at
>>>>>
>>>>>cz.nitta.licenceplate.server.business.communicator.CommandClientsManager.addClient(CommandClientsManager.java:118)
>>>>> at
>>>>>
>>>>>cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.addClient(ClientsGatekeeper.java:196)
>>>>> at
>>>>>
>>>>>cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.acceptClient(ClientsGatekeeper.java:140)
>>>>> at
>>>>>
>>>>>cz.nitta.licenceplate.server.business.communicator.ClientsGatekeeper.run(ClientsGatekeeper.java:213)
>>>>> at java.lang.Thread.run(Thread.java:662)
>>>>>
>>>>> Prostředí je popsáno níže. V příloze je obrazovka z jconsole, kde je
>>>>> zobrazen počet threadu i stav paměti. Nesetkal se někdo s něčím podobným
>>>>> a
>>>>> nenašel řešení? Zkouším laborovat s různými parametry, ale zatím nic. 32
>>>>> bit
>>>>> javu používám z důvodu nutnosti použít 32 bit dll. Díky. Jaroslav Hurdes
>>>>>
>>>>> OS Windows 7, x64
>>>>>
>>>>> Verze javy (32 bit)
>>>>> java version "1.6.0_31"
>>>>> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
>>>>> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
>>>>>
>>>>> spouštění aplikace:
>>>>> java -XX:ThreadStackSize=256 -Xss256k -XX:ReservedCodeCacheSize=64m
>>>>> -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001
>>>>> -Dcom.sun.management.jmxremote.authenticate=false
>>>>> -Dcom.sun.management.jmxremote.ssl=false -server -Xcheck:jni -Xmx1024M
>>>>> -Djava.library.path=..\common\lib\native -jar nitta-lp-rec-srv.jar ./cfg
>>>>> %*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>> --
>> S pozdravem Roman "Dagi" Pichlik
>>
>> /* http://dagblog.cz/ Blog pro kodery */
