Re: Memory problems due to org.apache.tomcat.dbcp.dbcp.AbandonedTrace?

[Mark Thomas]

On 25/06/2019 12:58, Christoph Hanke wrote:
> Hi,
> 
> I have got a jspx Page which gets reloaded every 30 seconds to show some
> status information. Consequently there are database requests every 30
> seconds. Before switching from glassfish to tomcat (7.0.94) there were
> no issues with that, but now the memory consumption is bloating over time.
> 
> Looking at the heapdump I recognized that the the traceLists of the used
> preparedStatements and the resultSets are the cause of the memory
> consumption. 
> 
> I already tried to use***removeAbandoned*=true and
> setting*removeAbandonedTimeout=5 *seconds, as well as turning off my
> jspx-database-requests over night,  thinking this could provide the
> necessary "timeout" for the connection / AbandonedTrace objects (
> https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/dbcp/dbcp/AbandonedTrace.html
> ) to get cleaned up. Unfortuneatly it did not. I'm now thinking to turn
> of the tracking (by using |*clearTrace
> *()|
> ) but it seems a little bit hackish to me. Has someone eventually an
> idea where to look at or what to do?

Do the logs indicate you have a connection leak?

Mark

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

Memory problems due to org.apache.tomcat.dbcp.dbcp.AbandonedTrace?

[Christoph Hanke]

Hi,

I have got a jspx Page which gets reloaded every 30 seconds to show some
status information. Consequently there are database requests every 30
seconds. Before switching from glassfish to tomcat (7.0.94) there were
no issues with that, but now the memory consumption is bloating over time.

Looking at the heapdump I recognized that the the traceLists of the used
preparedStatements and the resultSets are the cause of the memory
consumption. 

I already tried to use***removeAbandoned*=true and
setting*removeAbandonedTimeout=5 *seconds, as well as turning off my
jspx-database-requests over night,  thinking this could provide the
necessary "timeout" for the connection / AbandonedTrace objects (
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/tomcat/dbcp/dbcp/AbandonedTrace.html
) to get cleaned up. Unfortuneatly it did not. I'm now thinking to turn
of the tracking (by using |*clearTrace
*()|
) but it seems a little bit hackish to me. Has someone eventually an
idea where to look at or what to do?

Kind regards

Chris

Re: Memory problems caused by the messageBufferText CharBuffer in WSFrameBase.java

[Mark Thomas]

On 21/06/2016 15:52, Afaf Zahkya wrote:
> Hello,
> 
> I m using tomcat 8.0.21.
> 
> I want to send *up* to 4 MB of text messages through a websocket connection
> to my tomcat server. I set the MaxTextMessageBufferSize to 4 MB.Now as a
> result, every time I open a websocket  connection and I send a message , I
> can see that 4 MB are  being allocated in memory for the CharBuffer
> messageBufferText regardless of the size of the message I send . 99 % of my
> messages would be way smaller.The 4 MB  remain allocated in the
> messageBufferText CharBuffer even after the message is handled.  The
> connection can stay open up to 30 minutes in my case, and each  websocket
> connection is taking 4 MB of memory all of that time even if it's inactive
> which leads my server to eventually run out of memory even with inactive
> connections  . Note that I m using a Whole Message Handler.
> 
> in WSFrameBase.java  why not set the messageBufferText CharBuffer size to
> the payload length if it doesn't exceed the maxTextMessageBufferSize, and
> then clearing that buffer ( reducing its size) after the message is handled
> by the Handler, so that inactive connections don't take up memory. ( same
> for the binary) ?

GC churn.

> Any other / better suggestions on how to solve that problem ?

If you want scalability and the ability to handle messages that vary
significantly in size use a partial message handler.

Mark

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

Memory problems caused by the messageBufferText CharBuffer in WSFrameBase.java

[Afaf Zahkya]

Hello,

I m using tomcat 8.0.21.

I want to send *up* to 4 MB of text messages through a websocket connection
to my tomcat server. I set the MaxTextMessageBufferSize to 4 MB.Now as a
result, every time I open a websocket  connection and I send a message , I
can see that 4 MB are  being allocated in memory for the CharBuffer
messageBufferText regardless of the size of the message I send . 99 % of my
messages would be way smaller.The 4 MB  remain allocated in the
messageBufferText CharBuffer even after the message is handled.  The
connection can stay open up to 30 minutes in my case, and each  websocket
connection is taking 4 MB of memory all of that time even if it's inactive
which leads my server to eventually run out of memory even with inactive
connections  . Note that I m using a Whole Message Handler.

in WSFrameBase.java  why not set the messageBufferText CharBuffer size to
the payload length if it doesn't exceed the maxTextMessageBufferSize, and
then clearing that buffer ( reducing its size) after the message is handled
by the Handler, so that inactive connections don't take up memory. ( same
for the binary) ?

Any other / better suggestions on how to solve that problem ?

Thanks.

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Just for completeness on anyone reading this...

Setting development mode to false has vastly improved the performance, as is
no doubt already known by most people! My Old Generation memory now cycles
nicely, clearing out by 75% each time.

I also added the "checkInterval" parameter (at anything greater than zero)
to enable background compiling of JSPs, otherwise any changes to the JSP
files are not reflected on the website if development mode is false.

Thanks again for the help Mark... and guess what... we have since been asked
to upgrade to Tomcat-7.0.19 by our PCI auditors! Useful!

Ian


On 29 July 2011 13:09, Ian Marsh  wrote:

> Bugger thanks.
>
> I looked at this but, when I did, I simply compared the two web.xml
> files between Tomcat-7.0.8 and Tomcat-7.0.10 to see if a specific
> setting for development mode was used differently, but the two files
> were exactly the same, with no development mode setting mentioned.
> Which means they are both running in development mode, but with
> different behaviours, as I have only just seen that the default
> setting for it is "true".
>
> I will try running Tomcat-7.0.10 with development mode set as false to
> see if this fixes it.
>
> Thanks again, sorry for such an oversight.
>
>
> On 29 July 2011 12:27, Mark Thomas  wrote:
> > On 29/07/2011 09:53, Ian Marsh wrote:
> >> Ok thanks... so here's the trace of the 3 biggest
> >> org.apache.jasper.servlet.JspServletWrapper objects.
> >>
> >> I'm just showing the path of the objects that retain the biggest sizes
> >> at each nested level to save from overkill on detail. There are
> >> references to parent objects at some levels which show a larger
> >> retained size but I expect that's normal. If it would be useful to see
> >> all nested objects at each level, no problem, but here's a first
> >> look...
> >>
> >> 1)
> >> + org.apache.jasper.servlet.JspServletWrapper (1,608,752)
> >> =+ ctxt  org.apache.jasper.JspCompilationContext (1,602,384)
> >> ==+ jspCompiler  org.apache.jasper.compiler.JDTCompiler (1,601,032)
> >> ===+ pageNodes  org.apache.jasper.compiler.Node$Nodes (1,600,952)
> >
> > Which takes us back to my comment of almost a week ago. You have
> > development mode enabled which retains the pageNodes for improved error
> > messages. Disable development mode and the memory usage should fall.
> >
> > I don't recall any changes to this code bewteen 7.0.8 and 7.0.10 but to
> > be sure, I have double checked that disabling development mode does
> > indeed have the desired effect.
> >
> > To fix this:
> > - edit $CATALINA_BASE/conf/web.xml
> > - find the definition for the servlet named "jsp"
> > - add the following init parameter
> >
> >development
> >false
> >
> >
> > Mark
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Bugger thanks.

I looked at this but, when I did, I simply compared the two web.xml
files between Tomcat-7.0.8 and Tomcat-7.0.10 to see if a specific
setting for development mode was used differently, but the two files
were exactly the same, with no development mode setting mentioned.
Which means they are both running in development mode, but with
different behaviours, as I have only just seen that the default
setting for it is "true".

I will try running Tomcat-7.0.10 with development mode set as false to
see if this fixes it.

Thanks again, sorry for such an oversight.


On 29 July 2011 12:27, Mark Thomas  wrote:
> On 29/07/2011 09:53, Ian Marsh wrote:
>> Ok thanks... so here's the trace of the 3 biggest
>> org.apache.jasper.servlet.JspServletWrapper objects.
>>
>> I'm just showing the path of the objects that retain the biggest sizes
>> at each nested level to save from overkill on detail. There are
>> references to parent objects at some levels which show a larger
>> retained size but I expect that's normal. If it would be useful to see
>> all nested objects at each level, no problem, but here's a first
>> look...
>>
>> 1)
>> + org.apache.jasper.servlet.JspServletWrapper (1,608,752)
>> =+ ctxt  org.apache.jasper.JspCompilationContext (1,602,384)
>> ==+ jspCompiler  org.apache.jasper.compiler.JDTCompiler (1,601,032)
>> ===+ pageNodes  org.apache.jasper.compiler.Node$Nodes (1,600,952)
>
> Which takes us back to my comment of almost a week ago. You have
> development mode enabled which retains the pageNodes for improved error
> messages. Disable development mode and the memory usage should fall.
>
> I don't recall any changes to this code bewteen 7.0.8 and 7.0.10 but to
> be sure, I have double checked that disabling development mode does
> indeed have the desired effect.
>
> To fix this:
> - edit $CATALINA_BASE/conf/web.xml
> - find the definition for the servlet named "jsp"
> - add the following init parameter
>        
>            development
>            false
>        
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Mark Thomas]

