You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Adam Lipscombe <ad...@gmail.com> on 2011/02/03 10:57:59 UTC

Monitoring production tomcat

Folks


We have a several production servers, each of which runs 1 instance of
tomcat. Within each instance of tomcat there are approximately 10
virtual websites. Each virtual website runs a copy of our web app.
Therefore each server hosts @ 10 instances of our web app

On a couple of the servers we are having problems with tomcat running
out of memory and sometimes dropping the JDBC link to the MYSQL database 
etc.
We usually restart tomcat, which of course cures the issues. However 
doing do affects every virtual site and therefore is not ideal from our 
customer's perspective.

We have been looking at this problem for some time, however it is very 
difficult to determine what is causing these problems. Very likely 
something in out webapp.


What would help is some kind of management or monitoring facility
that allows us to see which virtual site is getting into trouble.
Ideally it should give enough information to help us track down what is
causing the issue. Memory usage per site, thread view etc.


Can anyone recommend anything that can do this? Commercial or free?


Many thanks - Adam



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


RE: Monitoring production tomcat

Posted by Martin Gainty <mg...@hotmail.com>.
you may want to consider a MySQL best respponse connection algorithm such as 
MySQL LoadBalancingConnectionProxy.java (allocates multiple connections and selects which connection to use based on least response time)

or allocate a number of connections upfront with DBCP
http://commons.apache.org/dbcp/

ping offline for details,
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.




> Date: Thu, 3 Feb 2011 11:40:08 +0100
> Subject: Re: Monitoring production tomcat
> From: rosenberg.leon@gmail.com
> To: users@tomcat.apache.org
> 
> There is clearly only one solution ;-)
> http://moskito.anotheria.net
> 
> Ok, advertisement aside, there are multiple, but moskito provides most
> information of all the available tools.
> 
> Feel free to ask offlist too.
> 
> regards
> Leon
> 
> On Thu, Feb 3, 2011 at 10:57 AM, Adam Lipscombe
> <ad...@gmail.com> wrote:
> >
> > Folks
> >
> >
> > We have a several production servers, each of which runs 1 instance of
> > tomcat. Within each instance of tomcat there are approximately 10
> > virtual websites. Each virtual website runs a copy of our web app.
> > Therefore each server hosts @ 10 instances of our web app
> >
> > On a couple of the servers we are having problems with tomcat running
> > out of memory and sometimes dropping the JDBC link to the MYSQL database
> > etc.
> > We usually restart tomcat, which of course cures the issues. However doing
> > do affects every virtual site and therefore is not ideal from our customer's
> > perspective.
> >
> > We have been looking at this problem for some time, however it is very
> > difficult to determine what is causing these problems. Very likely something
> > in out webapp.
> >
> >
> > What would help is some kind of management or monitoring facility
> > that allows us to see which virtual site is getting into trouble.
> > Ideally it should give enough information to help us track down what is
> > causing the issue. Memory usage per site, thread view etc.
> >
> >
> > Can anyone recommend anything that can do this? Commercial or free?
> >
> >
> > Many thanks - Adam
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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: Monitoring production tomcat

Posted by Leon Rosenberg <ro...@gmail.com>.
There is clearly only one solution ;-)
http://moskito.anotheria.net

Ok, advertisement aside, there are multiple, but moskito provides most
information of all the available tools.

Feel free to ask offlist too.

regards
Leon

On Thu, Feb 3, 2011 at 10:57 AM, Adam Lipscombe
<ad...@gmail.com> wrote:
>
> Folks
>
>
> We have a several production servers, each of which runs 1 instance of
> tomcat. Within each instance of tomcat there are approximately 10
> virtual websites. Each virtual website runs a copy of our web app.
> Therefore each server hosts @ 10 instances of our web app
>
> On a couple of the servers we are having problems with tomcat running
> out of memory and sometimes dropping the JDBC link to the MYSQL database
> etc.
> We usually restart tomcat, which of course cures the issues. However doing
> do affects every virtual site and therefore is not ideal from our customer's
> perspective.
>
> We have been looking at this problem for some time, however it is very
> difficult to determine what is causing these problems. Very likely something
> in out webapp.
>
>
> What would help is some kind of management or monitoring facility
> that allows us to see which virtual site is getting into trouble.
> Ideally it should give enough information to help us track down what is
> causing the issue. Memory usage per site, thread view etc.
>
>
> Can anyone recommend anything that can do this? Commercial or free?
>
>
> Many thanks - Adam
>
>
>
> ---------------------------------------------------------------------
> 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: Monitoring production tomcat

