tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "j r" <jreynold...@gmail.com>
Subject Re: Performance tuning parameters
Date Fri, 16 Feb 2007 14:49:49 GMT
I am gleaning from your comments that MaxThreads is the only thing to
tweak.  Yes I do really have a connection issue.  I have millions and
millions of connection requests on a very small pool of servers.  The app
has been tuned constantly over years.  I am either bound to buy more servers
or tweak tomcat to get more throughput.  In reality, I probably need to do
both.

On a large pageview day, we will overflow the 750 MaxThreads.  This is
noticed by the MaxThreads limit being exceeded error message.  We have
tweaked all pieces of the tomcat config.  I was hoping a post here could get
more explanation of the parameters.  We have our experience to fall back on,
but I was hoping for more.

If MaxThreads is the main thing to tweak, we will continue doing so.  There
is a limit to this though.  You should create the funnel for customer
requests (webserver limits, mod_jk limits, and tomcat limits).  Exploding
MaxThreads to a large number just to be large does not seem to fit with
having an acceptCount value or the funnel that should be created.


Thanks,
J

On 2/16/07, Andrew Miehs <andrew@2sheds.de> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear J,
>
> The focus should be on your application, and configuring everything
> thing around that.
>
> If you REALLY have an out of  connection problem, increase Max
> Threads to 10000, but I don't
> think that will really help you. The problem is usually that each
> individual request takes
> tooo long, which again, points back to your application - There isn't
> that much to tweak
> in tomcat. Once you have configured your application, then you can
> start looking at the
> kernel - but these only bring small % improvements.
>
> Without more information - ie: current number of threads being used,
> it is very
> hard to answer your question.
>
> Cheers
>
> Andrew
>
> On 16/02/2007, at 4:43 AM, j r wrote:
>
> > The focus should be on the tomcat tweaking.  We get errors in the
> > tomcat
> > error logs that say tomcat has reached its connection limits.  I
> > never said
> > that it was serving slow.  It hits connection limits which means
> > that the
> > app will not serve any more traffic until connections clear.
> >
> > If a box definitely has more capacity (dual core, dual procs), then
> > my best
> > guess is that tomcat is not tuned perfectly to allow the max amount of
> > connections in.  We have raised MaxThreads in the past to allow more
> > connections in.  This works, but surely other knobs are important
> > to be
> > tweaked.
> >
> > I am looking for good definitions and/or best practices on which
> > knobs to
> > tweak to allow the max connections in before exhausting the jvm native
> > memory allocation or cpu on the box.
> >
> >
> >
> > Thanks,
> > J
> >
> > On 2/15/07, Andrew Miehs <andrew@2sheds.de> wrote:
> >>
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Dear J'
> >>
> >> What do you mean you are hitting connection limits?! Are you getting
> >> errors? What are you seeing that makes you think that is slow?
> >> Is there a database involved in this application?
> >>
> >> I assume you are running linux on your server, with a 2.6 kernel.
> >>
> >> run the following commands while your box
> >>
> >> 1)  ps auxH
> >> 2)  ps auxH |grep -c java
> >> 3)  vmstat 5 5
> >> 4)  iostat 5 3
> >>
> >> Then we will have a bit of an idea what is going on.
> >>
> >> Andrew
> >>
> >>
> >>
> >>
> >> On 15/02/2007, at 9:36 PM, j r wrote:
> >>
> >> > The reason it is hitting its limits is easy: traffic.  We easily
> >> > get enough
> >> > website traffic to overflow the connection limits unless I have
> >> > many boxes
> >> > available to serve.  I know these can be configured to handle more
> >> > connections.  I know that we should be able to do this in the
> >> tomcat
> >> > server.  That is why I need those tweaking parameters defined.
> >> >
> >> >
> >> >
> >> > Thanks,
> >> > j
> >> >
> >> > On 2/15/07, Leon Rosenberg <rosenberg.leon@googlemail.com> wrote:
> >> >>
> >> >> First you should investigate why tomcat is hitting its limits.
> >> >> Why do you think it does? Which resource is the limit?
> >> >> Do you have/use any monitoring software? moskito? lambdaprobe?
> >> >> tomcat-manager?
> >> >>
> >> >> regards
> >> >> Leon
> >> >>
> >> >> On 2/15/07, j r <jreynolds11@gmail.com> wrote:
> >> >> > I have searched for exact documentation on this, and I always
> >> find
> >> >> > conflicting info.  Therefore I am reaching out to this list. 
I
> >> >> have the
> >> >> > following info and questions:
> >> >> >
> >> >> > - we are running tomcat 5.5.20
> >> >> > - we have the following configs in server.xml:
> >> >> >            <Connector port="8009"
> >> >> >                enableLookups="false" redirectPort="8443"
> >> debug="0"
> >> >> >                maxThreads="750" minSpareThreads="100"
> >> >> maxSpareThreads="250"
> >> >> >                acceptCount="100" connectionTimeout="5000"
> >> >> > tomcatAuthentication="
> >> >> >                false"
> >> >> >
> >> >> > - we have extra capacity (mem, cpu, etc.) on the servers, yet
> >> >> tomcat is
> >> >> > hitting connection limits
> >> >> > - we feel that tomcat can serve more, so what do we tune to make
> >> >> it do
> >> >> so?
> >> >> >     - maxThreads?
> >> >> >     - minSpareThreads?
> >> >> >     - maxSpareThreads?
> >> >> >     - acceptCount?
> >> >> >
> >> >> >
> >> >> > Honestly, I would rather love an exact definition of what each
> >> >> of those
> >> >> > would do to the tomcat server if tweaked.  Knowing that would
be
> >> >> nirvana
> >> >> for
> >> >> > tuning.
> >> >> >
> >> >> >
> >> >> >
> >> >> > -j
> >> >> >
> >> >>
> >> >>
> >> ---------------------------------------------------------------------
> >> >> To start a new topic, e-mail: users@tomcat.apache.org
> >> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >> >>
> >> >>
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.1 (Darwin)
> >>
> >> iD8DBQFF1NaFW126qUNSzvURAuxZAJ4ugkLObXKHJZsSIfX3SWzZzv5vlQCdHXeV
> >> jSPVOQqZXoxvlQc7Q94vMlA=
> >> =YSSz
> >> -----END PGP SIGNATURE-----
> >>
> >> ---------------------------------------------------------------------
> >> To start a new topic, e-mail: users@tomcat.apache.org
> >> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@tomcat.apache.org
> >>
> >>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFF1XNhW126qUNSzvURAtjIAJsHhDX6gXQFPi9UFnFgCPHqB0yGCgCeM7mg
> e41/HBE3bGRaol1JAJh81ds=
> =5ZBO
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message