On 29/07/2011 09:53, Ian Marsh wrote:
> Ok thanks... so here's the trace of the 3 biggest
> org.apache.jasper.servlet.JspServletWrapper objects.
> 
> I'm just showing the path of the objects that retain the biggest sizes
> at each nested level to save from overkill on detail. There are
> references to parent objects at some levels which show a larger
> retained size but I expect that's normal. If it would be useful to see
> all nested objects at each level, no problem, but here's a first
> look...
> 
> 1)
> + org.apache.jasper.servlet.JspServletWrapper (1,608,752)
> =+ ctxt  org.apache.jasper.JspCompilationContext (1,602,384)
> ==+ jspCompiler  org.apache.jasper.compiler.JDTCompiler (1,601,032)
> ===+ pageNodes  org.apache.jasper.compiler.Node$Nodes (1,600,952)

Which takes us back to my comment of almost a week ago. You have
development mode enabled which retains the pageNodes for improved error
messages. Disable development mode and the memory usage should fall.

I don't recall any changes to this code bewteen 7.0.8 and 7.0.10 but to
be sure, I have double checked that disabling development mode does
indeed have the desired effect.

To fix this:
- edit $CATALINA_BASE/conf/web.xml
- find the definition for the servlet named "jsp"
- add the following init parameter

development
false


Mark

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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Ok thanks... so here's the trace of the 3 biggest
org.apache.jasper.servlet.JspServletWrapper objects.

I'm just showing the path of the objects that retain the biggest sizes
at each nested level to save from overkill on detail. There are
references to parent objects at some levels which show a larger
retained size but I expect that's normal. If it would be useful to see
all nested objects at each level, no problem, but here's a first
look...

1)
+ org.apache.jasper.servlet.JspServletWrapper (1,608,752)
=+ ctxt  org.apache.jasper.JspCompilationContext (1,602,384)
==+ jspCompiler  org.apache.jasper.compiler.JDTCompiler (1,601,032)
===+ pageNodes  org.apache.jasper.compiler.Node$Nodes (1,600,952)
+ root  org.apache.jasper.compiler.Node$Root (1,600,840)
=+ body  org.apache.jasper.compiler.Node$Nodes (1,501,368)
==+ list  java.util.Vector (1,501,344)
===+ elementData  java.lang.Object[160] (1,501,312)
+ [0]  org.apache.jasper.compiler.Node$IncludeDirective (32,464)
=+ body  org.apache.jasper.compiler.Node$Nodes (31,776)
==+ list  java.util.Vector (31,752)
===+ elementData  java.lang.Object[10] (31,720)
+ [0]  org.apache.jasper.compiler.Node$Root (31,664)
=+ body  org.apache.jasper.compiler.Node$Nodes (27,432)
==+ list  java.util.Vector (27,408)
===+ elementData  java.lang.Object[80] (27,376)
+ [0]  org.apache.jasper.compiler.Node$PageDirective (1,480)
=+ attrs  org.apache.jasper.util.UniqueAttributesImpl (1,176)
==+   org.apache.jasper.util.UniqueAttributesImpl (936)
==+ data  java.lang.String[25] (464)
==+ qNames  java.util.HashSet (304)
==+ length = int 5  0x0005
==+ pageDirective = boolean true

2)
+ org.apache.jasper.servlet.JspServletWrapper (1,534,320)
=+ ctxt  org.apache.jasper.JspCompilationContext (1,406,208)
==+ jspCompiler  org.apache.jasper.compiler.JDTCompiler (1,404,944)
===+ pageNodes  org.apache.jasper.compiler.Node$Nodes (1,404,864)
+ root  org.apache.jasper.compiler.Node$Root (1,404,752)
=+ body  org.apache.jasper.compiler.Node$Nodes (1,303,480)
==+ list  java.util.Vector (1,303,456)
===+ elementData  java.lang.Object[320] (1,303,424)
+ [0]  org.apache.jasper.compiler.Node$IncludeDirective (32,464)
=+ body  org.apache.jasper.compiler.Node$Nodes (31,776)
==+ list  java.util.Vector (31,752)
===+ elementData  java.lang.Object[10] (31,720)
+ [0]  org.apache.jasper.compiler.Node$Root (31,664)
=+ body  org.apache.jasper.compiler.Node$Nodes (27,432)
==+ list  java.util.Vector (27,408)
===+ elementData  java.lang.Object[80] (27,376)
+ [0]  org.apache.jasper.compiler.Node$PageDirective (1,480)
=+ attrs  org.apache.jasper.util.UniqueAttributesImpl (1,176)
==+   org.apache.jasper.util.UniqueAttributesImpl (936)
==+ data  java.lang.String[25] (464)
==+ qNames  java.util.HashSet (304)
==+ length = int 5  0x0005
==+ pageDirective = boolean true

3)
+ org.apache.jasper.servlet.JspServletWrapper (1,454,520)
=+ ctxt  org.apache.jasper.JspCompilationContext (1,381,656)
==+ jspCompiler  org.apache.jasper.compiler.JDTCompiler (1,380,136)
===+ pageNodes  org.apache.jasper.compiler.Node$Nodes (1,380,056)
+ root  org.apache.jasper.compiler.Node$Root (1,379,944)
=+ body  org.apache.jasper.compiler.Node$Nodes (1,220,552)
==+ list  java.util.Vector (1,220,528)
===+ elementData  java.lang.Object[2560] (1,220,496)
+ [2]  org.apache.jasper.compiler.Node$IncludeDirective (22,744)
=+ body  org.apache.jasper.compiler.Node$Nodes (22,040)
==+ list  java.util.Vector (22,016)
===+ elementData  java.lang.Object[10] (21,984)
+ [0]  org.apache.jasper.compiler.Node$Root (21,928)
=+ body  org.apache.jasper.compiler.Node$Nodes (18,680)
==+ list  java.util.Vector (18,656)
===+ elementData  java.lang.Object[40] (18,624)
+ [1]  org.apache.jasper.compiler.Node$TemplateText (808)
=+ parent  org.apache.jasper.compiler.Node$Root (21,928)
=+   org.apache.jasper.compiler.Node$TemplateText (856)
=+ extraSmap  java.util.ArrayList (496)
=+ startMark  org.apache.jasper.compiler.Mark (144)
=+ text  java.lang.String " " (96)
=+ beginJavaLine = int 103  0x0067
=+ endJavaLine = int 125  0x007D
=+ isDummy = boolean false

Hopefully these are a good examples of what's being held. It is a very
similar story for the other objects, with varying sizes and array
lengths at the relevant levels etc.

There are 3,772 org.apache.jasper.servlet.JspServletWrapper objects in
total, the top 6 retain...

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Mark Thomas]

On 28/07/2011 12:29, Ian Marsh wrote:
> Right, I have taken a memory snapshot using YourKit of the system
> running Tomcat-7.0.10 after about 1 hour, when the Old Gen memory was
> beginning to reach its maximum.

OK. I think a little more digging is required but this might be heading
somewhere useful.

> So I looked into the "Selected Objects" of the
> java.util.concurrent.ConcurrentHashMap$Segment[16]. This contains...
> 
> + java.util.concurrent.ConcurrentHashMap$Segment[16] (732,561,032)
> =+ [14]  java.util.concurrent.ConcurrentHashMap$Segment (55,193,864)
> ==+ table  java.util.concurrent.ConcurrentHashMap$HashEntry[512] (55,193,792)
> ===+ [16]  java.util.concurrent.ConcurrentHashMap$HashEntry (496,712)
> + value  org.apache.jasper.servlet.JspServletWrapper (496,448)

Filter for objects of org.apache.jasper.servlet.JspServletWrapper and
trace where the bulk of the retained size is for the few largest. That
should move things forward a little.

The level of detail in here is about right. Enough to see where to go
next, not so much it takes ages to analyse.

Mark

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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Right, I have taken a memory snapshot using YourKit of the system
running Tomcat-7.0.10 after about 1 hour, when the Old Gen memory was
beginning to reach its maximum.

I am not completely sure what information is useful for you to know as
I have not used YourKit before so I am working from the demos and
support docs that YourKit provide, hopefully they're the right things
to be looking at. If there's anything missing or this isn't helpful
information, I apologise in advance as I don't mean to waste anyone's
time.

So... ordering the "Class List" by retained size, in bytes, gives the
top entries as...

java.util.concurrent.ConcurrentHashMap$Segment (retained size: 755,981,384)
java.util.concurrent.ConcurrentHashMap$HashEntry (retained size: 735,577,824)
java.util.concurrent.ConcurrentHashMap$Segment[] (retained size: 753,281,704)
...

The top entries when restricted to match "org.apache" are...
org.apache.jasper.servlet.JspServlet (retained size: 732,632,608)
org.apache.jasper.compiler.JspRuntimeContext (retained size: 732,613,072)
org.apache.jasper.servlet.JspServletWrapper (retained size: 714,078,800)
...

Looking at the "Biggest objects (dominators)" section shows a top entry of...
org.apache.jasper.servlet.JspServlet (retained size: 732,615,184)

Which is considerably bigger than the next in the list, at 12,235,872 bytes.

Expanding this top entry in "Biggest objects (dominators)" shows...
+ org.apache.jasper.servlet.JspServlet (732,615,184)
=+ org.apache.jasper.compiler.JspRuntimeContext (732,596,248)
==+ java.util.concurrent.ConcurrentHashMap (732,561,080)
===+ java.util.concurrent.ConcurrentHashMap$Segment[16] (732,561,032)
+ java.util.concurrent.ConcurrentHashMap$Segment (55,193,864)
+ java.util.concurrent.ConcurrentHashMap$Segment (49,947,008)
+  (the rest of the 16 map entries, of similar size)

So I looked into the "Selected Objects" of the
java.util.concurrent.ConcurrentHashMap$Segment[16]. This contains...

