I started the process with -Xmx256m but without any definition for perm size. Does this mean I am allowing
(theoretically) infinite perm gen space for the process/vm ? But does this matter since in perm gen there
are classes, Strings and other static stuff and the dynamically allocated space for objects etc. ist stored on
the heap (which has a limit) ?
I will try to repeat the tests with the perm gen size limit and see what happens...
Curious what will happen when using Java 8 where the perm gen limit parameter has been removed: http://openjdk.java.net/jeps/122 .

P.S. The 45,6% Memory process stopped running because the linux oom-killer process decided to stop it:

[So Jun 22 21:09:41 2014] Out of memory: Kill process 21744 (java) score 474 or sacrifice child
[So Jun 22 21:09:41 2014] Killed process 21744 (java) total-vm:7278584kB, anon-rss:4446556kB, file-rss:968kB


Von:        "Kasemir, Kay" <kasemirk@ornl.gov>
An:        "<marcus.michalsky@ptb.de> " <marcus.michalsky@ptb.de>
Kopie:        "Kasemir, Kay" <kasemirk@ornl.gov>, "Carcassi, Gabriele" <carcassi@bnl.gov>, "cs-studio-users@lists.sourceforge.net" <cs-studio-users@lists.sourceforge.net>
Datum:        20.06.2014 16:46
Betreff:        Re: [Cs-studio-users] Filling Memory when observing PVs


21744 xyz         20   0 6211m 3,5g  11m S  8,6         45,6     1307:53 java
may just mean that you allowed too much memory, and it's using that.

In comparison, I have CSS running on a control room computer for about 40 days:

Cpu(s):  6.6%us,  2.8%sy,  0.0%ni, 90.4%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:   3866144k total,  3637028k used,   229116k free,   366980k buffers
Swap:  8339448k total,    88928k used,  8250520k free,  1745640k cached

5313 tgt-hall  20   0 3702m 500m  13m S 45.7 13.3  62287:11 /usr/java/current/bin/java -Xmx1024m -XX:MaxPermSize=128M -Dorg.apache.commons.logging.Log=org.apache.commons.logging.i

Note how it was started with -Xmx1024m, -XX:MaxPermSize=128M.
Memory usage is not a problem.
In our case, on Linux,'%CPU is more of a concern, which is a separate issue that's in the process of being addressed.


On Jun 20, 2014, at 10:29 AM, <marcus.michalsky@ptb.de<


yes thanks too for the description although I feel a little more helpless now ;-)

I didn't run the Applications long enough to tell if it crashes or not. Once I ran some in parallel (different versions and VMs)
but since it was my normal working machine and it started to swap memory it wasn't usable in that state. So I had to stop.
Another one (custom build v3.2.15, OpenJDK 7) is running for a week now and linux-top shows the following:

KiB Mem:   8125900 total,  7843444 used,   282456 free,    18452 buffers
KiB Swap:  2103292 total,  1623244 used,   480048 free,   768356 cached

21744 xyz         20   0 6211m 3,5g  11m S  8,6         45,6     1307:53 java

Scenario is still the same (start the program, add ca. 20 PVs updating its values at 4Hz).
Maybe this one will grab the "rest" of the free memory until Monday and we will see what happens then.
Hopefully the linux oom-killer does not interfer.


Von:        "Kasemir, Kay" <kasemirk@ornl.gov<
An:        "marcus.michalsky@ptb.de<
mailto:marcus.michalsky@ptb.de>" <marcus.michalsky@ptb.de<mailto:marcus.michalsky@ptb.de>>
Kopie:        "Carcassi, Gabriele" <carcassi@bnl.gov<
mailto:carcassi@bnl.gov>>, "cs-studio-users@lists.sourceforge.net<mailto:cs-studio-users@lists.sourceforge.net>" <cs-studio-users@lists.sourceforge.net<mailto:cs-studio-users@lists.sourceforge.net>>
Datum:        16.06.2014 15:55
Betreff:        Re: [Cs-studio-users] Filling Memory when observing PVs


Thanks to Gabriele for the good description of general GC behavior.

With either OpenJDK or the Oracle JDK, have you seen it crash with OutOfMemoryError?
Or is it simply using memory towards the permitted limit?

I am aware of a perm gen memory issue with Jython (
https://github.com/ControlSystemStudio/cs-studio/issues/256, http://bugs.jython.org/issue1746).
The CSS ticket is about the Scan Server, but it may be the same for Jython scripts inside BOY.
The manifestation would be a pretty obvious java.lang.OutOfMemoryError: Permgen space.