You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ozgur Ozdemircili <oz...@gmail.com> on 2010/05/17 10:25:11 UTC
MaxPermSize / Threads
Hi,
I am having a lot of Java Heap OutOfMemory issues. The first change I did
was to add more memory to JVM:
export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m -server"
Yet I have 2 questions
- What are you real life configurations? In a very busy prod environment
what parameters do you use?
- Checking the Current and Busy threads I have Current at 145 and Busy at 6,
is this normal? Shouldn`t Tomcat close unused threads?
- After updating the server with "-XX:MaxPermSize=512m -Xms512m -Xmx2048m
-server" parameter although the Max mem should show 2048+512M it shows
1820.50 MB. Any ideas why?
Thank you for all the help.
Özgür Özdemircili
http://www.acikkod.org
Code so clean you could eat off it
Re: MaxPermSize / Threads
Posted by Antonio Vidal Ferrer <an...@globalia-sistemas.com>.
Can you paste the original error from your catalina.out log?
Best
Toni
El 17/05/2010 10:25, Ozgur Ozdemircili escribió:
> Hi,
>
> I am having a lot of Java Heap OutOfMemory issues. The first change I did
> was to add more memory to JVM:
>
> export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m -server"
>
> Yet I have 2 questions
>
> - What are you real life configurations? In a very busy prod environment
> what parameters do you use?
>
> - Checking the Current and Busy threads I have Current at 145 and Busy at 6,
> is this normal? Shouldn`t Tomcat close unused threads?
>
> - After updating the server with "-XX:MaxPermSize=512m -Xms512m -Xmx2048m
> -server" parameter although the Max mem should show 2048+512M it shows
> 1820.50 MB. Any ideas why?
>
> Thank you for all the help.
>
>
>
> Özgür Özdemircili
> http://www.acikkod.org
> Code so clean you could eat off it
> .
>
>
--
*******************************************************************************************
Antonio Vidal Ferrer Globalia Corporación Empresarial Senior System
Manager Carretera Arenal Llucmajor km 21.5 Globalia Sistemas y
Comunicaciones S.L. www.globalia-corp.com
antonio.vidal@globalia-sistemas.com 07620 Llucmajor - Islas Baleares –
España T: (0034) 971-178464 T: (0034) 971-178100 M: (0034) 647-995481
*******************************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: MaxPermSize / Threads
Posted by Pe...@blm.gov.
One thing that happened on a system I was working on here, was that we saw
OOMs and yet the GC stats showed we had plenty of free heap space, which
didn't make sense. The problem turned out to be that there was a memory
leak at the native level where the JVM couldn't see it and had no control
(specifically, Apache Commons FileUpload version 1.0 used a native library
function that had a leak; later versions of fileupload fixed this problem).
Pete
"Caldarale, Charles R" <Ch...@unisys.com> wrote on 05/17/2010
09:10:28 AM:
> > From: Ozgur Ozdemircili [mailto:ozgur.ozdemircili@gmail.com]
> > Subject: Re: MaxPermSize / Threads
> >
> > You can see the server giving error every 3-4 minutes until it dies.
>
> By "it dies", do you mean you have to restart Tomcat?
>
> Turn on GC logging (-verbose:gc) and use a heap profiler to see if
> you have a memory leak or simply an undersized heap for the load
> you're putting on it. If the heap usage returns to normal after a
> heavy load, your heap is undersized; if the heap usage keeps
> increasing over time regardless of the load, you have a leak in your
webapps.
>
> - 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: MaxPermSize / Threads
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ozgur Ozdemircili [mailto:ozgur.ozdemircili@gmail.com]
> Subject: Re: MaxPermSize / Threads
>
> You can see the server giving error every 3-4 minutes until it dies.
By "it dies", do you mean you have to restart Tomcat?
Turn on GC logging (-verbose:gc) and use a heap profiler to see if you have a memory leak or simply an undersized heap for the load you're putting on it. If the heap usage returns to normal after a heavy load, your heap is undersized; if the heap usage keeps increasing over time regardless of the load, you have a leak in your webapps.
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by Ozgur Ozdemircili <oz...@gmail.com>.
Hi,
It happens when there is a peak of requests.
Here is a part of catalina:
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
* **at java.util.HashMap.<init>(HashMap.java:209)*
* **at java.util.HashSet.<init>(HashSet.java:86)*
* **at org.jdom.output.XMLOutputter.printAttributes(XMLOutputter.java:1328)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1062)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at
org.jdom.output.XMLOutputter.printElementContent(XMLOutputter.java:1206)*
* **at org.jdom.output.XMLOutputter.printElement(XMLOutputter.java:1102)*
* **at org.jdom.output.XMLOutputter.output(XMLOutputter.java:502)*
* **at org.jdom.output.XMLOutputter.output(XMLOutputter.java:470)*
* **at com.serhs.wsserhs.utility.Parser.XmlToFile(Parser.java:214)*
* **at com.serhs.wsserhs.cache.CacheLevel2.writeFile(CacheLevel2.java:296)*
* **at com.serhs.wsserhs.cache.CacheLevel2.insert(CacheLevel2.java:253)*
* **at
com.serhs.wsserhs.app.GenerateResponse.createDocument(GenerateResponse.java:527)
*
* **at wsserhs.ServlStart.process(ServlStart.java:297)*
* **at wsserhs.ServlStart.doPost(ServlStart.java:400)*
* **at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)*
* **at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)*
*16-may-2010 18:00:08 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
* **at java.util.AbstractList.iterator(AbstractList.java:273)*
* **at org.jdom.Element.clone(Element.java:1834)*
* **at
com.serhs.wsserhs.app.FilterAccomBoards.insertAccomBoards(FilterAccomBoards.java:85)
*
* **at
com.serhs.wsserhs.app.FilterAccomBoards.filter(FilterAccomBoards.java:469)*
* **at com.serhs.wsserhs.app.Merge.getMergeResponse(Merge.java:126)*
* **at
com.serhs.wsserhs.app.GenerateResponse.makeResponse(GenerateResponse.java:2088)
*
* **at
com.serhs.wsserhs.app.GenerateResponse.createThreads(GenerateResponse.java:1823)
*
* **at
com.serhs.wsserhs.app.GenerateResponse.createDocument(GenerateResponse.java:493)
*
* **at wsserhs.ServlStart.process(ServlStart.java:297)*
* **at wsserhs.ServlStart.doPost(ServlStart.java:400)*
* **at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)*
* **at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)*
* **at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
*
* **at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
*
* **at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
*
* **at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
*
* **at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
*
* **at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
*
* **at wsserhs.Rhodasol.doGet(Rhodasol.java:86)*
* **at wsserhs.Rhodasol.doPost(Rhodasol.java:117)*
* **at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)*
* **at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)*
* **at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
*
* **at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
*
* **at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
*
* **at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
*
* **at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
*
* **at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
*
* **at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
*
* **at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)*
* **at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)*
* **at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
*
*16-may-2010 19:08:26 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
*16-may-2010 19:16:17 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
*16-may-2010 19:26:57 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
*16-may-2010 19:29:52 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
*16-may-2010 19:31:24 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
*16-may-2010 19:35:10 org.apache.catalina.core.ApplicationDispatcher invoke*
*GRAVE: El Servlet.service() para servlet servlstart lanzó una excepción*
*java.lang.OutOfMemoryError: Java heap space*
You can see the server giving error every 3-4 minutes until it dies.
Thanks.
Özgür Özdemircili
http://www.acikkod.org
Code so clean you could eat off it
On Mon, May 17, 2010 at 3:58 PM, Pid <pi...@pidster.com> wrote:
> On 17/05/2010 14:40, Ozgur Ozdemircili wrote:
> > Hi all,
> >
> > Thanks for all the answers. Since the company didn`t have any
> > monitorization I think the correct decision here would be to start
> > monitoring the tomcat servers and see what is happening.I really do not
> > have any control on the programming part I need to find out first what
> > is happening.
> >
> > Could you please share your experiences on this too?
> >
> > I am looking into 2 kinds of monitorization software:
> >
> > - Java Melody
> > - Jrockit Mission Control
> >
> >
> > The servers we are talking about are getting about 1.000.000 requests a
> > day making query the DB and returning xml to our clients. Before them we
> > have a F5 load balancing server that is sending the requests on one of
> > the 2 servers.
> >
> > In the attached file you can find catalina.out of 2 servers.
>
> (The list often strips attachments.)
>
> Does the problem manifest regularly, after a period of time?
>
> Or does the problem occur when the site experiences high load conditions?
>
>
> p
>
>
>
> > Özgür Özdemircili
> > http://www.acikkod.org
> > Code so clean you could eat off it
> >
> >
> > On Mon, May 17, 2010 at 3:17 PM, Caldarale, Charles R
> > <Chuck.Caldarale@unisys.com <ma...@unisys.com>> wrote:
> >
> > > From: André Warnier [mailto:aw@ice-sa.com <ma...@ice-sa.com>]
> > > Subject: Re: MaxPermSize / Threads
> > >
> > > So, while I am not saying that there are not circumstances where a
> > 2 GB
> > > Heap is justified, it is still a very high number, and maybe you
> > should
> > > have a look at which application really needs so much space.
> >
> > Having an excessively large heap does not hurt, as long as it's not
> > so large compared to available RAM that it pushes the environment
> > into paging. GC times are not affected by the size of the heap,
> > just the number of live objects present in the heap. Being able to
> > run the apps in a smaller heap does allow you to deploy on a
> > cost-reduced platform, but that's about all. If the JVM is the sole
> > application on the box, you might as well give it as much RAM as
> > you've got (unless you want to run with compressed object pointers).
> >
> > - 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-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > For additional commands, e-mail: users-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
Re: MaxPermSize / Threads
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 14:40, Ozgur Ozdemircili wrote:
> Hi all,
>
> Thanks for all the answers. Since the company didn`t have any
> monitorization I think the correct decision here would be to start
> monitoring the tomcat servers and see what is happening.I really do not
> have any control on the programming part I need to find out first what
> is happening.
>
> Could you please share your experiences on this too?
>
> I am looking into 2 kinds of monitorization software:
>
> - Java Melody
> - Jrockit Mission Control
>
>
> The servers we are talking about are getting about 1.000.000 requests a
> day making query the DB and returning xml to our clients. Before them we
> have a F5 load balancing server that is sending the requests on one of
> the 2 servers.
>
> In the attached file you can find catalina.out of 2 servers.
(The list often strips attachments.)
Does the problem manifest regularly, after a period of time?
Or does the problem occur when the site experiences high load conditions?
p
> Özgür Özdemircili
> http://www.acikkod.org
> Code so clean you could eat off it
>
>
> On Mon, May 17, 2010 at 3:17 PM, Caldarale, Charles R
> <Chuck.Caldarale@unisys.com <ma...@unisys.com>> wrote:
>
> > From: André Warnier [mailto:aw@ice-sa.com <ma...@ice-sa.com>]
> > Subject: Re: MaxPermSize / Threads
> >
> > So, while I am not saying that there are not circumstances where a
> 2 GB
> > Heap is justified, it is still a very high number, and maybe you
> should
> > have a look at which application really needs so much space.
>
> Having an excessively large heap does not hurt, as long as it's not
> so large compared to available RAM that it pushes the environment
> into paging. GC times are not affected by the size of the heap,
> just the number of live objects present in the heap. Being able to
> run the apps in a smaller heap does allow you to deploy on a
> cost-reduced platform, but that's about all. If the JVM is the sole
> application on the box, you might as well give it as much RAM as
> you've got (unless you want to run with compressed object pointers).
>
> - 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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by Ozgur Ozdemircili <oz...@gmail.com>.
Hi all,
Thanks for all the answers. Since the company didn`t have any monitorization
I think the correct decision here would be to start monitoring the tomcat
servers and see what is happening.I really do not have any control on the
programming part I need to find out first what is happening.
Could you please share your experiences on this too?
I am looking into 2 kinds of monitorization software:
- Java Melody
- Jrockit Mission Control
The servers we are talking about are getting about 1.000.000 requests a day
making query the DB and returning xml to our clients. Before them we have a
F5 load balancing server that is sending the requests on one of the 2
servers.
In the attached file you can find catalina.out of 2 servers.
Özgür Özdemircili
http://www.acikkod.org
Code so clean you could eat off it
On Mon, May 17, 2010 at 3:17 PM, Caldarale, Charles R <
Chuck.Caldarale@unisys.com> wrote:
> > From: André Warnier [mailto:aw@ice-sa.com]
> > Subject: Re: MaxPermSize / Threads
> >
> > So, while I am not saying that there are not circumstances where a 2 GB
> > Heap is justified, it is still a very high number, and maybe you should
> > have a look at which application really needs so much space.
>
> Having an excessively large heap does not hurt, as long as it's not so
> large compared to available RAM that it pushes the environment into paging.
> GC times are not affected by the size of the heap, just the number of live
> objects present in the heap. Being able to run the apps in a smaller heap
> does allow you to deploy on a cost-reduced platform, but that's about all.
> If the JVM is the sole application on the box, you might as well give it as
> much RAM as you've got (unless you want to run with compressed object
> pointers).
>
> - 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: MaxPermSize / Threads
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Subject: RE: MaxPermSize / Threads
>
> could you describe compressed object pointers and how implementation
> will reduce allocations from JVM heap?thx,
It doesn't reduce the number of allocations, but it does reduce the size of objects, since each object reference is kept in 32 bits instead of 64. For heaps larger than 4 GB, some CPU time is spent (de)compressing the references to and from pointers.
http://wikis.sun.com/display/HotSpotInternals/CompressedOops
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: MaxPermSize / Threads
Posted by Martin Gainty <mg...@hotmail.com>.
could you describe compressed object pointers and how implementation will reduce allocations from JVM heap?thx,
Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
> From: Chuck.Caldarale@unisys.com
> To: users@tomcat.apache.org
> Date: Mon, 17 May 2010 08:17:06 -0500
> Subject: RE: MaxPermSize / Threads
>
> > From: André Warnier [mailto:aw@ice-sa.com]
> > Subject: Re: MaxPermSize / Threads
> >
> > So, while I am not saying that there are not circumstances where a 2 GB
> > Heap is justified, it is still a very high number, and maybe you should
> > have a look at which application really needs so much space.
>
> Having an excessively large heap does not hurt, as long as it's not so large compared to available RAM that it pushes the environment into paging. GC times are not affected by the size of the heap, just the number of live objects present in the heap. Being able to run the apps in a smaller heap does allow you to deploy on a cost-reduced platform, but that's about all. If the JVM is the sole application on the box, you might as well give it as much RAM as you've got (unless you want to run with compressed object pointers).
>
> - 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4
RE: MaxPermSize / Threads
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: MaxPermSize / Threads
>
> So, while I am not saying that there are not circumstances where a 2 GB
> Heap is justified, it is still a very high number, and maybe you should
> have a look at which application really needs so much space.
Having an excessively large heap does not hurt, as long as it's not so large compared to available RAM that it pushes the environment into paging. GC times are not affected by the size of the heap, just the number of live objects present in the heap. Being able to run the apps in a smaller heap does allow you to deploy on a cost-reduced platform, but that's about all. If the JVM is the sole application on the box, you might as well give it as much RAM as you've got (unless you want to run with compressed object pointers).
- 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by André Warnier <aw...@ice-sa.com>.
Ozgur Ozdemircili wrote:
> Hi,
>
> I have the default server.conf file with :
>
> <Connector port="8080" protocol="HTTP/1.1"
> maxThreads="250"
> connectionTimeout="20000"
> redirectPort="8443" />
>
> I do not have any Executor.
>
> When I check the manager status in detail I see the threads with ? in front
> and nothing else. The ones being used do have the data.
>
> Just wondering is it normal to have that much open threads waiting?
>
>
Let's get back to the basics for a minute.
How many requests are you expecting your server(s) to handle per unit of
time, and how long does one request take to process ?
And, once you get one request from a client, how many subsequent
follow-up requests do you expect that same client to send within any
short period of time ?
I mean, above you have connectionTimeout set to 20 seconds.
That means :
- when a first request comes in from a browser, a thread will be
allocated to process it. That thread will be busy with that one client,
and that one connection, for the duration it takes to process that request.
- when that request is processed, this same thread will still wait for
up to 20 seconds, doing nothing, just in case the same client, on the
same connection, would send another request.
It is only if no further request from the same client arrives within 20
seconds, that this thread will give up, close that connection, and
become available again to process another request.
So I would say that if you do not actually have the kind of client
interaction where many client requests come in "bursts" (like for
example returning a page with many image links in it), you could
probably save yourself a lot of idle waiting threads by reducing this
parameter to 3 seconds or so.
The second part is the memory usage.
You are getting OOM's with a 2 GB Heap.
2 GB is actually 2048 MegaByte, which is roughly 2048 times 1,000,000 (1
Million) bytes. I have customers who use less than that on disk, for
the database containing their accounts for a full year.
While Java never ceases to amaze me as to how much memory it can use,
there are reasonable applications running within Tomcat under a JVM with
a Heap of 128 MB, which is 1/16th of 2 GB.
So, while I am not saying that there are not circumstances where a 2 GB
Heap is justified, it is still a very high number, and maybe you should
have a look at which application really needs so much space.
Tomcat itself does not. I also have Tomcats running with a 64 MB Heap,
happily.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ozgur,
On 5/17/2010 5:28 AM, Ozgur Ozdemircili wrote:
> I have the default server.conf file with :
>
> <Connector port="8080" protocol="HTTP/1.1"
> maxThreads="250"
> connectionTimeout="20000"
> redirectPort="8443" />
>
> I do not have any Executor.
<Executor>s are smart enough to close-down inactive request processor
threads after a certain amount of inactivity: regular <Connector>s are
too dumb: once a thread is created, it lives until the <Connector> is
shut down (usually only as the server is being stopped).
If you have 186 active request processor threads, that indicates that
the maximum load you experienced since the last TC startup was 186
simultaneous requests: congratulations! You probably have a
correctly-sized request processor pool for your webapp.
> Just wondering is it normal to have that much open threads waiting?
Not necessarily a problem, but if you were monitoring your webapp
closely, you might want those threads to expire so you could better
track the usage of your webapp during certain periods of time (like,
"nobody uses our app at 0300 but we get a lot of activity at 0500...
maybe we ought to move our backups from 0500 to 0300" or something like
that.
Since you're getting OOMEs, you might want to think about your webapp
and answer this question: what am I doing that can take-up a lot of
memory? XML processing using the DOM API is often a killer, as is any
kind of graphical image manipulation. Another culprit is storing too
much information in user sessions: if each session needs 100MiB and you
need to support 20 users, there's your 2GiB heap.
There are a lot of things that can take up a lot of memory when you
start getting a whole bunch of users together into memory.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkvyjAkACgkQ9CaO5/Lv0PDEuACaA9pKP5bE8imCwHqyAVGjBAfi
vGwAnj+B/Fq47LvEoyQp9dRzspUYfnZZ
=RDuC
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by Ozgur Ozdemircili <oz...@gmail.com>.
Hi,
I have the default server.conf file with :
<Connector port="8080" protocol="HTTP/1.1"
maxThreads="250"
connectionTimeout="20000"
redirectPort="8443" />
I do not have any Executor.
When I check the manager status in detail I see the threads with ? in front
and nothing else. The ones being used do have the data.
Just wondering is it normal to have that much open threads waiting?
And André I have 4 Gb for each of the servers.
Özgür Özdemircili
http://www.acikkod.org
Code so clean you could eat off it
On Mon, May 17, 2010 at 11:15 AM, Pid <pi...@pidster.com> wrote:
> On 17/05/2010 09:56, Ozgur Ozdemircili wrote:
> > Hi,
> >
> > -Rhel 5.3 x64
> >
> > -java version "1.6.0_16"
> > Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> > Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
> >
> > -Apache tomcat 6.0.26
> >
> > -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>
> Each or 8Gb total?
>
> > On Mon, May 17, 2010 at 10:31 AM, Pid <pid@pidster.com
> >
> > On 17/05/2010 09:25, Ozgur Ozdemircili wrote:
> > > Hi,
> > >
> > > I am having a lot of Java Heap OutOfMemory issues. The first
> > change I did
> > > was to add more memory to JVM:
> > >
> > > export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m
> -server"
>
> Seems OK. We usually recommend -Xms and -Xmx being set to the same size
> so that the JVM doesn't have to keep resizing itself.
>
> > > Yet I have 2 questions
> > >
> > > - What are you real life configurations? In a very busy prod
> > environment
> > > what parameters do you use?
>
> The answer is entirely subjective. Unless we're running exactly the
> same application, our settings are meaningless to you.
>
> > > - Checking the Current and Busy threads I have Current at 145 and
> > Busy at 6,
> > > is this normal? Shouldn`t Tomcat close unused threads?
>
> Depends what the Threads are doing. If they are not Tomcat connector
> threads, then no. Do you have an Executor configured in server.xml?
>
> > > - After updating the server with "-XX:MaxPermSize=512m -Xms512m
> > -Xmx2048m
> > > -server" parameter although the Max mem should show 2048+512M it
> shows
> > > 1820.50 MB. Any ideas why?
>
> Because you specified a range between min and max that the heap can
> occupy, so the memory used is 512+(some resource stuff)+(a number
> between 512 and 2048).
>
>
> p
>
> > > Thank you for all the help.
> >
> > Please provide the exact OS, JVM and Tomcat versions you are using.
> >
> > Some clues about the server(s) architecture, memory available would
> also
> > be useful.
> >
> >
> > p
> >
> >
>
>
>
Re: MaxPermSize / Threads
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 10:15, Pid wrote:
> On 17/05/2010 09:56, Ozgur Ozdemircili wrote:
>> Hi,
>>
>> -Rhel 5.3 x64
>>
>> -java version "1.6.0_16"
>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>
>> -Apache tomcat 6.0.26
>>
>> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>
> Each or 8Gb total?
>
>> On Mon, May 17, 2010 at 10:31 AM, Pid <pid@pidster.com
>>
>> On 17/05/2010 09:25, Ozgur Ozdemircili wrote:
>> > Hi,
>> >
>> > I am having a lot of Java Heap OutOfMemory issues. The first
>> change I did
>> > was to add more memory to JVM:
>> >
>> > export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m -server"
Also: I think the -server argument isn't necessary on a 64bit JVM.
p
> Seems OK. We usually recommend -Xms and -Xmx being set to the same size
> so that the JVM doesn't have to keep resizing itself.
>
>> > Yet I have 2 questions
>> >
>> > - What are you real life configurations? In a very busy prod
>> environment
>> > what parameters do you use?
>
> The answer is entirely subjective. Unless we're running exactly the
> same application, our settings are meaningless to you.
>
>> > - Checking the Current and Busy threads I have Current at 145 and
>> Busy at 6,
>> > is this normal? Shouldn`t Tomcat close unused threads?
>
> Depends what the Threads are doing. If they are not Tomcat connector
> threads, then no. Do you have an Executor configured in server.xml?
>
>> > - After updating the server with "-XX:MaxPermSize=512m -Xms512m
>> -Xmx2048m
>> > -server" parameter although the Max mem should show 2048+512M it shows
>> > 1820.50 MB. Any ideas why?
>
> Because you specified a range between min and max that the heap can
> occupy, so the memory used is 512+(some resource stuff)+(a number
> between 512 and 2048).
>
>
> p
>
>> > Thank you for all the help.
>>
>> Please provide the exact OS, JVM and Tomcat versions you are using.
>>
>> Some clues about the server(s) architecture, memory available would also
>> be useful.
>>
>>
>> p
>>
>>
>
>
Re: MaxPermSize / Threads
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 09:56, Ozgur Ozdemircili wrote:
> Hi,
>
> -Rhel 5.3 x64
>
> -java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>
> -Apache tomcat 6.0.26
>
> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
Each or 8Gb total?
> On Mon, May 17, 2010 at 10:31 AM, Pid <pid@pidster.com
>
> On 17/05/2010 09:25, Ozgur Ozdemircili wrote:
> > Hi,
> >
> > I am having a lot of Java Heap OutOfMemory issues. The first
> change I did
> > was to add more memory to JVM:
> >
> > export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m -server"
Seems OK. We usually recommend -Xms and -Xmx being set to the same size
so that the JVM doesn't have to keep resizing itself.
> > Yet I have 2 questions
> >
> > - What are you real life configurations? In a very busy prod
> environment
> > what parameters do you use?
The answer is entirely subjective. Unless we're running exactly the
same application, our settings are meaningless to you.
> > - Checking the Current and Busy threads I have Current at 145 and
> Busy at 6,
> > is this normal? Shouldn`t Tomcat close unused threads?
Depends what the Threads are doing. If they are not Tomcat connector
threads, then no. Do you have an Executor configured in server.xml?
> > - After updating the server with "-XX:MaxPermSize=512m -Xms512m
> -Xmx2048m
> > -server" parameter although the Max mem should show 2048+512M it shows
> > 1820.50 MB. Any ideas why?
Because you specified a range between min and max that the heap can
occupy, so the memory used is 512+(some resource stuff)+(a number
between 512 and 2048).
p
> > Thank you for all the help.
>
> Please provide the exact OS, JVM and Tomcat versions you are using.
>
> Some clues about the server(s) architecture, memory available would also
> be useful.
>
>
> p
>
>
Re: MaxPermSize / Threads
Posted by Mercy <te...@gmail.com>.
Thank you.
Mercy
On 05/17/2010 08:58 PM, Pid wrote:
> On 17/05/2010 13:18, Mercy wrote:
>
>> Hi,
>>
>> Please take a look at this:
>> http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html
>>
>> *maximum heap size:*
>>
>> Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the
>> default maximum heap size was 64MB. You can override this default
>> using the |-Xmx| command-line option.
>>
>>
>> It does not mean just only use 1/4th, it will increase overload to
>> system if more than 1/4th of the physical memory.
>>
> That part of the document only describes the initial value of the
> maximum heap size parameter and how it is calculated, it doesn't make a
> recommendation for what is appropriate for a given system.
>
> I don't know what you mean by "it will increase overload to system if
> more than 1/4th of the physical memory"?
>
>
>
>> If you had more practical setting , please tell me.
>>
> The settings will be extremely specific to each environment and the
> behaviour of the applications you've deployed, both inside and outside
> of the JVM.
>
>
> p
>
>
>
>
>> On 05/17/2010 06:49 PM, Pid wrote:
>>
>>> On 17/05/2010 10:29, Mercy wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> You could set the one fourth of physical memory size(the recommended
>>>> heap size) for -Xms,-Xmx arguments.
>>>>
>>>>
>>> Where does this recommendation come from?
>>>
>>> It would mean that with 16Gb of RAM one should only use 4Gb for the heap.
>>>
>>>
>>> p
>>>
>>>
>>>
>>>> What's more, you also analyze the heap using jmap.
>>>>
>>>> Mercy
>>>>
>>>> On 05/17/2010 05:16 PM, André Warnier wrote:
>>>>
>>>>
>>>>> Ozgur Ozdemircili wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> -Rhel 5.3 x64
>>>>>>
>>>>>> -java version "1.6.0_16"
>>>>>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>>>>>
>>>>>> -Apache tomcat 6.0.26
>>>>>>
>>>>>> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>>>>>>
>>>>>>
>>>>>>
>>>>> Hè ? do you mean 4 Gb or 8GB total RAM ?
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 13:18, Mercy wrote:
> Hi,
>
> Please take a look at this:
> http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html
>
> *maximum heap size:*
>
> Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the
> default maximum heap size was 64MB. You can override this default
> using the |-Xmx| command-line option.
>
>
> It does not mean just only use 1/4th, it will increase overload to
> system if more than 1/4th of the physical memory.
That part of the document only describes the initial value of the
maximum heap size parameter and how it is calculated, it doesn't make a
recommendation for what is appropriate for a given system.
I don't know what you mean by "it will increase overload to system if
more than 1/4th of the physical memory"?
> If you had more practical setting , please tell me.
The settings will be extremely specific to each environment and the
behaviour of the applications you've deployed, both inside and outside
of the JVM.
p
> On 05/17/2010 06:49 PM, Pid wrote:
>> On 17/05/2010 10:29, Mercy wrote:
>>
>>> Hi,
>>>
>>> You could set the one fourth of physical memory size(the recommended
>>> heap size) for -Xms,-Xmx arguments.
>>>
>> Where does this recommendation come from?
>>
>> It would mean that with 16Gb of RAM one should only use 4Gb for the heap.
>>
>>
>> p
>>
>>
>>> What's more, you also analyze the heap using jmap.
>>>
>>> Mercy
>>>
>>> On 05/17/2010 05:16 PM, André Warnier wrote:
>>>
>>>> Ozgur Ozdemircili wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> -Rhel 5.3 x64
>>>>>
>>>>> -java version "1.6.0_16"
>>>>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>>>>
>>>>> -Apache tomcat 6.0.26
>>>>>
>>>>> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>>>>>
>>>>>
>>>> Hè ? do you mean 4 Gb or 8GB total RAM ?
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>>
>
Re: MaxPermSize / Threads
Posted by Peter Crowther <pe...@melandra.com>.
On 17 May 2010 13:18, Mercy <te...@gmail.com> wrote:
> Hi,
>
> Please take a look at this:
> http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html
>
> *maximum heap size:*
>
> Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the
> default maximum heap size was 64MB. You can override this default
> using the |-Xmx| command-line option.
>
>
> It does not mean just only use 1/4th, it will increase overload to system
> if more than 1/4th of the physical memory.
>
That page describes the default settings of the Java memory system: it will
use 1/4 of the physical memory of the machine.
> If you had more practical setting , please tell me.
>
> It depends on your application and your physical architecture. I've seen
16 Gbyte Windows machines with 12 Gbyte Java heaps - 4 Gbytes was enough for
the operating system, other processes, the disk cache, and Windows' crazy
insistence on keeping 10% "available". I've also seen 8 Gbyte machines with
64M devoted to Java, as the big memory hog was a database server on the same
machine.
Monitor your current settings to see what performance problems you are
seeing. If your JVM is not competing with anything else for resources, try
increasing heap memory to 50% or even 75% of RAM... but, each time you
change the setting, monitor the machine to see what performance problems you
have resolved and what new problems you have introduced.
"If you don't measure it, you can't fix it."
- Peter
Re: MaxPermSize / Threads
Posted by Mercy <te...@gmail.com>.
Hi,
Please take a look at this:
http://java.sun.com/javase/6/docs/technotes/guides/vm/gc-ergonomics.html
*maximum heap size:*
Smaller of 1/4th of the physical memory or 1GB. Before J2SE 5.0, the
default maximum heap size was 64MB. You can override this default
using the |-Xmx| command-line option.
It does not mean just only use 1/4th, it will increase overload to
system if more than 1/4th of the physical memory.
If you had more practical setting , please tell me.
Kind regards,
Mercy
On 05/17/2010 06:49 PM, Pid wrote:
> On 17/05/2010 10:29, Mercy wrote:
>
>> Hi,
>>
>> You could set the one fourth of physical memory size(the recommended
>> heap size) for -Xms,-Xmx arguments.
>>
> Where does this recommendation come from?
>
> It would mean that with 16Gb of RAM one should only use 4Gb for the heap.
>
>
> p
>
>
>> What's more, you also analyze the heap using jmap.
>>
>> Mercy
>>
>> On 05/17/2010 05:16 PM, André Warnier wrote:
>>
>>> Ozgur Ozdemircili wrote:
>>>
>>>> Hi,
>>>>
>>>> -Rhel 5.3 x64
>>>>
>>>> -java version "1.6.0_16"
>>>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>>>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>>>
>>>> -Apache tomcat 6.0.26
>>>>
>>>> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>>>>
>>>>
>>> Hè ? do you mean 4 Gb or 8GB total RAM ?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
Re: MaxPermSize / Threads
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 10:29, Mercy wrote:
> Hi,
>
> You could set the one fourth of physical memory size(the recommended
> heap size) for -Xms,-Xmx arguments.
Where does this recommendation come from?
It would mean that with 16Gb of RAM one should only use 4Gb for the heap.
p
> What's more, you also analyze the heap using jmap.
>
> Mercy
>
> On 05/17/2010 05:16 PM, André Warnier wrote:
>> Ozgur Ozdemircili wrote:
>>> Hi,
>>>
>>> -Rhel 5.3 x64
>>>
>>> -java version "1.6.0_16"
>>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>>
>>> -Apache tomcat 6.0.26
>>>
>>> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>>>
>> Hè ? do you mean 4 Gb or 8GB total RAM ?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: MaxPermSize / Threads
Posted by Mercy <te...@gmail.com>.
Hi,
You could set the one fourth of physical memory size(the
recommended heap size) for -Xms,-Xmx arguments.
What's more, you also analyze the heap using jmap.
Mercy
On 05/17/2010 05:16 PM, André Warnier wrote:
> Ozgur Ozdemircili wrote:
>> Hi,
>>
>> -Rhel 5.3 x64
>>
>> -java version "1.6.0_16"
>> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
>> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>>
>> -Apache tomcat 6.0.26
>>
>> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>>
> Hè ? do you mean 4 Gb or 8GB total RAM ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by André Warnier <aw...@ice-sa.com>.
Ozgur Ozdemircili wrote:
> Hi,
>
> -Rhel 5.3 x64
>
> -java version "1.6.0_16"
> Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
> Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
>
> -Apache tomcat 6.0.26
>
> -Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
>
Hè ? do you mean 4 Gb or 8GB total RAM ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: MaxPermSize / Threads
Posted by Ozgur Ozdemircili <oz...@gmail.com>.
Hi,
-Rhel 5.3 x64
-java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
-Apache tomcat 6.0.26
-Dual core Intel(R) Xeon(R) CPU E3110 @ 3.00GHz and 4 GB memory each.
Thanks.
Özgür Özdemircili
http://www.acikkod.org
Code so clean you could eat off it
On Mon, May 17, 2010 at 10:31 AM, Pid <pi...@pidster.com> wrote:
> On 17/05/2010 09:25, Ozgur Ozdemircili wrote:
> > Hi,
> >
> > I am having a lot of Java Heap OutOfMemory issues. The first change I did
> > was to add more memory to JVM:
> >
> > export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m -server"
> >
> > Yet I have 2 questions
> >
> > - What are you real life configurations? In a very busy prod environment
> > what parameters do you use?
> >
> > - Checking the Current and Busy threads I have Current at 145 and Busy at
> 6,
> > is this normal? Shouldn`t Tomcat close unused threads?
> >
> > - After updating the server with "-XX:MaxPermSize=512m -Xms512m -Xmx2048m
> > -server" parameter although the Max mem should show 2048+512M it shows
> > 1820.50 MB. Any ideas why?
> >
> > Thank you for all the help.
>
> Please provide the exact OS, JVM and Tomcat versions you are using.
>
> Some clues about the server(s) architecture, memory available would also
> be useful.
>
>
> p
>
>
Re: MaxPermSize / Threads
Posted by Pid <pi...@pidster.com>.
On 17/05/2010 09:25, Ozgur Ozdemircili wrote:
> Hi,
>
> I am having a lot of Java Heap OutOfMemory issues. The first change I did
> was to add more memory to JVM:
>
> export CATALINA_OPTS="-XX:MaxPermSize=512m -Xms512m -Xmx2048m -server"
>
> Yet I have 2 questions
>
> - What are you real life configurations? In a very busy prod environment
> what parameters do you use?
>
> - Checking the Current and Busy threads I have Current at 145 and Busy at 6,
> is this normal? Shouldn`t Tomcat close unused threads?
>
> - After updating the server with "-XX:MaxPermSize=512m -Xms512m -Xmx2048m
> -server" parameter although the Max mem should show 2048+512M it shows
> 1820.50 MB. Any ideas why?
>
> Thank you for all the help.
Please provide the exact OS, JVM and Tomcat versions you are using.
Some clues about the server(s) architecture, memory available would also
be useful.
p