+ java.util.concurrent.ConcurrentHashMap$Segment[16] (732,561,032)
=+ [14]  java.util.concurrent.ConcurrentHashMap$Segment (55,193,864)
==+ table  java.util.concurrent.ConcurrentHashMap$HashEntry[512] (55,193,792)
===+ [16]  java.util.concurrent.ConcurrentHashMap$HashEntry (496,712)
+ value  org.apache.jasper.servlet.JspServletWrapper (496,448)
+ key  java.lang.String "/directory-name/file-name.jsp" (32)
+ hash = int -457695728  0xE4B81E10
===+ [1]  java.util.concurrent.ConcurrentHashMap$HashEntry (96,912)
===+ [13]  java.util.concurrent.ConcurrentHashMap$HashEntry (27,488)
===+ ... (the rest of the 512 map entries)
==+ sync  java.util.concurrent.locks.ReentrantLock$NonfairSync (32)
==+ count = int 248  0x00F8
==+ loadFactor = float 0.75
==+ modCount = int 248  0x00F8
==+ threshold = int 384  0x0180
=+ [9]  java.util.concurrent.ConcurrentHashMap$Segment (49,947,008)
=+ [13]  java.util.concurrent.ConcurrentHashMap$Segment (49,717,568)
=+ ... (the rest of the 16 map entries)

I don't want this to become any more unreadable than it might already
be so maybe this is a reasonable point to stop at to see if I'm even
going down the right route.

>From what I can make out simply, there is a large HashMap (~700MB)
holding references to JspServletWrappers indexed by the JSP page uri,
which garbage collection has little impact on. I have looked further
into the JspServletWrapper, would this information be useful for
anyone? It did not reveal much to my limited knowledge! Or is this
enough to show that it is very much looking like something within our
JSPs that's causing the issues rather than a difference between the
versions of Tomcat?

Ian




On 26 July 2011 10:52, Mark Thomas  wrote:
> On 26/07/2011 10:43, Ian Marsh wrote:
>> Unfortunately the conf changes to fork the compilation of JSPs and the
>> increased 'modificationTestInterval' value made no real improvement so
>> I am continuing to work towards replacing the language text request
>> scope variables with property files references.
>>
>> However, if this is a problem, this has made me concerned that all
>> request scope variables aren't being released, not just the ones we
>> use for language text!
>
> Again, use a profiler and follow the gc roots. Until you provide some
> evidence that Tomcat is doing something wrong, the assumption is going
> to be that the problem is with the application.
>
> Mark
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Mark Thomas]

On 26/07/2011 10:43, Ian Marsh wrote:
> Unfortunately the conf changes to fork the compilation of JSPs and the
> increased 'modificationTestInterval' value made no real improvement so
> I am continuing to work towards replacing the language text request
> scope variables with property files references.
> 
> However, if this is a problem, this has made me concerned that all
> request scope variables aren't being released, not just the ones we
> use for language text!

Again, use a profiler and follow the gc roots. Until you provide some
evidence that Tomcat is doing something wrong, the assumption is going
to be that the problem is with the application.

Mark



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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Unfortunately the conf changes to fork the compilation of JSPs and the
increased 'modificationTestInterval' value made no real improvement so
I am continuing to work towards replacing the language text request
scope variables with property files references.

However, if this is a problem, this has made me concerned that all
request scope variables aren't being released, not just the ones we
use for language text!

Ian


On 25 July 2011 10:45, Ian Marsh  wrote:
> Good morning and thanks for the replies!
>
> Unfortunately, as far as I am aware, our bank determines who we must
> use as the PCI Auditor so our hands are tied with that one, but it
> does seem like they're just covering their backs by choosing the
> latest available version rather than actually determining a reason as
> to why its needed.
>
> However, thanks for looking into my problem... the first thing that
> rang a bell was the mention that it could be to do with the JSPs. I
> have checked for development mode settings and neither have it
> enabled. The bell it rang though was that, for some slightly silly
> reasons that I am planning on finally clearing up today to see if they
> are the cause, we have, in certain pages of the site, roughly 1000
>  tags of text for different languages set in request scope. I
> know these should be implemented through properties files instead but
> the excuses are for me to deal with not you guys!
>
> Could this be link to the cause though? Could it somehow be that the
> text variables are being held or referenced for longer than the
> request scope period and so quickly eating up memory?
>
> I also remembered some changes we made to the tomcat settings in
> web.xml to fork the compilation of JSPs to a separate JVM and we had
> set the 'modificationTestInterval' to 40 seconds. These may have had
> an impact as well so I'll change these in the later versions of Tomcat
> to see if they have any effect.
>
> Thanks again,
>
> Ian
>
>
>
>
> On 22 July 2011 22:42, Pid  wrote:
>> On 22/07/2011 20:17, Mark Thomas wrote:
>>> On 22/07/2011 17:26, Ian Marsh wrote:
 Hi,

 I am in charge of running a Apache-2, Tomcat-7, Ubuntu-10.04 set up
 for which we have to be PCI Compliant. We recently upgraded to
 Apache-2.2.17 and Tomcat-7.0.8 (from Apache-2.0.x and Tomcat 5.0.28)
 in order to comply with the requirements of the PCI Compliance checks
 and ironed out any issues to get us back to a satisfactory running
 state.
>>>
>>> Hmm. I think you need some better PCI auditors. If your app was running
>>> on Tomcat 5.0.x and you trust the app (which seems reasonable given it
>>> is doing something that requires PCI compliance) then an upgrade to
>>> 7.0.12 should be sufficient if you using the HTTP BIO connector.
>>
>> Indeed.
>>
>> In my experience, I'd expect a QSA/PCI Auditor to be far, far more
>> conservative than to promote Tomcat 7.0.x as a 'safe' version compared
>> to 6.0.recent.
>>
>>
>> p
>>
>>
>>> Since Tomcat appears to behind httpd then there is a strong chance you
>>> are using AJP (BIO or APR), in which case 7.0.2 should be sufficient.
>>>
>>> It appears your current auditors are blindly (and wrongly) assuming any
>>> vulnerability in Tomcat will impact your installation. Expect a demand
>>> to upgrade to 7.0.19 when they get around to reading the Tomcat security
>>> pages again.
>>>
>>> 
>>>
 It seems that the character arrays [C, java.lang.String and
 javax.servlet.jsp.tagext.TagAttributeInfo entries are considerably
 higher in Tomcat-7.0.10 than in Tomcat-7.0.8 and I am wondering if
 this could lead to an explanation for the difference.
>>>
>>> Maybe. What you really want to look at is the GC roots for those
>>> objects. That will tell you what is holding on to the references. Based
>>> on that data I'd start looking at the arrays of TagAttributeInfo but
>>> that might be completely the wrong place to look.
>>>
>>> I've just triggered a heap dump on the ASF Jira instance (running
>>> 7.0.19) to see what that looks like. I'll report back what I find (once
>>> the 4GB heap has finished downloading - it may be some time).
>>>
 Would anyone know of any changes between the two versions, possibly
 linked to those memory entries, that could lead to such behaviour?
>>>
>>> Nothing jumped out at me from the changelog.
>>>
 Any help or suggestions is greatly appreciated! I'm sorry for a long
 post, but hopefully its got the information needed to help diagnosis.
>>>
>>> To be honest, there isn't enough info hear to diagnose the root cause
>>> but there is enough to demonstrate that there is probably a problem and
>>> maybe where to start looking. That might not seem like much but it is a
>>> heck of a lot better than most of the reports we get here. Thanks for
>>> providing such a useful problem report.
>>>
>>> Mark
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.o

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Good morning and thanks for the replies!

Unfortunately, as far as I am aware, our bank determines who we must
use as the PCI Auditor so our hands are tied with that one, but it
does seem like they're just covering their backs by choosing the
latest available version rather than actually determining a reason as
to why its needed.

However, thanks for looking into my problem... the first thing that
rang a bell was the mention that it could be to do with the JSPs. I
have checked for development mode settings and neither have it
enabled. The bell it rang though was that, for some slightly silly
reasons that I am planning on finally clearing up today to see if they
are the cause, we have, in certain pages of the site, roughly 1000
 tags of text for different languages set in request scope. I
know these should be implemented through properties files instead but
the excuses are for me to deal with not you guys!

Could this be link to the cause though? Could it somehow be that the
text variables are being held or referenced for longer than the
request scope period and so quickly eating up memory?

I also remembered some changes we made to the tomcat settings in
web.xml to fork the compilation of JSPs to a separate JVM and we had
set the 'modificationTestInterval' to 40 seconds. These may have had
an impact as well so I'll change these in the later versions of Tomcat
to see if they have any effect.

Thanks again,

Ian




