Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4F270B14.5050002@ice-sa.com>
Date: Mon, 30 Jan 2012 22:26:44 +0100
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Java.lang.out.of.memory not clearly....
References: 
 <CAMqvj+1pwSnO4NHtp586dqMTrG4a_VQaagpTemd6r0P6Y-L0Jg@mail.gmail.com>
	<4F22EDB9.9020404@pidster.com>
	<CAMqvj+1G6hbp=8W=p9TSWJpABNvBQySCdckNn4jXoeQURmfYOA@mail.gmail.com>
	<4F230BE8.1010501@pidster.com>
	<7215BA462D00D343B2837F9113F0131F010574F905@POSTOFFICE02.polydyne.com>
	<CAMqvj+2QfHVxf3cnob10p58H1Q3LTtD+Wf_JEtZK81BZAnyPWg@mail.gmail.com>
	<7215BA462D00D343B2837F9113F0131F010574F953@POSTOFFICE02.polydyne.com>
	<CAMqvj+3pRoDROR8a7DQEBfBKaA=WkHwxuufea4R8cJ7e8JZfKQ@mail.gmail.com>
	<CAMqvj+0ZKjp8oMmj0N_ySGFE+45ui0MrXEDqkV4uSuWPknOdcw@mail.gmail.com>
	<99C8B2929B39C24493377AC7A121E21FB010D92A01@USEA-EXCH8.na.uis.unisys.com>
	<CAMqvj+3bKXnDXHVb1UxeCdOvL=RYhXvZs6CqYxDLza6pZPo4Tg@mail.gmail.com>
	<4F26C41A.8080304@verizon.net>
	<CAMqvj+0PSTOotK-GKURfv8d_SRhYFJ8hBbr2D7qscosgQjK8Rw@mail.gmail.com>
	<CAMqvj+2oOjmKyp60rTxw=2P2q2d=M1Emc7CiAuBKLZwAfiJK5w@mail.gmail.com>
	<4F26DB4B.9030407@pidster.com>
 <CAMqvj+02kk+axAKqcWFuqo9jcxeWWFZdEp85CzacChQVBS5wQA@mail.gmail.com>
In-Reply-To: 
 <CAMqvj+02kk+axAKqcWFuqo9jcxeWWFZdEp85CzacChQVBS5wQA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Luciano Andress Martini wrote:
...
> Now my boss talked with the developers and added a command to call the
> garbage colector, it is very better now, and we find the bad guy, its
> a button, when we click then, the memory increases.
> 
Luciano,

your original post about this issue mentioned this error :
...
 > at java.lang.Thread.run(Thread.java:662) Caused by:
 > java.lang.OutOfMemoryError: Java heap space
 >
 > Java options (that i configurate)
 > -Djava.awt.headless=true
 > -Xmx512m
 > -XX:MaxPermSize=3512M
 > -XX:+CMSIncrementalMode
 > -XX:+UseConcMarkSweepGC
 > -XX:+CMSClassUnloadingEnabled
 > -XX:ParallelGCThreads=4
 > -XX:+UseParNewGC
...
and later you told us (not necessarily in that order) :

The system is 64 bits + Java 64 bits, running in debian
 > paravirtualized with Xen.
 >
...
 > (available system memory) : By default 4GB per virtual machine with tomcat.
...
Java using: 914mb
 >> Free memory on the virtual machine server: 2152
 >>

-- end of data --


Maybe a good idea right now would be to calm down, not panic, get a cup of coffee, sit 
down, read what you have already been told, and think about it for a while before you 
change any more parameters left and right.
And the same for your boss and the programmers.

Because right until now, you and your boss and the programmers are giving the impression 
of a bunch of headless chicken running around in the control room of a nuclear power 
plant, pressing (*) on any button that is available, to try an stop the alarm bell.
That is usually not the best way to avoid a melt-down.

First, if I may ask, from where did you get the java parameters that you are showing above ?

The only parameter which has a direct relationship with the issue that caused the error
(repeat: java.lang.OutOfMemoryError: Java heap space)
is this one :

 > -Xmx512m

which limits the Java Heap to 512 MB of memory, maximum.
And that does not seem to be enough, because you got an error "java.lang.OutOfMemoryError: 
Java heap space".

All the other "-XX" parameters on your Java command-line are probably unnecessary, and 
they probably do more harm than good.
Java has default values for all of those, which work fine in 95% of cases, for thousands 
on Tomcat servers all over the world.
And since neither you, nor the programmers, nor you boss seem to know much about java, you 
should probably not play with these parameters, unless you understand exactly what they do.
And as Chuck mentioned, your boss should stop playing with the Garbage Collector.  Java 
will automatically run the Garbage Collector when it needs to run it, and you should leave 
java to decide when that is necessary.

So why do you not set the java command-line this way :

  java -Djava.awt.headless=true -Xms1024m -Xmx1024m

and that's it. No more "-XX" parameters for now.
Java will set all the other parameters to their default values, which are probably fine.

And then try your application.  And then /if there is a problem/ let us know again what 
the Tomcat logfile says, before you change any parameter again.

The "-Xms1024m -Xmx1024m" switches will set both the minimum and the maximum java Heap 
size to 1024 MB.  In other words, they will "fix" to 1024 MB the size of the Heap, which 
is where java allocates the space that it needs to store new objects, when it needs them.
And before this Heap fills up, java automatically runs the Garbage Collector, to free some 
space on the Heap.  This is automatic and normal; that is how java works.

/If/ there is a memory leak in the application, then little by little, and despite the 
fact that java runs the Garbage Collector from time to time, the Heap will fill up, and 
the GC will not be able to make space free anymore.  And then java will try to do a GC 
more often, and your server will slow down.
And then, sooner or later, you will have an "out of memory" again.

But maybe there is no memory leak.
So far, neither you nor us have seen any /evidence/ that there is a memory leak. Maybe the 
size of the Heap - which you had limited before to 512 MB - was just not enough to process 
the millions of transactions of which you were talking.

When you click a button in the application, something happens in the application 
(supposedly, some work gets done).  In java, when an application does something, most of 
the time it means that many new objects get created; and creating new objects uses space 
on the Heap.  Most of the time also, the majority of these objects only have a short 
lifetime, and when they are not needed anymore they disappear, and java will after a while 
free the space that they used on the Heap.  So the usage of memory inside the Heap goes up 
and down all the time, and that is normal.

There are many methods and tools for java that allow to see what java does with the 
memory.  If you still have a problem after the above, we will tell you about them.
But the first step is to simplify your setup, run the application and finding out if there 
is really a problem.


(*) I would have used pecking, but since they're headless..


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org