I'm monitoring some CentOS 5 servers running Sun Java. We have set things up so 2048 MB of RAM are available for the base operating system, taking into account the xMx and permgen settings. What we're seeing is the swap space getting used up, and not released. Is this normal behavior? Performance doesn't seem to be affected, however I'm a bit concerned that the swap file is completely full:
free -m total used free shared buffers cached Mem: 9993 9945 48 0 174 1695 -/+ buffers/cache: 8074 1919 Swap: 2047 2033 14
Here are the xMx and permgen settings: -Xms7177m -Xmx7177m -XX:MaxPermSize=768m
Apart from Java/Tomcat/Apache and some HP hardware monitoring tools we are not running anything else on this server.
Sean Carolan wrote:
I'm monitoring some CentOS 5 servers running Sun Java. We have set things up so 2048 MB of RAM are available for the base operating system, taking into account the xMx and permgen settings. What we're seeing is the swap space getting used up, and not released. Is this normal behavior? Performance doesn't seem to be affected, however I'm a bit concerned that the swap file is completely full:
free -m total used free shared buffers cached Mem: 9993 9945 48 0 174 1695 -/+ buffers/cache: 8074 1919 Swap: 2047 2033 14
Here are the xMx and permgen settings: -Xms7177m -Xmx7177m -XX:MaxPermSize=768m
Apart from Java/Tomcat/Apache and some HP hardware monitoring tools we are not running anything else on this server.
I think Xms/x is java's heap space for program object storage. It doesn't take into account the space needed for the JVM itself. Top should show you the actual memory usage - along with any other programs that might be using a lot.
I think Xms/x is java's heap space for program object storage. It doesn't take into account the space needed for the JVM itself. Top should show you the actual memory usage - along with any other programs that might be using a lot.
One of our java developers indicated that the heap space plus permgen should approximate the total memory required by the JVM. HP's system management homepage that eats up nearly 500MB by itself.
Are there any tools that let you look inside the swap disk or file and see exactly what is being placed there?
Sean Carolan wrote:
I think Xms/x is java's heap space for program object storage. It doesn't take into account the space needed for the JVM itself. Top should show you the actual memory usage - along with any other programs that might be using a lot.
One of our java developers indicated that the heap space plus permgen should approximate the total memory required by the JVM. HP's system management homepage that eats up nearly 500MB by itself.
I'm pretty sure that's not true. Permgen is just part of the heap space and none of that accounts for the executing part of the JVM. In any case, you probably want to allow some free memory to be used for filesystem cache.
Are there any tools that let you look inside the swap disk or file and see exactly what is being placed there?
In top, hit 'f', then 'p' to add a column to show swap usage by process.
I'm pretty sure that's not true. Permgen is just part of the heap space and none of that accounts for the executing part of the JVM. In any case, you probably want to allow some free memory to be used for filesystem cache.
I'll read up on this some more. I'm not a java expert.
Are there any tools that let you look inside the swap disk or file and see exactly what is being placed there?
In top, hit 'f', then 'p' to add a column to show swap usage by process.
Well, looks like java is the culprit. I'll work with the devs and QA people some more to see if we can track down the source, maybe it's a memory leak...
Sean Carolan wrote:
I'm pretty sure that's not true. Permgen is just part of the heap space and none of that accounts for the executing part of the JVM. In any case, you probably want to allow some free memory to be used for filesystem cache.
I'll read up on this some more. I'm not a java expert.
Are there any tools that let you look inside the swap disk or file and see exactly what is being placed there?
In top, hit 'f', then 'p' to add a column to show swap usage by process.
Well, looks like java is the culprit. I'll work with the devs and QA people some more to see if we can track down the source, maybe it's a memory leak...
Does restarting java fix it for a while? There was an odd leak back in the 1.4.x versions when creating graphic images, and there may be others in other versions.
Am Montag, den 08.03.2010, 08:24 +0100 schrieb Mathieu Baudier:
I'm monitoring some CentOS 5 servers running Sun Java. We have set things
Out of curiosity, which version of Sun Java do you use precisely?
I had memory issues with the the Java OpenJDK 1.6 (b09) provided by stock CentOS and upgraded to Java OpenJDK 1.6 b16.
I have Crashes with the b09 too. How did you upgrade the version?
Chris
financial.com AG
Munich head office/Hauptsitz München: Maria-Probst-Str. 19 | 80939 München | Germany Frankfurt branch office/Niederlassung Frankfurt: Messeturm | Friedrich-Ebert-Anlage 49 | 60327 Frankfurt | Germany Management board/Vorstand: Dr. Steffen Boehnert | Dr. Alexis Eisenhofer | Dr. Yann Samson | Matthias Wiederwach Supervisory board/Aufsichtsrat: Dr. Dr. Ernst zur Linden (chairman/Vorsitzender) Register court/Handelsregister: Munich – HRB 128 972 | Sales tax ID number/St.Nr.: DE205 370 553
I have Crashes with the b09 too. How did you upgrade the version?
We repackaged the Fedora SRPM. (it was discussed on this list in December/January: "[CentOS] stock openjdk vs. epel")
You can find the SRPMs as well as x86_64 and i386 versions here: http://www.argeo.org/linux/argeo-el/5/plus/
We use this version since then, and have experienced better resource usage and less issues.
Please note, that the RPMs as they currently are DO UPGRADE base CentOS. Our goal is to maintain this in the long term and to submit it to one of the additional CentOS repositories if there is enough interest, so we would be happy to have people testing it and providing feedback. We are considering building another version which would not override the stock OpenJDK but install the latest version on the side as an 'alternative'. We did not have the need until then, but it would make sense if there is interest in the community.
Here are instructions on how to use our repositories: http://lists.centos.org/pipermail/centos/2010-January/088368.html
You can directly download the repo file ("plus" repositories are disabled so you need to enable the [argeo-plus] one): http://www.argeo.org/linux/argeo-el/5/argeo.repo
If you don't want to depend on our repository you can of course rebuild the SRPM.
An alternative is to build locally the OpenJDK using the IcedTea harness and deploy it on /opt or /usr/local. Here are pointers on how to do it as well as the rationale for upgrading (with links to the bugs we filed): http://lists.centos.org/pipermail/centos/2009-December/088036.html
You can of course always install the latest Sun JDK (our policy is rather to use FLOSS software upon which we have control) Some pointers here, mostly relevant for desktop: http://lists.centos.org/pipermail/centos/2009-December/088038.html
Hope it helps.
-
Christoph Maser -
Les Mikesell -
Mathieu Baudier -
Sean Carolan