On 22 July 2011 22:42, Pid  wrote:
> On 22/07/2011 20:17, Mark Thomas wrote:
>> On 22/07/2011 17:26, Ian Marsh wrote:
>>> Hi,
>>>
>>> I am in charge of running a Apache-2, Tomcat-7, Ubuntu-10.04 set up
>>> for which we have to be PCI Compliant. We recently upgraded to
>>> Apache-2.2.17 and Tomcat-7.0.8 (from Apache-2.0.x and Tomcat 5.0.28)
>>> in order to comply with the requirements of the PCI Compliance checks
>>> and ironed out any issues to get us back to a satisfactory running
>>> state.
>>
>> Hmm. I think you need some better PCI auditors. If your app was running
>> on Tomcat 5.0.x and you trust the app (which seems reasonable given it
>> is doing something that requires PCI compliance) then an upgrade to
>> 7.0.12 should be sufficient if you using the HTTP BIO connector.
>
> Indeed.
>
> In my experience, I'd expect a QSA/PCI Auditor to be far, far more
> conservative than to promote Tomcat 7.0.x as a 'safe' version compared
> to 6.0.recent.
>
>
> p
>
>
>> Since Tomcat appears to behind httpd then there is a strong chance you
>> are using AJP (BIO or APR), in which case 7.0.2 should be sufficient.
>>
>> It appears your current auditors are blindly (and wrongly) assuming any
>> vulnerability in Tomcat will impact your installation. Expect a demand
>> to upgrade to 7.0.19 when they get around to reading the Tomcat security
>> pages again.
>>
>> 
>>
>>> It seems that the character arrays [C, java.lang.String and
>>> javax.servlet.jsp.tagext.TagAttributeInfo entries are considerably
>>> higher in Tomcat-7.0.10 than in Tomcat-7.0.8 and I am wondering if
>>> this could lead to an explanation for the difference.
>>
>> Maybe. What you really want to look at is the GC roots for those
>> objects. That will tell you what is holding on to the references. Based
>> on that data I'd start looking at the arrays of TagAttributeInfo but
>> that might be completely the wrong place to look.
>>
>> I've just triggered a heap dump on the ASF Jira instance (running
>> 7.0.19) to see what that looks like. I'll report back what I find (once
>> the 4GB heap has finished downloading - it may be some time).
>>
>>> Would anyone know of any changes between the two versions, possibly
>>> linked to those memory entries, that could lead to such behaviour?
>>
>> Nothing jumped out at me from the changelog.
>>
>>> Any help or suggestions is greatly appreciated! I'm sorry for a long
>>> post, but hopefully its got the information needed to help diagnosis.
>>
>> To be honest, there isn't enough info hear to diagnose the root cause
>> but there is enough to demonstrate that there is probably a problem and
>> maybe where to start looking. That might not seem like much but it is a
>> heck of a lot better than most of the reports we get here. Thanks for
>> providing such a useful problem report.
>>
>> Mark
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Pid]

On 22/07/2011 20:17, Mark Thomas wrote:
> On 22/07/2011 17:26, Ian Marsh wrote:
>> Hi,
>>
>> I am in charge of running a Apache-2, Tomcat-7, Ubuntu-10.04 set up
>> for which we have to be PCI Compliant. We recently upgraded to
>> Apache-2.2.17 and Tomcat-7.0.8 (from Apache-2.0.x and Tomcat 5.0.28)
>> in order to comply with the requirements of the PCI Compliance checks
>> and ironed out any issues to get us back to a satisfactory running
>> state.
> 
> Hmm. I think you need some better PCI auditors. If your app was running
> on Tomcat 5.0.x and you trust the app (which seems reasonable given it
> is doing something that requires PCI compliance) then an upgrade to
> 7.0.12 should be sufficient if you using the HTTP BIO connector.

Indeed.

In my experience, I'd expect a QSA/PCI Auditor to be far, far more
conservative than to promote Tomcat 7.0.x as a 'safe' version compared
to 6.0.recent.


p


> Since Tomcat appears to behind httpd then there is a strong chance you
> are using AJP (BIO or APR), in which case 7.0.2 should be sufficient.
> 
> It appears your current auditors are blindly (and wrongly) assuming any
> vulnerability in Tomcat will impact your installation. Expect a demand
> to upgrade to 7.0.19 when they get around to reading the Tomcat security
> pages again.
> 
> 
> 
>> It seems that the character arrays [C, java.lang.String and
>> javax.servlet.jsp.tagext.TagAttributeInfo entries are considerably
>> higher in Tomcat-7.0.10 than in Tomcat-7.0.8 and I am wondering if
>> this could lead to an explanation for the difference.
> 
> Maybe. What you really want to look at is the GC roots for those
> objects. That will tell you what is holding on to the references. Based
> on that data I'd start looking at the arrays of TagAttributeInfo but
> that might be completely the wrong place to look.
> 
> I've just triggered a heap dump on the ASF Jira instance (running
> 7.0.19) to see what that looks like. I'll report back what I find (once
> the 4GB heap has finished downloading - it may be some time).
> 
>> Would anyone know of any changes between the two versions, possibly
>> linked to those memory entries, that could lead to such behaviour?
> 
> Nothing jumped out at me from the changelog.
> 
>> Any help or suggestions is greatly appreciated! I'm sorry for a long
>> post, but hopefully its got the information needed to help diagnosis.
> 
> To be honest, there isn't enough info hear to diagnose the root cause
> but there is enough to demonstrate that there is probably a problem and
> maybe where to start looking. That might not seem like much but it is a
> heck of a lot better than most of the reports we get here. Thanks for
> providing such a useful problem report.
> 
> Mark
> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Mark Thomas]

On 22/07/2011 20:17, Mark Thomas wrote:
> On 22/07/2011 17:26, Ian Marsh wrote:

>> It seems that the character arrays [C, java.lang.String and
>> javax.servlet.jsp.tagext.TagAttributeInfo entries are considerably
>> higher in Tomcat-7.0.10 than in Tomcat-7.0.8 and I am wondering if
>> this could lead to an explanation for the difference.
> 
> Maybe. What you really want to look at is the GC roots for those
> objects. That will tell you what is holding on to the references. Based
> on that data I'd start looking at the arrays of TagAttributeInfo but
> that might be completely the wrong place to look.
> 
> I've just triggered a heap dump on the ASF Jira instance (running
> 7.0.19) to see what that looks like. I'll report back what I find (once
> the 4GB heap has finished downloading - it may be some time).

The Jira heap dump looks pretty much as I'd expect it to look so
whatever is going wrong is probably related to the application.

In Yourkit, view the class list, order it by retained size. That should
point you in the right direction. Filtering the classes for just those
that start with "org.apache" or "org.apache.jasper" may shed some light
as will looking at what objects are being retained by each class.

>> Would anyone know of any changes between the two versions, possibly
>> linked to those memory entries, that could lead to such behaviour?
> 
> Nothing jumped out at me from the changelog.

Looking again at the list of classes, my guess is something related to
JSPs (due to the presence of javax.servlet.jsp.tagext.TagAttributeInfo
and org.apache.jasper.compiler.Node$TemplateText). Is it possible you
have development mode enabled for 7.0.10 but disabled for 7.0.8?

This is getting to the point where I'd really need access to the heap
dump to provide any more specific information.

Mark



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

Re: Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Mark Thomas]

On 22/07/2011 17:26, Ian Marsh wrote:
> Hi,
> 
> I am in charge of running a Apache-2, Tomcat-7, Ubuntu-10.04 set up
> for which we have to be PCI Compliant. We recently upgraded to
> Apache-2.2.17 and Tomcat-7.0.8 (from Apache-2.0.x and Tomcat 5.0.28)
> in order to comply with the requirements of the PCI Compliance checks
> and ironed out any issues to get us back to a satisfactory running
> state.

Hmm. I think you need some better PCI auditors. If your app was running
on Tomcat 5.0.x and you trust the app (which seems reasonable given it
is doing something that requires PCI compliance) then an upgrade to
7.0.12 should be sufficient if you using the HTTP BIO connector.

Since Tomcat appears to behind httpd then there is a strong chance you
are using AJP (BIO or APR), in which case 7.0.2 should be sufficient.

It appears your current auditors are blindly (and wrongly) assuming any
vulnerability in Tomcat will impact your installation. Expect a demand
to upgrade to 7.0.19 when they get around to reading the Tomcat security
pages again.



> It seems that the character arrays [C, java.lang.String and
> javax.servlet.jsp.tagext.TagAttributeInfo entries are considerably
> higher in Tomcat-7.0.10 than in Tomcat-7.0.8 and I am wondering if
> this could lead to an explanation for the difference.

Maybe. What you really want to look at is the GC roots for those
objects. That will tell you what is holding on to the references. Based
on that data I'd start looking at the arrays of TagAttributeInfo but
that might be completely the wrong place to look.

I've just triggered a heap dump on the ASF Jira instance (running
7.0.19) to see what that looks like. I'll report back what I find (once
the 4GB heap has finished downloading - it may be some time).

> Would anyone know of any changes between the two versions, possibly
> linked to those memory entries, that could lead to such behaviour?

Nothing jumped out at me from the changelog.

> Any help or suggestions is greatly appreciated! I'm sorry for a long
> post, but hopefully its got the information needed to help diagnosis.

To be honest, there isn't enough info hear to diagnose the root cause
but there is enough to demonstrate that there is probably a problem and
maybe where to start looking. That might not seem like much but it is a
heck of a lot better than most of the reports we get here. Thanks for
providing such a useful problem report.

Mark



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

Upgrading from Tomcat 7.0.8 to 7.0.10 and higher causes Old Generation memory problems

[Ian Marsh]

Hi,

I am in charge of running a Apache-2, Tomcat-7, Ubuntu-10.04 set up
for which we have to be PCI Compliant. We recently upgraded to
Apache-2.2.17 and Tomcat-7.0.8 (from Apache-2.0.x and Tomcat 5.0.28)
in order to comply with the requirements of the PCI Compliance checks
and ironed out any issues to get us back to a satisfactory running
state.

We have now received warning, from our PCI Compliance monitor service,
that further updates are required to remain compliant, those being to
use Apache-2.2.19 and Tomcat-7.0.14 (or higher).

When using Tomcat-7.0.8, we experience healthy memory cycling. The Old
Generation slowly increases until garbage collection runs and clears
out the Old Gen memory level, dropping considerably as expected.

So to the upgrading! Upgrading Apache has been successful and without
problem, however upgrading Tomcat has caused memory problems which, as
yet, I cannot find similar reported cases or clear possibilities for
why its happening.

I've searched post archives and web results, looked through the change
log of Tomcat and tried using tools like jmap and the YourKit monitor
to discover some answers, although I am quite inexperienced with these
tools, but unfortunately I'm not progressing so far.

