-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<size> 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...)
<http://avricot.com/blog/index.php?post/2010/05/03/Get-started-with-java-JVM-memory-%28heap%2C-stack%2C-xss-xms-xmx-xmn...%29>
- 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 <re...@centrum.cz <mailto:re...@centrum.cz>>
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" <j...@ataco.cz <mailto:j...@ataco.cz>>
> Komu: <konference@java.cz <mailto:konference@java.cz>>
> 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<roman.pich...@gmail.com
<mailto:roman.pich...@gmail.com>>:
>> hmm je uz to opravdu jenom strelba od boku, co zkusit nastavit
PermSpace?
>>
>> 2012/4/12 Jaroslav Hurdes<j...@ataco.cz <mailto:j...@ataco.cz>>:
>>> 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<j...@ataco.cz <mailto:j...@ataco.cz>>:
>>>>> 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<martin-l...@geek.cz
<mailto:martin-l...@geek.cz>>:
>>>>>
>>>>> 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<j...@ataco.cz
<mailto:j...@ataco.cz>> 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 */