Posted by M....@DNB.NL.
Hello

Maybe Tcat from mulesoft is something to look into

regards

Milko


                                                                           
             Adam Lipscombe                                                
             <adam.lipscombe@g                                             
             mail.com>                                                  To 
                                       users@tomcat.apache.org             
             03-02-2011 10:57                                           cc 
                                                                           
                                                                   Subject 
             Please respond to         Monitoring production tomcat        
               "Tomcat Users                                               
                   List"                                                   
             <users@tomcat.apa                                             
                 che.org>                                                  
                                                                           
                                                                           





Folks


We have a several production servers, each of which runs 1 instance of
tomcat. Within each instance of tomcat there are approximately 10
virtual websites. Each virtual website runs a copy of our web app.
Therefore each server hosts @ 10 instances of our web app

On a couple of the servers we are having problems with tomcat running
out of memory and sometimes dropping the JDBC link to the MYSQL database
etc.
We usually restart tomcat, which of course cures the issues. However
doing do affects every virtual site and therefore is not ideal from our
customer's perspective.

We have been looking at this problem for some time, however it is very
difficult to determine what is causing these problems. Very likely
something in out webapp.


What would help is some kind of management or monitoring facility
that allows us to see which virtual site is getting into trouble.
Ideally it should give enough information to help us track down what is
causing the issue. Memory usage per site, thread view etc.


Can anyone recommend anything that can do this? Commercial or free?


Many thanks - Adam



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




Please consider the environment before printing this email.

De informatie verzonden met dit e-mailbericht is vertrouwelijk en
uitsluitend bestemd voor de geadresseerde. Indien u als niet-geadresseerde
dit bericht ontvangt, wordt u verzocht direct de afzender hierover te
informeren en het bericht te vernietigen. Gebruik van informatie door
onbevoegden, openbaarmaking of vermenigvuldiging  is verboden en kan leiden
tot aansprakelijkheid. De afzender is niet aansprakelijk in geval van
onjuiste overbrenging van het e-mailbericht en/of bij ontijdige ontvangst
daarvan.

The information transmitted is confidential and intended only for the
person or entity to whom or which it is addressed. If you are not the
intended recipient of this communication, please inform us immediately and
destroy this communication. Unauthorised use, disclosure or copying of
information is strictly prohibited and may entail liability. The sender
accepts no liability for improper transmission of this communication nor
for any delay in its receipt.

Re: Monitoring production tomcat

Posted by Mark Thomas <ma...@apache.org>.
On 03/02/2011 09:57, Adam Lipscombe wrote:
> What would help is some kind of management or monitoring facility
> that allows us to see which virtual site is getting into trouble.
> Ideally it should give enough information to help us track down what is
> causing the issue. Memory usage per site, thread view etc.

Per site memory usage is going to be tricky. If most of the memory is in
user sessions you'll probably be able to monitor it.

-XX:+HeapDumpOnOutOfMemoryError may be worth looking at.

Mark

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


Re: Monitoring production tomcat

Posted by Brett Delle Grazie <br...@gmail.com>.
Hi,

See interleaved.

On 3 February 2011 09:57, Adam Lipscombe <ad...@gmail.com> wrote:
>
> Folks
>
>
> We have a several production servers, each of which runs 1 instance of
> tomcat. Within each instance of tomcat there are approximately 10
> virtual websites. Each virtual website runs a copy of our web app.
> Therefore each server hosts @ 10 instances of our web app
>
> On a couple of the servers we are having problems with tomcat running
> out of memory and sometimes dropping the JDBC link to the MYSQL database
> etc.
> We usually restart tomcat, which of course cures the issues. However doing
> do affects every virtual site and therefore is not ideal from our customer's
> perspective.
>
> We have been looking at this problem for some time, however it is very
> difficult to determine what is causing these problems. Very likely something
> in out webapp.
>
>
> What would help is some kind of management or monitoring facility
> that allows us to see which virtual site is getting into trouble.
> Ideally it should give enough information to help us track down what is
> causing the issue. Memory usage per site, thread view etc.
>
>
> Can anyone recommend anything that can do this? Commercial or free?