I have tried running with...
- Tomcat-7.0.16 (being the latest available)
- Tomcat-7.0.14 (being the minimum required for PCI Compliance)
- Tomcat-7.0.10 (being the next available release after 7.0.8)

Tomcat-7.0.10 obviously has the fewest number changes from
Tomcat-7.0.8 but, all of these have resulted in seeing a rather sharp
rise in the Old Generation memory usage, reaching 90%+ (of the
available 1.25GB) in under an hour. Requesting forced garbage
collection gives little effect, if not none at all, and eventually the
Old Gen memory becomes full and the site stops functioning.

There have been no changes to the jvm settings, so I doubt they are
the cause, but for your information they are as follows...

-Djava.awt.headless=true
-Xmx1536m
-Xms1536m
-XX:NewSize=256m
-XX:MaxNewSize=256M
-XX:SurvivorRatio=6
-XX:ReservedCodeCacheSize=64m
-XX:MaxPermSize=512m
-XX:PermSize=512m

I have used jmap to look into what objects are being held in memory
for the problematic versions of Tomcat. For Tomcat-7.0.10, the top 20
listed entries are...

 num     #instances         #bytes  class name
--
  1:       8170940      471172552  [C
  2:       8501813      272058016  java.lang.String
  3:       5388341      215533640  javax.servlet.jsp.tagext.TagAttributeInfo
  4:        581051       35164552  [Ljava.lang.Object;
  5:        170658       34508384  
  6:        528746       33839744  javax.servlet.jsp.tagext.TagInfo
  7:        528746       31094960  [Ljavax.servlet.jsp.tagext.TagAttributeInfo;
  8:         75231       25469312  [B
  9:        170658       23223888  
 10:        395025       22121400  org.apache.jasper.compiler.Mark
 11:         11737       21889840  
 12:        281224       20248128  org.apache.jasper.compiler.Node$TemplateText
 13:        229740       19444304  [Ljava.util.HashMap$Entry;
 14:        594062       19009984  java.util.HashMap$Entry
 15:        220856       15973856  
 16:        110747       13909808  [Ljava.lang.String;
 17:         10561       13740840  
 18:        400243       12807776  java.util.Stack
 19:        224826       10791648  java.util.HashMap
 20:         11737       10042552  

When running under Tomcat-7.0.8 after approximately a similar time of
about an hour, the top 20 entries are...

 num     #instances         #bytes  class name
--
  1:        592439       86974504  [C
  2:         47888       73416688  [I
  3:        189957       39457512  
  4:         88307       27806528  [B
  5:         13444       26059552  
  6:        189957       25848632  
  7:        619859       19835488  java.lang.String
  8:        242174       19462792  
  9:         12260       16256800  
 10:         13444       11624240  
 11:        236662        9466480  java.math.BigDecimal
 12:        184843        7393720  javax.servlet.jsp.tagext.TagAttributeInfo
 13:         83238        5795576  [Ljava.lang.Object;
 14:         59168        5611728  [Ljava.util.HashMap$Entry;
 15:        132465        4238880  java.util.HashMap$Entry
 16:          5287        3630456  
 17:         54218        2602464  java.util.HashMap
 18:         26369        2320472  java.lang.reflect.Method
 19:         39714        1588560  java.util.TreeMap$Entry
 20:         14143        1470872  java.lang.Class

It seems that the character arrays [C, java.lang.String and
javax.servlet.jsp.tagext.TagAttributeInfo entries are considerably
higher in Tomcat-7.0.10 than in Tomcat-7.0.8 and I am wondering if
this could lead to an explanation for the difference.

Would anyone know of any changes between the two versions, possibly
linked to those memory entries, that could lead to such behaviour?

A

Re: memory problems / time outs

[Pid]

On 19/04/2010 14:39, Woude, Alexander van der wrote:
> Pid, considering I put the _OPTS in my startup.sh file, can it be they are 
> not used?

It was probably used, but the settings you specified overlap with each
other, so the -Xms in JAVA_ is replaced by the second setting in CATALINA_

> What is the quickest way to find out?

 jmap -heap 


p

> 
> Van: Pid [...@pidster.com]
> Verzonden: maandag 19 april 2010 15:33
> Aan: Woude, Alexander van der
> Onderwerp: Re: memory problems / time outs
> 
> On 19/04/2010 14:05, Woude, Alexander van der wrote:
>> Wel actually when memeory problems appeared I started with the CATALINA_OPTS 
>> to increase memeory.
>>
>> When after a while problems appeared again, I thought to understand that I 
>> had to increase the heap size op the JVM memory.
> 
> That's what you were doing.
> 
>> In the end I wanted more memeory allocated for the tomcat.
>> SO please tell me what is the best one for me, if u can.
> 
> JAVA_OPTS and CATALINA_OPTS are both used when the starting Tomcat,
> JAVA_OPTS is also used when stopping Tomcat.
> 
> Environment variables don't apply separately to the JVM, Tomcat or
> applications, it's all set per JVM.
> 
> All of the settings should be in CATALINA_OPTS in your case.
> 
>> And I am doubting now if it is in the right file, the startup.sh Can u 
>> confirm if that is okay?
> 
> Environment settings can be placed in bin/setenv.sh, create the file if
> it doesn't exist.
> 
> 
> p
> 
> 
>> Greetings Alexander
>>
>> 
>> Van: Pid [...@pidster.com]
>> Verzonden: maandag 19 april 2010 14:50
>> Aan: Tomcat Users List
>> Onderwerp: Re: memory problems / time outs
>>
>> On 19/04/2010 13:24, Woude, Alexander van der wrote:
>>> Thanks for the suggestions this far.
>>> I had an oversight with the tomcat monitoring, didnt notice it on the site.
>>>
>>> I will try that just as the suggestions about JStack etc.
>>>
>>> why 2 Xms settings?
>>> I thought to have understood that catalina en java opts were 2 seperate 
>>> things but I was wrong?
>>
>> They are different.  I'm asking why you have set them, what are you
>> trying to achieve?
>>
>>
>> p
>>
>>> Thanks
>>> Alex
>>> 
>>> Van: Harry Metske [harry.met...@gmail.com]
>>> Verzonden: maandag 19 april 2010 14:16
>>> Aan: Tomcat Users List
>>> Onderwerp: Re: memory problems / time outs
>>>
>>> 2010/4/19 Woude, Alexander van der 
>>>
>>>> Sorry a small correction. The client times out, because the tomcat gives a
>>>> Heap Space memory error.
>>>>
>>>> config in startup.sh :
>>>>
>>>> export JAVA_OPTS="-Xms128m -Xmx512m"
>>>> export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"
>>>>
>>>> My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB
>>>>
>>>> How do I check the memory the tomcat uses?
>>>>
>>>
>>> you can also enable JMX, see
>>> http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling
>>> JMX Remote and use jconsole to monitor real time memory usage.
>>>
>>>
>>>
>>>> Greetings
>>>> Alex
>>>>
>>>>
>>>> 
>>>> Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
>>>> Verzonden: maandag 19 april 2010 13:49
>>>> Aan: users@tomcat.apache.org
>>>> Onderwerp: memory problems / time outs
>>>>
>>>> Hello All
>>>>
>>>> For a client I developed a few Data webservices. In total there are 7
>>>> services.
>>>> All are CXF based webservices that use hibernate.
>>>>
>>>> I keep having memory problems, so I increased both JAVA_OPTS as
>>>> CATALINA_OPTS.
>>>> Now I get timed out errors and tomcat blocks completely, I only can resolve
>>>> things by restarting the tomcat server.
>>>>
>>>> I did profile my services and I did profile my hibernate DAO's and it seems
>>>> fine.
>>>> I have no clue where to look anymore for a solution, any idea is welcome.
>>>>
>>>> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a
>>>> OpenJDK java6 64 

RE: memory problems / time outs

[Woude, Alexander van der]

Wel actually when memeory problems appeared I started with the CATALINA_OPTS to 
increase memeory.
When after a while problems appeared again, I thought to understand that I had 
to increase the heap size op the JVM memory.

In the end I wanted more memeory allocated for the tomcat.
SO please tell me what is the best one for me, if u can.
And I am doubting now if it is in the right file, the startup.sh Can u confirm 
if that is okay?

Greetings Alexander


Van: Pid [...@pidster.com]
Verzonden: maandag 19 april 2010 14:50
Aan: Tomcat Users List
Onderwerp: Re: memory problems / time outs

On 19/04/2010 13:24, Woude, Alexander van der wrote:
> Thanks for the suggestions this far.
> I had an oversight with the tomcat monitoring, didnt notice it on the site.
>
> I will try that just as the suggestions about JStack etc.
>
> why 2 Xms settings?
> I thought to have understood that catalina en java opts were 2 seperate 
> things but I was wrong?

They are different.  I'm asking why you have set them, what are you
trying to achieve?


p

> Thanks
> Alex
> 
> Van: Harry Metske [harry.met...@gmail.com]
> Verzonden: maandag 19 april 2010 14:16
> Aan: Tomcat Users List
> Onderwerp: Re: memory problems / time outs
>
> 2010/4/19 Woude, Alexander van der 
>
>> Sorry a small correction. The client times out, because the tomcat gives a
>> Heap Space memory error.
>>
>> config in startup.sh :
>>
>> export JAVA_OPTS="-Xms128m -Xmx512m"
>> export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"
>>
>> My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB
>>
>> How do I check the memory the tomcat uses?
>>
>
> you can also enable JMX, see
> http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling
> JMX Remote and use jconsole to monitor real time memory usage.
>
>
>
>> Greetings
>> Alex
>>
>>
>> ____
>> Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
>> Verzonden: maandag 19 april 2010 13:49
>> Aan: users@tomcat.apache.org
>> Onderwerp: memory problems / time outs
>>
>> Hello All
>>
>> For a client I developed a few Data webservices. In total there are 7
>> services.
>> All are CXF based webservices that use hibernate.
>>
>> I keep having memory problems, so I increased both JAVA_OPTS as
>> CATALINA_OPTS.
>> Now I get timed out errors and tomcat blocks completely, I only can resolve
>> things by restarting the tomcat server.
>>
>> I did profile my services and I did profile my hibernate DAO's and it seems
>> fine.
>> I have no clue where to look anymore for a solution, any idea is welcome.
>>
>> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a
>> OpenJDK java6 64 JVM.
>>
>> Thanks
>> Alex
>>
>>
>>
>>
>>
>>
>> This message contains information that may be privileged or confidential
>> and is the property of the Capgemini Group. It is
>> intended only for the person to whom it is addressed. If you are not the
>> intended recipient, you are not authorized to
>> read, print, retain, copy, disseminate, distribute, or use this message or
>> any part thereof. If you receive this message
>> in error, please notify the sender immediately and delete all copies of
>> this message.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
>>
>>
>>
>>
>> This message contains information that may be privileged or confidential
>> and is the property of the Capgemini Group. It is
>> intended only for the person to whom it is addressed. If you are not the
>> intended recipient, you are not authorized to
>> read, print, retain, copy, disseminate, distribute, or use this message or
>> any part thereof. If you receive this message
>> in error, please notify the sender immediately and delete all copies of
>> this message.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
>
>
>
>
>
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is
> intended only for the

Re: memory problems / time outs

[Pid]

On 19/04/2010 13:24, Woude, Alexander van der wrote:
> Thanks for the suggestions this far. 
> I had an oversight with the tomcat monitoring, didnt notice it on the site.
> 
> I will try that just as the suggestions about JStack etc.
> 
> why 2 Xms settings?
> I thought to have understood that catalina en java opts were 2 seperate 
> things but I was wrong?

They are different.  I'm asking why you have set them, what are you
trying to achieve?


p

> Thanks
> Alex
> 
> Van: Harry Metske [harry.met...@gmail.com]
> Verzonden: maandag 19 april 2010 14:16
> Aan: Tomcat Users List
> Onderwerp: Re: memory problems / time outs
> 
> 2010/4/19 Woude, Alexander van der 
> 
>> Sorry a small correction. The client times out, because the tomcat gives a
>> Heap Space memory error.
>>
>> config in startup.sh :
>>
>> export JAVA_OPTS="-Xms128m -Xmx512m"
>> export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"
>>
>> My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB
>>
>> How do I check the memory the tomcat uses?
>>
> 
> you can also enable JMX, see
> http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling
> JMX Remote and use jconsole to monitor real time memory usage.
> 
> 
> 
>> Greetings
>> Alex
>>
>>
>> ____
>> Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
>> Verzonden: maandag 19 april 2010 13:49
>> Aan: users@tomcat.apache.org
>> Onderwerp: memory problems / time outs
>>
>> Hello All
>>
>> For a client I developed a few Data webservices. In total there are 7
>> services.
>> All are CXF based webservices that use hibernate.
>>
>> I keep having memory problems, so I increased both JAVA_OPTS as
>> CATALINA_OPTS.
>> Now I get timed out errors and tomcat blocks completely, I only can resolve
>> things by restarting the tomcat server.
>>
>> I did profile my services and I did profile my hibernate DAO's and it seems
>> fine.
>> I have no clue where to look anymore for a solution, any idea is welcome.
>>
>> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a
>> OpenJDK java6 64 JVM.
>>
>> Thanks
>> Alex
>>
>>
>>
>>
>>
>>
>> This message contains information that may be privileged or confidential
>> and is the property of the Capgemini Group. It is
>> intended only for the person to whom it is addressed. If you are not the
>> intended recipient, you are not authorized to
>> read, print, retain, copy, disseminate, distribute, or use this message or
>> any part thereof. If you receive this message
>> in error, please notify the sender immediately and delete all copies of
>> this message.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>>
>>
>>
>>
>>
>> This message contains information that may be privileged or confidential
>> and is the property of the Capgemini Group. It is
>> intended only for the person to whom it is addressed. If you are not the
>> intended recipient, you are not authorized to
>> read, print, retain, copy, disseminate, distribute, or use this message or
>> any part thereof. If you receive this message
>> in error, please notify the sender immediately and delete all copies of
>> this message.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
> 
> 
> 
> 
> 
> 
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is 
> intended only for the person to whom it is addressed. If you are not the 
> intended recipient, you are not authorized to 
> read, print, retain, copy, disseminate, distribute, or use this message or 
> any part thereof. If you receive this message 
> in error, please notify the sender immediately and delete all copies of this 
> message.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 




signature.asc
Description: OpenPGP digital signature

Re: memory problems / time outs

[Harry Metske]

if you specify java options in JAVA_OPTS it is both valid for startup and
shutdown, if you specify java options in CATALINA_OPTS it is only valid for
startup.
So my guess is that CATALINA_OPTS is the right place in your situation.

regards,
Harry

2010/4/19 Woude, Alexander van der 

> Thanks for the suggestions this far.
> I had an oversight with the tomcat monitoring, didnt notice it on the site.
>
> I will try that just as the suggestions about JStack etc.
>
> why 2 Xms settings?
> I thought to have understood that catalina en java opts were 2 seperate
> things but I was wrong?
>
> Thanks
> Alex
> 
> Van: Harry Metske [harry.met...@gmail.com]
> Verzonden: maandag 19 april 2010 14:16
> Aan: Tomcat Users List
> Onderwerp: Re: memory problems / time outs
>
> 2010/4/19 Woude, Alexander van der 
>
> > Sorry a small correction. The client times out, because the tomcat gives
> a
> > Heap Space memory error.
> >
> > config in startup.sh :
> >
> > export JAVA_OPTS="-Xms128m -Xmx512m"
> > export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"
> >
> > My apps are 7 war, that  each contain its own deps. Size of 1 war is 14
> MB
> >
> > How do I check the memory the tomcat uses?
> >
>
> you can also enable JMX, see
> http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling
> JMX Remote and use jconsole to monitor real time memory usage.
>
>
>
> > Greetings
> > Alex
> >
> >
> > ____
> > Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
> > Verzonden: maandag 19 april 2010 13:49
> > Aan: users@tomcat.apache.org
> > Onderwerp: memory problems / time outs
> >
> > Hello All
> >
> > For a client I developed a few Data webservices. In total there are 7
> > services.
> > All are CXF based webservices that use hibernate.
> >
> > I keep having memory problems, so I increased both JAVA_OPTS as
> > CATALINA_OPTS.
> > Now I get timed out errors and tomcat blocks completely, I only can
> resolve
> > things by restarting the tomcat server.
> >
> > I did profile my services and I did profile my hibernate DAO's and it
> seems
> > fine.
> > I have no clue where to look anymore for a solution, any idea is welcome.
> >
> > I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a
> > OpenJDK java6 64 JVM.
> >
> > Thanks
> > Alex
> >
> >
> >
> >
> >
> >
> > This message contains information that may be privileged or confidential
> > and is the property of the Capgemini Group. It is
> > intended only for the person to whom it is addressed. If you are not the
> > intended recipient, you are not authorized to
> > read, print, retain, copy, disseminate, distribute, or use this message
> or
> > any part thereof. If you receive this message
> > in error, please notify the sender immediately and delete all copies of
> > this message.
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> >
> >
> >
> >
> >
> > This message contains information that may be privileged or confidential
> > and is the property of the Capgemini Group. It is
> > intended only for the person to whom it is addressed. If you are not the
> > intended recipient, you are not authorized to
> > read, print, retain, copy, disseminate, distribute, or use this message
> or
> > any part thereof. If you receive this message
> > in error, please notify the sender immediately and delete all copies of
> > this message.
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>
>
>
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or
> any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of
> this message.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: memory problems / time outs

[Woude, Alexander van der]

Thanks for the suggestions this far. 
I had an oversight with the tomcat monitoring, didnt notice it on the site.

I will try that just as the suggestions about JStack etc.

why 2 Xms settings?
I thought to have understood that catalina en java opts were 2 seperate things 
but I was wrong?

Thanks
Alex

Van: Harry Metske [harry.met...@gmail.com]
Verzonden: maandag 19 april 2010 14:16
Aan: Tomcat Users List
Onderwerp: Re: memory problems / time outs

2010/4/19 Woude, Alexander van der 

> Sorry a small correction. The client times out, because the tomcat gives a
> Heap Space memory error.
>
> config in startup.sh :
>
> export JAVA_OPTS="-Xms128m -Xmx512m"
> export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"
>
> My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB
>
> How do I check the memory the tomcat uses?
>

you can also enable JMX, see
http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling
JMX Remote and use jconsole to monitor real time memory usage.



> Greetings
> Alex
>
>
> 
> Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
> Verzonden: maandag 19 april 2010 13:49
> Aan: users@tomcat.apache.org
> Onderwerp: memory problems / time outs
>
> Hello All
>
> For a client I developed a few Data webservices. In total there are 7
> services.
> All are CXF based webservices that use hibernate.
>
> I keep having memory problems, so I increased both JAVA_OPTS as
> CATALINA_OPTS.
> Now I get timed out errors and tomcat blocks completely, I only can resolve
> things by restarting the tomcat server.
>
> I did profile my services and I did profile my hibernate DAO's and it seems
> fine.
> I have no clue where to look anymore for a solution, any idea is welcome.
>
> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a
> OpenJDK java6 64 JVM.
>
> Thanks
> Alex
>
>
>
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or
> any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of
> this message.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or
> any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of
> this message.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>






This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is 
intended only for the person to whom it is addressed. If you are not the 
intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any 
part thereof. If you receive this message 
in error, please notify the sender immediately and delete all copies of this 
message.


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

Re: memory problems / time outs

[Harry Metske]

2010/4/19 Woude, Alexander van der 

> Sorry a small correction. The client times out, because the tomcat gives a
> Heap Space memory error.
>
> config in startup.sh :
>
> export JAVA_OPTS="-Xms128m -Xmx512m"
> export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"
>
> My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB
>
> How do I check the memory the tomcat uses?
>

you can also enable JMX, see
http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html#Enabling
JMX Remote and use jconsole to monitor real time memory usage.



> Greetings
> Alex
>
>
> 
> Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
> Verzonden: maandag 19 april 2010 13:49
> Aan: users@tomcat.apache.org
> Onderwerp: memory problems / time outs
>
> Hello All
>
> For a client I developed a few Data webservices. In total there are 7
> services.
> All are CXF based webservices that use hibernate.
>
> I keep having memory problems, so I increased both JAVA_OPTS as
> CATALINA_OPTS.
> Now I get timed out errors and tomcat blocks completely, I only can resolve
> things by restarting the tomcat server.
>
> I did profile my services and I did profile my hibernate DAO's and it seems
> fine.
> I have no clue where to look anymore for a solution, any idea is welcome.
>
> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a
> OpenJDK java6 64 JVM.
>
> Thanks
> Alex
>
>
>
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or
> any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of
> this message.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
>
>
> This message contains information that may be privileged or confidential
> and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the
> intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or
> any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of
> this message.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: memory problems / time outs

[Pid]

On 19/04/2010 12:54, Woude, Alexander van der wrote:
> Sorry a small correction. The client times out, because the tomcat gives a 
> Heap Space memory error.
> 
> config in startup.sh :
> 
> export JAVA_OPTS="-Xms128m -Xmx512m"
> export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"

You're setting -Xms twice there.  Why?

Why are you setting the memory in two different environment variables?

> My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB
> 
> How do I check the memory the tomcat uses?

 jmap -heap 

You could post the result of that here.


p


> Greetings
> Alex
> 
> 
> 
> Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
> Verzonden: maandag 19 april 2010 13:49
> Aan: users@tomcat.apache.org
> Onderwerp: memory problems / time outs
> 
> Hello All
> 
> For a client I developed a few Data webservices. In total there are 7 
> services.
> All are CXF based webservices that use hibernate.
> 
> I keep having memory problems, so I increased both JAVA_OPTS as CATALINA_OPTS.
> Now I get timed out errors and tomcat blocks completely, I only can resolve 
> things by restarting the tomcat server.
> 
> I did profile my services and I did profile my hibernate DAO's and it seems 
> fine.
> I have no clue where to look anymore for a solution, any idea is welcome.
> 
> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a 
> OpenJDK java6 64 JVM.
> 
> Thanks
> Alex
> 
> 
> 
> 
> 
> 
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are not the 
> intended recipient, you are not authorized to
> read, print, retain, copy, disseminate, distribute, or use this message or 
> any part thereof. If you receive this message
> in error, please notify the sender immediately and delete all copies of this 
> message.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
> 
> 
> 
> 
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is 
> intended only for the person to whom it is addressed. If you are not the 
> intended recipient, you are not authorized to 
> read, print, retain, copy, disseminate, distribute, or use this message or 
> any part thereof. If you receive this message 
> in error, please notify the sender immediately and delete all copies of this 
> message.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 




signature.asc
Description: OpenPGP digital signature

Re: memory problems / time outs

[Pid]

On 19/04/2010 12:49, Woude, Alexander van der wrote:
> Hello All
> 
> For a client I developed a few Data webservices. In total there are 7 
> services.
> All are CXF based webservices that use hibernate.
> 
> I keep having memory problems, so I increased both JAVA_OPTS as CATALINA_OPTS.
> Now I get timed out errors and tomcat blocks completely, I only can resolve 
> things by restarting the tomcat server.
> 
> I did profile my services and I did profile my hibernate DAO's and it seems 
> fine.
> I have no clue where to look anymore for a solution, any idea is welcome.

Take a series of thread dumps after the server starts to manifest
problems.  Look for differences between each dump and see if you can
work out what's wrong.  E.g. Lots of threads which are "blocked".

I think the jstack tool is available in OpenJDK.


p

> I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a 
> OpenJDK java6 64 JVM.
> 
> Thanks 
> Alex
> 
> 
> 
> 
> 
> 
> This message contains information that may be privileged or confidential and 
> is the property of the Capgemini Group. It is 
> intended only for the person to whom it is addressed. If you are not the 
> intended recipient, you are not authorized to 
> read, print, retain, copy, disseminate, distribute, or use this message or 
> any part thereof. If you receive this message 
> in error, please notify the sender immediately and delete all copies of this 
> message.
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 




signature.asc
Description: OpenPGP digital signature

RE: memory problems / time outs

[Woude, Alexander van der]

Sorry a small correction. The client times out, because the tomcat gives a Heap 
Space memory error.

config in startup.sh :

export JAVA_OPTS="-Xms128m -Xmx512m"
export CATALINA_OPTS="-Xms512m -XX:MaxPermSize=512m"

My apps are 7 war, that  each contain its own deps. Size of 1 war is 14 MB

How do I check the memory the tomcat uses?

Greetings
Alex



Van: Woude, Alexander van der [alexander.vander.wo...@capgemini.com]
Verzonden: maandag 19 april 2010 13:49
Aan: users@tomcat.apache.org
Onderwerp: memory problems / time outs

Hello All

For a client I developed a few Data webservices. In total there are 7 services.
All are CXF based webservices that use hibernate.

I keep having memory problems, so I increased both JAVA_OPTS as CATALINA_OPTS.
Now I get timed out errors and tomcat blocks completely, I only can resolve 
things by restarting the tomcat server.

I did profile my services and I did profile my hibernate DAO's and it seems 
fine.
I have no clue where to look anymore for a solution, any idea is welcome.

I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a 
OpenJDK java6 64 JVM.

Thanks
Alex






This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is
intended only for the person to whom it is addressed. If you are not the 
intended recipient, you are not authorized to
read, print, retain, copy, disseminate, distribute, or use this message or any 
part thereof. If you receive this message
in error, please notify the sender immediately and delete all copies of this 
message.


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







This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is 
intended only for the person to whom it is addressed. If you are not the 
intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any 
part thereof. If you receive this message 
in error, please notify the sender immediately and delete all copies of this 
message.


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

memory problems / time outs

[Woude, Alexander van der]

Hello All

For a client I developed a few Data webservices. In total there are 7 services.
All are CXF based webservices that use hibernate.

I keep having memory problems, so I increased both JAVA_OPTS as CATALINA_OPTS.
Now I get timed out errors and tomcat blocks completely, I only can resolve 
things by restarting the tomcat server.

I did profile my services and I did profile my hibernate DAO's and it seems 
fine.
I have no clue where to look anymore for a solution, any idea is welcome.

I use tomcat-6.0.18 on RedHat enterprise linux 5 , 64 bit version. With a 
OpenJDK java6 64 JVM.

Thanks 
Alex






This message contains information that may be privileged or confidential and is 
the property of the Capgemini Group. It is 
intended only for the person to whom it is addressed. If you are not the 
intended recipient, you are not authorized to 
read, print, retain, copy, disseminate, distribute, or use this message or any 
part thereof. If you receive this message 
in error, please notify the sender immediately and delete all copies of this 
message.


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

Re: Max Thread/Memory problems with tomcat

[Peter Crowther]

2009/10/5 prashant sharma :
> Tomcat: 5.0.

That's old, and no longer supported.  Why are you using this version?
(And exactly which version of 5.0 are you using, by the way?)

> OS: Windows Server HPC edition.

32- or 64-bit?  I ask because the maximum contiguous memory you'll get
in 32-bit is somewhere around 1400 Mbytes - the numbers vary depending
on exactly which Microsoft OS.

> JVM: 5.0

That's also old.  Why are you using this version?

> There is one basic doubt that I have. When we load/stress our Tomcat server, 
> we hit thresholds mentioned below once in a while. The root of the problem is 
> that when I increase the clients, I start getting a connection refused error 
> on the server side. This is because the server hits the maximum request 
> processing thread limit. The other problems are connected to it:
>
> -Max threads (tomcat):
>
> As mentioned above, this is the root of the problem. To solve this problem, I 
> increase the max threads in server.xml. Then I get the Out of stack space 
> exception.
>
> -Stack Memory:
>
> Now for this I tried a couple of things
> a) Reduce the stack size allotted per thread so that more threads can be 
> spawned in the allotted stack space.I believe that the default is around 
> 320K/ thread. I set it to 128K in the JVM options (Xss).
> b) Reduce the heap size. I did this because as per my understanding the 
> memory alloted to a process is divided among heap and stack. So probably 
> reducing the heap size makes more memory available for stack. Don't know if 
> this is correct?

It certainly makes more memory available for the OS stack.

> Now once in a while I get Out of memory exception for heap space.
>
> -Heap Memory:
>
> Can somebody advise as to what are the solutions for these sort of problems 
> other than reducing the memory/thread consumption, of our application logic. 
> I mean are there techniques that can be applied on tomcat/JVM/OS level to 
> make more threads/memory available to the tomcat process?

OS: Use a 64-bit OS.  Add RAM to the server.  Use anything other than
32-bit Windows in order to get a larger contiguous heap space.  If you
absolutely have to use Windows, and it absolutely has to be the 32-bit
version, use the /3GB switch *with extreme care* - read up on
*exactly* what it does and what will break before enabling it.

JVM: You've done the main thing, which is to reduce the stack depth per thread.

Tomcat: Memory and CPU usage is generally better in newer versions.
Other tunings are very much application-specific, I suspect.

However, I think we all know what the underlying problem is: your
application will not reliably fit in the available space with the load
you're putting on it during the test.  Add more space, load-balance
onto multiple machines of the size you have, tune the app, or reduce
the scale of your load test if it's deliberately a long way above your
target load.

- Peter

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

Max Thread/Memory problems with tomcat

[prashant sharma]

Hi,

We are using the following configuration:

Tomcat: 5.0. 
OS: Windows Server HPC edition.  
JVM: 5.0

There is one basic doubt that I have. When we load/stress our Tomcat server, we 
hit thresholds mentioned below once in a while. The root of the problem is that 
when I increase the clients, I start getting a connection refused error on the 
server side. This is because the server hits the maximum request processing 
thread limit. The other problems are connected to it:

-Max threads (tomcat): 

As mentioned above, this is the root of the problem. To solve this problem, I 
increase the max threads in server.xml. Then I get the Out of stack space 
exception. 

-Stack Memory:
 
Now for this I tried a couple of things
a) Reduce the stack size allotted per thread so that more threads can be 
spawned in the allotted stack space.I believe that the default is around 320K/ 
thread. I set it to 128K in the JVM options (Xss). 
b) Reduce the heap size. I did this because as per my understanding the memory 
alloted to a process is divided among heap and stack. So probably reducing the 
heap size makes more memory available for stack. Don't know if this is correct?

Now once in a while I get Out of memory exception for heap space.

-Heap Memory: 

Can somebody advise as to what are the solutions for these sort of problems 
other than reducing the memory/thread consumption, of our application logic. I 
mean are there techniques that can be applied on tomcat/JVM/OS level to make 
more threads/memory available to the tomcat process? 

Please advise.

Thanks!
Prashant


  

RES: Re: Memory problems

[Milanez, Marcus]

Have you considered using Lambda Probe for tracking tomcat memory use details?  
Give it a try, maybe you'll be able to find alive object references that could 
be garbage collected.

http://www.lambdaprobe.org/


-Mensagem original-
De: news [mailto:[EMAIL PROTECTED] Em nome de Morten
Enviada em: terça-feira, 21 de agosto de 2007 09:11
Para: users@tomcat.apache.org
Assunto: Re: Memory problems

>> Are there any way to stop Tomcat from cached these large byte[] 
>> internally?
>> The ByteChunks are referenced from IntermediateOutputstream, 
>> C2BConverter and OutputBuffer.

>Hmm.  Those are all Tomcat util classes, so they're almost certainly 
>held by something else.  Can you find out what's holding on to those 
>instances, and make sure the chain of references goes entirely through 
>Tomcat rather than via JBoss, your webapp or something you've cached in 
>your session?
>
The graph looks like this:

The byte[] is referenced from:
- ByteChunk (A)
- ByteChunk (B)

ByteChunk (A) is referenced by:
- org.apache.tomcat.util.buf.C2BConverter (AA)
- org.apache.tomcat.util.buf.IntermediateOutputStream (AB)
- org.apache.catalina.connector.OutputBuffer (AC)

ByteChunk (B) is referenced by:
- org.apache.catalina.connector.OutputBuffer (AC)

C2BConverter (AA) is referenced by:
- HashMap$Entry (AAA)
- org.apache.catalina.connector.OutputBuffer (AC)

IntermediateOutputStream (AB) is referenced by:
- org.apache.tomcat.util.buf.C2BConverter (AA)
- org.apache.tomcat.util.buf.WriteConvertor (ABA)
- sun.nio.cs.StreamEnocder (ABB)

OutputBuffer (AC) is referenced by:
- org.apache.catalina.conncetor.CoyoteOutputStream (ACA)
- org.apache.catalina.connector.CoyoteWriter (ACB)
- org.apache.catalina.connector.Response (ACC)

HashMap$Entry (AAA) is referenced by:
- []

org.apache.catalina.conncetor.CoyoteOutputStream (ACA) is referenced by:
- org.apache.catalina.connector.Response (ACC)

org.apache.catalina.connector.CoyoteWriter (ACB) is referenced by:
- org.apache.catalina.connector.Response (ACC)

org.apache.catalina.connector.Response (ACC) is referenced by:
- org.apache.catalina.connector.ResponseFacade (ACCA)
- [] (ACCB)
- org.apache.catalina.connector.Request (ACCC)

I cannot find any trace of any JBoss or any webapp class.

Best regards,
Morten





-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: 
[EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory problems

[Morten]

>> Are there any way to stop Tomcat from cached these large
>> byte[] internally?
>> The ByteChunks are referenced from IntermediateOutputstream,
>> C2BConverter and OutputBuffer.

>Hmm.  Those are all Tomcat util classes, so they're almost certainly
>held by something else.  Can you find out what's holding on to those
>instances, and make sure the chain of references goes entirely through
>Tomcat rather than via JBoss, your webapp or something you've cached in
>your session?
>
The graph looks like this:

The byte[] is referenced from:
- ByteChunk (A)
- ByteChunk (B)

ByteChunk (A) is referenced by:
- org.apache.tomcat.util.buf.C2BConverter (AA)
- org.apache.tomcat.util.buf.IntermediateOutputStream (AB)
- org.apache.catalina.connector.OutputBuffer (AC)

ByteChunk (B) is referenced by:
- org.apache.catalina.connector.OutputBuffer (AC)

C2BConverter (AA) is referenced by:
- HashMap$Entry (AAA)
- org.apache.catalina.connector.OutputBuffer (AC)

IntermediateOutputStream (AB) is referenced by:
- org.apache.tomcat.util.buf.C2BConverter (AA)
- org.apache.tomcat.util.buf.WriteConvertor (ABA)
- sun.nio.cs.StreamEnocder (ABB)

OutputBuffer (AC) is referenced by:
- org.apache.catalina.conncetor.CoyoteOutputStream (ACA)
- org.apache.catalina.connector.CoyoteWriter (ACB)
- org.apache.catalina.connector.Response (ACC)

HashMap$Entry (AAA) is referenced by:
- []

org.apache.catalina.conncetor.CoyoteOutputStream (ACA) is referenced by:
- org.apache.catalina.connector.Response (ACC)

org.apache.catalina.connector.CoyoteWriter (ACB) is referenced by:
- org.apache.catalina.connector.Response (ACC)

org.apache.catalina.connector.Response (ACC) is referenced by:
- org.apache.catalina.connector.ResponseFacade (ACCA)
- [] (ACCB)
- org.apache.catalina.connector.Request (ACCC)

I cannot find any trace of any JBoss or any webapp class.

Best regards,
Morten





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Memory problems

[Peter Crowther]

> From: Morten
> According to a heap dump done by jmap, there are many 
> org.apache.tomcat.util.buf.ByteChunk instances referencing 
> large byte[], 
> which we suspect to be previously used pictures.
> 
> We have tried both Tomcat 5.5.9 and Tomcat 6 under JBoss 
> 4.2.0. Both showed 
> the same behaviour.
> 
> Are there any way to stop Tomcat from cached these large 
> byte[] internally?
> The ByteChunks are referenced from IntermediateOutputstream, 
> C2BConverter and OutputBuffer.

Hmm.  Those are all Tomcat util classes, so they're almost certainly
held by something else.  Can you find out what's holding on to those
instances, and make sure the chain of references goes entirely through
Tomcat rather than via JBoss, your webapp or something you've cached in
your session?

- Peter

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Memory problems

[Morten]

Hi

We have implemented a picture server in Tomcat.
The pictures are cached in a map. When the memory is nearly full, some 
entries are removed from map.

However, eventually the entries in the map become fewer and fewer even 
though the memory consumption stays high. In other words more and more 
memory are used outside the map.

According to a heap dump done by jmap, there are many 
org.apache.tomcat.util.buf.ByteChunk instances referencing large byte[], 
which we suspect to be previously used pictures.

We have tried both Tomcat 5.5.9 and Tomcat 6 under JBoss 4.2.0. Both showed 
the same behaviour.

Are there any way to stop Tomcat from cached these large byte[] internally?
The ByteChunks are referenced from IntermediateOutputstream, C2BConverter 
and OutputBuffer.

Best regards,
Morten Knudsen




-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat 5.5.9 memory problems

[mrkmrk]

Hi

We're using Tomcat 5.5.9 embedded in JBoss 4.0.2 as a server supplying pdf 
files.

The Servlet contains a map of entries 
Entries are removed if a memory threshold is exceeded.

The problem is that the map contains fewer and fewer entries as time goes 
by.
It seems that Tomcat caches previously used byte[] in objects of the type 
org.apache.util.buf.ByteChunk. These objects are again contained in 
OutputBuffers and IntermediateOutputStreams. These objects take more and 
more space thus leaving less room for the entries in the map.

How do I get Tomcat to remove these objects from its internal cache?

Best regards,
Morten Knudsen




-- 
View this message in context: 
http://www.nabble.com/Tomcat-5.5.9-memory-problems-tf3992793.html#a11338090
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

memory problems

[Daniel L. Gross]

I have some servlets that run without problem on tomcat 4, but when I 
upgraded to Tomcat 5.5.15, everytime a servlet is accessed, it uses a 
little more memory, and finally after many users, runs out of heap 
space.  Any clues?


Thanks Dan Gross


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]