Re: [Cs-studio-users] Filling Memory when observing PVs

[Carcassi, G. <car...@bn...>]

Hi Marcus:

In principle a leak in the JVM itself (e.g. JIT, GC, ...) would have that behavior. I am skeptical we'd bump into something like that ... But...

Since Oracle/OpenJDK /6/7/8 are from the same codebase, you could try the IBM Java:
http://www.ibm.com/developerworks/java/jdk/linux/download.html
And see if you get any different behavior...

You could also look at the full C dump... Never done it, though, so I'd have no idea even what to look for... :-/

Gabriele

From: mar...@pt... [mailto:mar...@pt...]
Sent: Monday, June 30, 2014 10:29 AM
To: Kasemir, Kay
Cc: cs-...@li...
Subject: Re: [Cs-studio-users] Filling Memory when observing PVs

Hi,

that is what confused me too, an ever increasing memory consumption according to top but nothing in visualvm/jconsole/etc.
The last test with the oom killer was custom build css with OpenJDK 1.7.0_u51... So quite a difference.
The mystery is that not the java memory pools (heap, perm gen) are running out of memory but the vm process according to
linux (ps/top and oom-killer).

I am now running nsls2-3.2.16a with the boy widget examples... (custom build does not have boy yet)
It is started with the integrated oracle vm 1.7.0_25. We will see.

Epics was pure Java CA in all setups.

Marcus



Von:        "Kasemir, Kay" <kas...@or...<mailto:kas...@or...>>
An:        "<mar...@pt...<mailto:mar...@pt...>> " <mar...@pt...<mailto:mar...@pt...>>
Kopie:        "cs-...@li...<mailto:cs-...@li...>" <cs-...@li...<mailto:cs-...@li...>>
Datum:        27.06.2014 14:53
Betreff:        Re: [Cs-studio-users] Filling Memory when observing PVs
________________________________




On Jun 27, 2014, at 8:29 AM, <mar...@pt...<mailto:mar...@pt...>>
wrote:
> AFAIK -Xmx does not set the overall memory limit but the maximum heap size: ...
Right, there's some difference between the "256m" that the JVM provides to CSS for heap, and the overall memory footprint which includes the JVM itself and the perm gen space. Still, the latter two are a fairly fixed overhead, they shouldn't result in growing from "256m" to total-vm:7278584kB = 7GB.

> The -Xmx256m was/is specified in the css.ini file:
> ...
> After starting it when using ps -ef | grep css I see the long outout with ... /usr/bin/java -vmargs -Xmx256m ...
> VisualVM also shows it in JVM arguments and in the monitor tab (as Gabriele showed in the screenshots):
>
> Heap: Max: 268.435.456 B
> Perm Gen Max: Max: 174.063.616 B
Good, that confirms we have known Xmx settings.


Overall, that makes it even more puzzling, and nobody else has reported such memory growth which seems to come from the JVM itself.
If the heap or perm gen space ran into the configured limits, you should see out-of-memory exceptions from the JVM itself.
So what's different about your setup?

If you just run the /BOY Examples/1_2_WidgetExamples.opi that displays most widgets, using simulated PVs, does that grow over time for you?
When talking to real EPICS PVs, are you using the pure Java CA client, or did you add the JNI version?

Thanks,
Kay