You're going to need to do some research as not all of the suggestions
below will be suitable for your
specific setup.

The ones I know about are:
Standard JVM monitoring (SNMP/JMX):
http://download.oracle.com/javase/6/docs/technotes/guides/management/

Standard JMX Tomcat monitoring:
http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html (uses above)

Ones that integrate with the Application or Tomcat (open-source):
http://code.google.com/p/javamelody/
http://code.google.com/p/psi-probe/ (replaces lambda probe which is
integrated into tcat server from mulesoft)
http://www.tomcatmonitor.com/
http://jamonapi.sourceforge.net/

Commercial:
http://www.mulesoft.com/tcat-server-enterprise-tomcat-application-server-0
http://www.hyperic.com/products/tomcat-monitoring
http://www.springsource.com/products/tcserver/performance-monitoring-diagnostics
(tcserver)

That's all I've got right now.


>
> Many thanks - Adam
>

-- 
Best Regards,

Brett Delle Grazie

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


Re: Monitoring production tomcat

Posted by André Warnier <aw...@ice-sa.com>.
Jeffrey Janner wrote:
> Adam -
> If you have the physical memory for it, you might want to look into breaking your sites into multiple Tomcat instances (see RUNNING.TXT in the install directory).  At a minimum, you won't have to restart all sites just because one becomes a memory hog.  Plus it would help narrow the list of suspect sites when it does happen.
> Jeff
> 

But you would have to give each one of them a distinct IP address and/or port.
With a front-end proxy, that's not usually a problem, but otherwise the customer may 
object (if it is the ports which you change).


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


RE: Monitoring production tomcat

Posted by Jeffrey Janner <Je...@PolyDyne.com>.
Adam -
If you have the physical memory for it, you might want to look into breaking your sites into multiple Tomcat instances (see RUNNING.TXT in the install directory).  At a minimum, you won't have to restart all sites just because one becomes a memory hog.  Plus it would help narrow the list of suspect sites when it does happen.
Jeff

> -----Original Message-----
> From: Adam Lipscombe [mailto:adam.lipscombe@gmail.com]
> Sent: Thursday, February 03, 2011 3:58 AM
> To: users@tomcat.apache.org
> Subject: Monitoring production tomcat
> 
> 
> Folks
> 
> 
> We have a several production servers, each of which runs 1 instance of
> tomcat. Within each instance of tomcat there are approximately 10
> virtual websites. Each virtual website runs a copy of our web app.
> Therefore each server hosts @ 10 instances of our web app
> 
> On a couple of the servers we are having problems with tomcat running
> out of memory and sometimes dropping the JDBC link to the MYSQL
> database
> etc.
> We usually restart tomcat, which of course cures the issues. However
> doing do affects every virtual site and therefore is not ideal from our
> customer's perspective.
> 
> We have been looking at this problem for some time, however it is very
> difficult to determine what is causing these problems. Very likely
> something in out webapp.
> 
> 
> What would help is some kind of management or monitoring facility
> that allows us to see which virtual site is getting into trouble.
> Ideally it should give enough information to help us track down what is
> causing the issue. Memory usage per site, thread view etc.
> 
> 
> Can anyone recommend anything that can do this? Commercial or free?
> 
> 
> Many thanks - Adam
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
> 

__________________________________________________________________________

Confidentiality Notice:  This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law.  If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited.  

If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.


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


Re: Monitoring production tomcat

Posted by Mikolaj Rydzewski <mi...@ceti.pl>.
 On Thu, 03 Feb 2011 09:57:59 +0000, Adam Lipscombe 
 <ad...@gmail.com> wrote:

> What would help is some kind of management or monitoring facility
> that allows us to see which virtual site is getting into trouble.
> Ideally it should give enough information to help us track down what 
> is
> causing the issue. Memory usage per site, thread view etc.

 Is it your webapp or a third party one?
 Take a time and read about JMX - it's a standard way of monitoring Java 
 applications.
 For a quick start check http://www.lambdaprobe.org/ and jconsole.

-- 
 Mikolaj Rydzewski <mi...@ceti.pl>

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