By default 4GB per virtual machine with tomcat. 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.
2012/1/30, Pid <p...@pidster.com>: > On 30/01/2012 16:33, Luciano Andress Martini wrote: >> 2012/1/30, Luciano Andress Martini <777u...@gmail.com>: >>> Pid i changed the configuration, like this: >>> >>> JAVA_OPTS="-Djava.awt.headless=true -Xmx1512m -XX:ParallelGCThreads=4 >>> -XX:+UseParNewGC -XX:MaxPermSize=1024M -XX:+UseConcMarkSweepGC >>> -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" >>> >>> The system is 64 bits + Java 64 bits, running in debian >>> paravirtualized with Xen. >>> >>> >>> 2012/1/30, David kerber <dcker...@verizon.net>: >>>> On 1/30/2012 11:05 AM, Luciano Andress Martini wrote: >>>>> 2012/1/30, Caldarale, Charles R<chuck.caldar...@unisys.com>: >>>>>>> From: Luciano Andress Martini [mailto:777u...@gmail.com] >>>>>>> Subject: Re: Java.lang.out.of.memory not clearly.... >>>>>> >>>>>>> Jeffrey im sorry, but i need to ask, my boss says that is impossible >>>>>>> to be a problem in the software cause java unalocate objects >>>>>>> automatically, is that true? >>>>>> >>>>>> A) Stop your top posting - it's incredibly annoying and makes people >>>>>> much >>>>>> less likely to help. >>>>>> >>>>>> B) Your boss is wrong. Google for many examples of memory leaks in >>>>>> Java. >>>>>> >>>>>> - Chuck >>>>>> >>>>>> >>>>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE >>>>>> PROPRIETARY >>>>>> MATERIAL and is thus for use only by the intended recipient. If you >>>>>> received >>>>>> this in error, please contact the sender and delete the e-mail and its >>>>>> attachments from all computers. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org >>>>>> >>>>>> >>>>> >>>>> Thank you and sorry Chuck. >>>>> Jeffrey what is your opinion about this? >>>>> The development team is using a software that "Draw" java code called >>>>> developer, and do not programming in. Im a assembler/C programmer and >>>>> don't have so much knowing about java. >>>> >>>> Java can have memory leaks just as easily as C can, but if the app is >>>> standalone, it will release them when the app closes and the JRE shuts >>>> down. >>>> >>>> I have killed tomcat more than once with memory leaks, so it's easy to >>>> do. I'm not the expert that Chuck and Mark T are, but here is my >>>> understanding of what happens: if the app is running under tomcat, the >>>> JRE never shuts down since tomcat is using it. That means the JRE can >>>> not free up memory that your app has left allocated, as it would be able >>>> to in a standalone app. So your Tomcat app has to clean up after itself >>>> because there is nothing else that can do so. >>>> >>>> >>>>> >>>>> But all the fault is falling back to me in the company. >>>> >>>> I know the feeling :-/ > > >> Sorry the gmail is doing wrong with my messages =/ >> >> I changed the configuration like this: >> JAVA_OPTS="-Djava.awt.headless=true -Xmx1512m -XX:ParallelGCThreads=4 >> -XX:+UseParNewGC -XX:MaxPermSize=1024M -XX:+UseConcMarkSweepGC >> -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError" > > > -XX:MaxPermSize=1024M still seems large. PermGen is the memory where > the classes are held, not the class instances. > > Unless you are loading LOTS of classes you should be able to get away > with much a smaller number here. The JVM probably isn't even using it > as you have not specified -XX:PermSize, so it's probably on the default > and is using 32Mb. > > The -Xmx is set at a reasonable (if odd) number. I usually use > multiples of 32. > > You still didn't say how much physical memory you have available. This > is important. > > > p > > > -- > > [key:62590808] > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
