tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luciano Andress Martini <777u...@gmail.com>
Subject Re: Java.lang.out.of.memory not clearly....
Date Tue, 31 Jan 2012 10:56:41 GMT
2012/1/30, André 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=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
>
>

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


Mime
View raw message