You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by BB Commish <bb...@hotmail.com> on 2005/11/18 18:50:29 UTC
Managing concurrent high memory processes
We have a Struts application running on Tomcat where a few actions within
the app can invoke processing that consumes 300+ MB of RAM and can run for
several hours. The issue is how to make the application more scalable to
accommodate multiple concurrent 'high load' processes and also make better
use of servers with available RAM beyond the jvm limits (we have used both
Sun and JRockit jvms - typically on Win2k3 as per customer requirements).
Would Tomcat clustering/load balancing be suited to this problem? Or is it
more geared to managing high volumes of requests rather than just dealing
with certain high load requests that need special attention?
We have also considered spawning a separate jvm instance (or retrieving from
a pool more likely) to handle each high load request with the 'normal'
requests being handled within the jvm running Tomcat. Is this a feasible
option?
I will appreciate any comments. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Managing concurrent high memory processes
Posted by Peter Lin <wo...@gmail.com>.
sounds like you have a heafty reporting process, which loads a ton of data
and generates a large report. I definitely wouldn't recommend running these
processes within a single instance of Tomcat. You'll easily eat all the
available RAM and get OOME.
A better approach would be to off-load the process and use something like
JMS to route the message. If the process is generating a report, I would
recommend revisiting the design and implementation of that component. More
specifically, if you're running all sorts of multi-dimensional reports on a
large dataset that's 500K+ records, consider using an OLAP product. In many
cases, using MOLAP approach can reduce the processing time by 10x.
good luck
peter
On 11/18/05, BB Commish <bb...@hotmail.com> wrote:
>
> We have a Struts application running on Tomcat where a few actions within
> the app can invoke processing that consumes 300+ MB of RAM and can run for
> several hours. The issue is how to make the application more scalable to
> accommodate multiple concurrent 'high load' processes and also make better
> use of servers with available RAM beyond the jvm limits (we have used both
> Sun and JRockit jvms - typically on Win2k3 as per customer requirements).
>
> Would Tomcat clustering/load balancing be suited to this problem? Or is it
> more geared to managing high volumes of requests rather than just dealing
> with certain high load requests that need special attention?
>
> We have also considered spawning a separate jvm instance (or retrieving
> from
> a pool more likely) to handle each high load request with the 'normal'
> requests being handled within the jvm running Tomcat. Is this a feasible
> option?
>
> I will appreciate any comments. Thanks.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Managing concurrent high memory processes
Posted by Peter Lin <wo...@gmail.com>.
it is overhead, but there really aren't too many options for the case given.
If the process really will take a long time, having the process happen
within the tomcat using the same JVM will introduce instability. In the long
run, it is going to be hard to maintain a production system with such long
running processes.
by spawning new processes, one can atleast get a big box with 8Gb of ram and
kick multiple processes. I know of several applications that use the JMS
model to handle heavy processes that take several minutes. This way, it
allows the application to send a JMS message, the message gets routed to the
big box for processing, when it is done, a message is sent back to the
browser or webserver. Scaling this approach should be easier and is a matter
of adding more servers to listen to the JMS topic. hope that helps
peter
On 11/21/05, BB Commish <bb...@hotmail.com> wrote:
>
> Thanks Richard. I do require communication back to the user so I will take
> a
> look at JMS as you suggest.
>
> My concern with spawning jvms (as I mentioned in a reply to another list
> member) is the additional overhead and the additional difficulty (as I
> perceive it anyway) of deploying to a multi-machine environment.
>
>
> >From: "Richard Mixon" <rn...@qwest.net>
> >Reply-To: <rn...@qwest.net>
> >To: "'Tomcat Users List'" <us...@tomcat.apache.org>
> >Subject: RE: Managing concurrent high memory processes
> >Date: Fri, 18 Nov 2005 11:14:55 -0700
> >
> >BB,
> >
> >It sounds like you are talking about what used to be called "batch
> >processing". The workload is simply kicked off from a web request. Does
> it
> >(attempt) to return a request to the user? Are timeouts and issue?
> >
> >As far as available RAM - the obvious solution here is to move to a
> 64-bit
> >OS. We've been using AMD Opterons and SuSE Linux for high-memory Tomcat
> >(JVM
> >heap > 2GB) for a couple of years now. But I'm also running Windows XP
> _64
> >on my desktop and its JVM seems able to take more than 2GB also. We have
> a
> >somewhat similar problem, in that we have to dynamically build an
> in-memory
> >"cube" of analytical data for charting and what-if exploration of
> >results.But our reponses typically come back in between 15 seconds and a
> >couple of minutes.
> >
> >Depending on how large your session is, you may not really want to use
> >clustering - because your sessions are replicated across all or a subset
> of
> >machines.
> >
> >However simple load balancing with session affinity might help you scale
> >your solution - either with multiple Tomcat's on a single machine or on
> >separate machines.
> >
> >But ultimately, I think you are going down the correct path to consider
> >spawning a separate JVM to handle this if it is a true "batch request".
> >From
> >what I know (please correct me if I'm wrong here) Tomcat is definitely
> >optimized for handling larger numbers of "relatively" small requests. Its
> >also much easier to tune Tomcat if you have a larger numbers of similarly
> >sized workloads (requests). On mainframe transaction processing the
> analogy
> >was to an hour glass - if you mixed a few pebbles in with all of the
> grains
> >of sand, you ended up clogging up the works for everyone - not just
> >yourself.
> >
> >This also lets you allocate CPU resources to these separate JVM as you
> wish
> >- if its all in Tomcat, you have much less control.
> >
> >Also, if communication has to occur back to a Tomcat user, you might
> >consider using Java Messaging Service for this - at which point you
> should
> >look at Jboss or similar application server that has Tomcat and a JMS
> >bundled together.
> >
> >Hope these thoughts are useful.
> >
> > - Richard
> >
> >
> > > -----Original Message-----
> > > From: BB Commish [mailto:bbcommish@hotmail.com]
> > > Sent: Friday, November 18, 2005 10:50 AM
> > > To: users@tomcat.apache.org
> > > Subject: Managing concurrent high memory processes
> > >
> > > We have a Struts application running on Tomcat where a few
> > > actions within the app can invoke processing that consumes
> > > 300+ MB of RAM and can run for several hours. The issue is
> > > how to make the application more scalable to accommodate
> > > multiple concurrent 'high load' processes and also make
> > > better use of servers with available RAM beyond the jvm
> > > limits (we have used both Sun and JRockit jvms - typically on
> > > Win2k3 as per customer requirements).
> > >
> > > Would Tomcat clustering/load balancing be suited to this
> > > problem? Or is it more geared to managing high volumes of
> > > requests rather than just dealing with certain high load
> > > requests that need special attention?
> > >
> > > We have also considered spawning a separate jvm instance (or
> > > retrieving from a pool more likely) to handle each high load
> > > request with the 'normal'
> > > requests being handled within the jvm running Tomcat. Is this
> > > a feasible option?
> > >
> > > I will appreciate any comments. Thanks.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: Managing concurrent high memory processes
Posted by Richard Mixon <rn...@qwest.net>.
BB,
Depending on how many dedicated JVMs you would startup, I do not believe the
overhead from creating a new JVM for each long-running task will be that
bad. Now if you've got dozens, forget it. In that case you need to move to a
JMS-type solution with queueing.
Think about it - you've got the same amount of work going on (i.e. threads
and memory) but they are just distributed across multiple JVMs - some of
which are dedicated to single tasks. If you are using Java 5 there is even
some minimal sharing of resources that can occur across the JVMs.
But eventually, you do need something like JMS. Along with decoupling where
the long running process actually resides, you also can queue things up so
that when you have peak loads things don't go crash. Responses will take a
bit longer as the long-running processes get queued, but they will get done
at least. Of course you can always add more servers to handle the load.
Good luck - Richard
> -----Original Message-----
> From: BB Commish [mailto:bbcommish@hotmail.com]
> Sent: Monday, November 21, 2005 2:45 PM
> To: users@tomcat.apache.org
> Subject: RE: Managing concurrent high memory processes
>
> Thanks Richard. I do require communication back to the user
> so I will take a look at JMS as you suggest.
>
> My concern with spawning jvms (as I mentioned in a reply to
> another list
> member) is the additional overhead and the additional
> difficulty (as I perceive it anyway) of deploying to a
> multi-machine environment.
>
>
> >From: "Richard Mixon" <rn...@qwest.net>
> >Reply-To: <rn...@qwest.net>
> >To: "'Tomcat Users List'" <us...@tomcat.apache.org>
> >Subject: RE: Managing concurrent high memory processes
> >Date: Fri, 18 Nov 2005 11:14:55 -0700
> >
> >BB,
> >
> >It sounds like you are talking about what used to be called "batch
> >processing". The workload is simply kicked off from a web
> request. Does
> >it
> >(attempt) to return a request to the user? Are timeouts and issue?
> >
> >As far as available RAM - the obvious solution here is to move to a
> >64-bit OS. We've been using AMD Opterons and SuSE Linux for
> high-memory
> >Tomcat (JVM heap > 2GB) for a couple of years now. But I'm
> also running
> >Windows XP _64 on my desktop and its JVM seems able to take
> more than
> >2GB also. We have a somewhat similar problem, in that we have to
> >dynamically build an in-memory "cube" of analytical data for
> charting
> >and what-if exploration of results.But our reponses
> typically come back
> >in between 15 seconds and a couple of minutes.
> >
> >Depending on how large your session is, you may not really
> want to use
> >clustering - because your sessions are replicated across all or a
> >subset of machines.
> >
> >However simple load balancing with session affinity might help you
> >scale your solution - either with multiple Tomcat's on a
> single machine
> >or on separate machines.
> >
> >But ultimately, I think you are going down the correct path
> to consider
> >spawning a separate JVM to handle this if it is a true
> "batch request".
> >From
> >what I know (please correct me if I'm wrong here) Tomcat is
> definitely
> >optimized for handling larger numbers of "relatively" small
> requests.
> >Its also much easier to tune Tomcat if you have a larger numbers of
> >similarly sized workloads (requests). On mainframe transaction
> >processing the analogy was to an hour glass - if you mixed a few
> >pebbles in with all of the grains of sand, you ended up
> clogging up the
> >works for everyone - not just yourself.
> >
> >This also lets you allocate CPU resources to these separate
> JVM as you
> >wish
> >- if its all in Tomcat, you have much less control.
> >
> >Also, if communication has to occur back to a Tomcat user, you might
> >consider using Java Messaging Service for this - at which point you
> >should look at Jboss or similar application server that has
> Tomcat and
> >a JMS bundled together.
> >
> >Hope these thoughts are useful.
> >
> > - Richard
> >
> >
> > > -----Original Message-----
> > > From: BB Commish [mailto:bbcommish@hotmail.com]
> > > Sent: Friday, November 18, 2005 10:50 AM
> > > To: users@tomcat.apache.org
> > > Subject: Managing concurrent high memory processes
> > >
> > > We have a Struts application running on Tomcat where a
> few actions
> > > within the app can invoke processing that consumes
> > > 300+ MB of RAM and can run for several hours. The issue is
> > > how to make the application more scalable to accommodate multiple
> > > concurrent 'high load' processes and also make better use
> of servers
> > > with available RAM beyond the jvm limits (we have used
> both Sun and
> > > JRockit jvms - typically on
> > > Win2k3 as per customer requirements).
> > >
> > > Would Tomcat clustering/load balancing be suited to this
> problem? Or
> > > is it more geared to managing high volumes of requests
> rather than
> > > just dealing with certain high load requests that need special
> > > attention?
> > >
> > > We have also considered spawning a separate jvm instance (or
> > > retrieving from a pool more likely) to handle each high
> load request
> > > with the 'normal'
> > > requests being handled within the jvm running Tomcat. Is this a
> > > feasible option?
> > >
> > > I will appreciate any comments. Thanks.
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> > >
> > >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >For additional commands, e-mail: users-help@tomcat.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Managing concurrent high memory processes
Posted by BB Commish <bb...@hotmail.com>.
Thanks Richard. I do require communication back to the user so I will take a
look at JMS as you suggest.
My concern with spawning jvms (as I mentioned in a reply to another list
member) is the additional overhead and the additional difficulty (as I
perceive it anyway) of deploying to a multi-machine environment.
>From: "Richard Mixon" <rn...@qwest.net>
>Reply-To: <rn...@qwest.net>
>To: "'Tomcat Users List'" <us...@tomcat.apache.org>
>Subject: RE: Managing concurrent high memory processes
>Date: Fri, 18 Nov 2005 11:14:55 -0700
>
>BB,
>
>It sounds like you are talking about what used to be called "batch
>processing". The workload is simply kicked off from a web request. Does it
>(attempt) to return a request to the user? Are timeouts and issue?
>
>As far as available RAM - the obvious solution here is to move to a 64-bit
>OS. We've been using AMD Opterons and SuSE Linux for high-memory Tomcat
>(JVM
>heap > 2GB) for a couple of years now. But I'm also running Windows XP _64
>on my desktop and its JVM seems able to take more than 2GB also. We have a
>somewhat similar problem, in that we have to dynamically build an in-memory
>"cube" of analytical data for charting and what-if exploration of
>results.But our reponses typically come back in between 15 seconds and a
>couple of minutes.
>
>Depending on how large your session is, you may not really want to use
>clustering - because your sessions are replicated across all or a subset of
>machines.
>
>However simple load balancing with session affinity might help you scale
>your solution - either with multiple Tomcat's on a single machine or on
>separate machines.
>
>But ultimately, I think you are going down the correct path to consider
>spawning a separate JVM to handle this if it is a true "batch request".
>From
>what I know (please correct me if I'm wrong here) Tomcat is definitely
>optimized for handling larger numbers of "relatively" small requests. Its
>also much easier to tune Tomcat if you have a larger numbers of similarly
>sized workloads (requests). On mainframe transaction processing the analogy
>was to an hour glass - if you mixed a few pebbles in with all of the grains
>of sand, you ended up clogging up the works for everyone - not just
>yourself.
>
>This also lets you allocate CPU resources to these separate JVM as you wish
>- if its all in Tomcat, you have much less control.
>
>Also, if communication has to occur back to a Tomcat user, you might
>consider using Java Messaging Service for this - at which point you should
>look at Jboss or similar application server that has Tomcat and a JMS
>bundled together.
>
>Hope these thoughts are useful.
>
> - Richard
>
>
> > -----Original Message-----
> > From: BB Commish [mailto:bbcommish@hotmail.com]
> > Sent: Friday, November 18, 2005 10:50 AM
> > To: users@tomcat.apache.org
> > Subject: Managing concurrent high memory processes
> >
> > We have a Struts application running on Tomcat where a few
> > actions within the app can invoke processing that consumes
> > 300+ MB of RAM and can run for several hours. The issue is
> > how to make the application more scalable to accommodate
> > multiple concurrent 'high load' processes and also make
> > better use of servers with available RAM beyond the jvm
> > limits (we have used both Sun and JRockit jvms - typically on
> > Win2k3 as per customer requirements).
> >
> > Would Tomcat clustering/load balancing be suited to this
> > problem? Or is it more geared to managing high volumes of
> > requests rather than just dealing with certain high load
> > requests that need special attention?
> >
> > We have also considered spawning a separate jvm instance (or
> > retrieving from a pool more likely) to handle each high load
> > request with the 'normal'
> > requests being handled within the jvm running Tomcat. Is this
> > a feasible option?
> >
> > I will appreciate any comments. Thanks.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Managing concurrent high memory processes
Posted by Richard Mixon <rn...@qwest.net>.
BB,
It sounds like you are talking about what used to be called "batch
processing". The workload is simply kicked off from a web request. Does it
(attempt) to return a request to the user? Are timeouts and issue?
As far as available RAM - the obvious solution here is to move to a 64-bit
OS. We've been using AMD Opterons and SuSE Linux for high-memory Tomcat (JVM
heap > 2GB) for a couple of years now. But I'm also running Windows XP _64
on my desktop and its JVM seems able to take more than 2GB also. We have a
somewhat similar problem, in that we have to dynamically build an in-memory
"cube" of analytical data for charting and what-if exploration of
results.But our reponses typically come back in between 15 seconds and a
couple of minutes.
Depending on how large your session is, you may not really want to use
clustering - because your sessions are replicated across all or a subset of
machines.
However simple load balancing with session affinity might help you scale
your solution - either with multiple Tomcat's on a single machine or on
separate machines.
But ultimately, I think you are going down the correct path to consider
spawning a separate JVM to handle this if it is a true "batch request". From
what I know (please correct me if I'm wrong here) Tomcat is definitely
optimized for handling larger numbers of "relatively" small requests. Its
also much easier to tune Tomcat if you have a larger numbers of similarly
sized workloads (requests). On mainframe transaction processing the analogy
was to an hour glass - if you mixed a few pebbles in with all of the grains
of sand, you ended up clogging up the works for everyone - not just
yourself.
This also lets you allocate CPU resources to these separate JVM as you wish
- if its all in Tomcat, you have much less control.
Also, if communication has to occur back to a Tomcat user, you might
consider using Java Messaging Service for this - at which point you should
look at Jboss or similar application server that has Tomcat and a JMS
bundled together.
Hope these thoughts are useful.
- Richard
> -----Original Message-----
> From: BB Commish [mailto:bbcommish@hotmail.com]
> Sent: Friday, November 18, 2005 10:50 AM
> To: users@tomcat.apache.org
> Subject: Managing concurrent high memory processes
>
> We have a Struts application running on Tomcat where a few
> actions within the app can invoke processing that consumes
> 300+ MB of RAM and can run for several hours. The issue is
> how to make the application more scalable to accommodate
> multiple concurrent 'high load' processes and also make
> better use of servers with available RAM beyond the jvm
> limits (we have used both Sun and JRockit jvms - typically on
> Win2k3 as per customer requirements).
>
> Would Tomcat clustering/load balancing be suited to this
> problem? Or is it more geared to managing high volumes of
> requests rather than just dealing with certain high load
> requests that need special attention?
>
> We have also considered spawning a separate jvm instance (or
> retrieving from a pool more likely) to handle each high load
> request with the 'normal'
> requests being handled within the jvm running Tomcat. Is this
> a feasible option?
>
> I will appreciate any comments. Thanks.
>
>
>
> ---------------------------------------------------------------------
> 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