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 (athena.apache.org: domain of 777user@gmail.com designates
 209.85.210.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4F270B14.5050002@ice-sa.com>
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>
	<4F270B14.5050002@ice-sa.com>
Date: Tue, 31 Jan 2012 08:56:41 -0200
Message-ID: 
 <CAMqvj+3zGT6ohM+Zye8hkawEz6XAQBZzNTxjyQcKiC=3DbiW3w@mail.gmail.com>
Subject: Re: Java.lang.out.of.memory not clearly....
From: Luciano Andress Martini <777user@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2012/1/30, Andr=E9 Warnier <aw@ice-sa.com>:
> 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=3Dtrue
>  > -Xmx512m
>  > -XX:MaxPermSize=3D3512M
>  > -XX:+CMSIncrementalMode
>  > -XX:+UseConcMarkSweepGC
>  > -XX:+CMSClassUnloadingEnabled
>  > -XX:ParallelGCThreads=3D4
>  > -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 o=
f
> coffee, sit
> down, read what you have already been told, and think about it for a whil=
e
> 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 muc=
h
> 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=3Dtrue -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 k=
now
> again what
> the Tomcat logfile says, before you change any parameter again.
>
> The "-Xms1024m -Xmx1024m" switches will set both the minimum and the maxi=
mum
> 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, whe=
n
> 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, an=
d
> despite the
> fact that java runs the Garbage Collector from time to time, the Heap wil=
l
> fill up, and
> the GC will not be able to make space free anymore.  And then java will t=
ry
> 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 memor=
y
> 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 h=
ave
> a short
> lifetime, and when they are not needed anymore they disappear, and java w=
ill
> 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 doe=
s
> with the
> memory.  If you still have a problem after the above, we will tell you ab=
out
> 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
>
>

my heap size is 1512, some wrong in the message, but now 2000 with the
Xms too. Thank you.

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