I'll try loading up 18 version of my webapp and see if tomcat blows up. should know in a hour or so
peter On 4/20/05, LeeAnn Pultz <[EMAIL PROTECTED]> wrote: > when you say 50 threads, do you mean 50 separate web applications? > > My concern right now is that we seem to be limited to 17-18 copies of our > web app on a particular installation of tomcat. And that > is just hitting the login page - not doing any work. Practically, for > applications with many users, we may be limited to 7-10 copies of our > application on a tomcat. > > Maybe I'm expecting too much? Perhaps that's a reasonable number of > concurrent webapps that can be run on a tomcat? But if that is the case, > it would be good to know what the limiting factor is, if it's not number of > threads or amount of memory. > > thanks for much for your help! > > > At 05:48 PM 4/20/2005, you wrote: > >ahh ok. .. my confusion. > > > >back to the problem you see. I've tested tomcat with 30-40 threads > >without any problems in the past. Even with heavy weight JSTL tags in > >JSP's, I'm able to go up to 50 threads with tomcat4.1. > > > >I'll try hitting tomcat's status servlet with 50 threads tonight and > >see what happens. > > > > > >peter > > > > > >On 4/20/05, LeeAnn Pultz <[EMAIL PROTECTED]> wrote: > > > I think we've gotten things a bit confused :) > > > > > > The application itself is not thread intensive - our original tests show > > > that each separate copy of the web application started up 3 active > > > threads. > > > > > > Further testing, when we added in debugging code that would spin up dozens > > > of threads just to see if we could cause the tomcat to get the error if we > > > started one application up and had tons of threads, showed that we could > > > get 800+ threads with no problems (no outofmemory errors) and that the > > > problem does not in fact seem to be specifically related to the number of > > > threads the application creates. > > > > > > In fact, regardless of whether each instance of the application spins up 3 > > > threads (real situation) or 10+ (debug code only) threads, we still get > > > the > > > out of memory error not when we hit a certain number of threads, but > > > actually when we hit a certain number of servlets having been initialized. > > > > > > Testing a very simple servlet, I can start up >25 instances of the servlet > > > with no OOM error. > > > Testing our application's servlet, I can only start up 17-18 instances of > > > the servlet before getting an OOM error. > > > > > > At this point I am going through our standard application servlet, trying > > > to isolate what work it does that may cause a problem when we do it 17 or > > > 18 times on one installation of tomcat. > > > > > > > > > At 05:16 PM 4/20/2005, you wrote: > > > >if your application is thread heavy, I would recommend changing it so > > > >that one thread can manage several processes. creating 800+ threads is > > > >going to hit a scalability and reliability wall very quickly. In > > > >general, you want to make sure the number of threads remain constant > > > >under constant load. If it doesn't the server will eventually crash as > > > >you currently see. I'm guessing the application is using threads to > > > >handle async processes, which is good, but spawning new threads with > > > >every request isn't going to work. > > > > > > > >hope that helps > > > > > > > >peter > > > > > > > > > > > >On 4/20/05, LeeAnn Pultz <[EMAIL PROTECTED]> wrote: > > > > > We tried a new test :) > > > > > > > > > > We added code that spins up 8 threads inside just a plain servlet that > > > > > doesn't do anything else. When I fire up 10 different "instances" > > of that > > > > > servlet, I get hundreds of threads printing out as being active - > > and no > > > > > out of memory errors. > > > > > > > > > > So we added the same code to our (slightly more complex) application > > > > > servlet, and did the same thing. Now the reported number of threads > > > > > is > > > > > much higher, but I still get an OutOfMemory error at the same > > number of new > > > > > instances fired up (between 17-18 sites started up). > > > > > > > > > > Active Threads : WHEN STARTING INIT() 617 > > > > > [GC 57193K->46096K(129792K), 0.0353880 secs] > > > > > [GC 57936K->47554K(129792K), 0.0238210 secs] > > > > > [Full GC 49312K->47441K(129792K), 0.6546550 secs] > > > > > [Full GC 47732K->47129K(129792K), 0.7706500 secs] > > > > > [Full GC 48310K->47256K(129792K), 0.6425030 secs] > > > > > [Full GC 47276K->47263K(129792K), 0.6445770 secs] > > > > > [Full GC 47263K->47263K(129792K), 0.6368020 secs] > > > > > [Full GC 47263K->47241K(129792K), 0.7775600 secs] > > > > > java.lang.OutOfMemoryError > > > > > [Full GC 47295K->47242K(129792K), 0.6301470 secs] > > > > > [Full GC 47248K->47245K(129792K), 0.6451800 secs] > > > > > [Full GC 47257K->47250K(129792K), 0.6454320 secs] > > > > > [Full GC 47271K->47262K(129792K), 0.7056980 secs] > > > > > java.lang.OutOfMemoryError > > > > > java.lang.OutOfMemoryError > > > > > > > > > > So it looks like it isn't just a thread issue. > > > > > > > > > > If I fire up the simple servlet 18 times, I don't get the > > error. In fact, > > > > > I can then go on to fire up our main servlet another 17-18 times > > before we > > > > > get the OutOfMemory error - this time at 844 threads before it dies. > > > > > > > > > > There must be something else going on within our application that is > > > > > consuming something that the simple servlet doesn't. > > > > > > > > > > If anyone has any suggestions on other things that I could check for ? > > > > > Someone said OOM errors can mean out of file descriptors as well? > > > > > > > > > > thanks for all your help so far - I'm really hoping we can figure > > this out! > > > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > LeeAnn Pultz > > > ExtraView Corporation > > > [EMAIL PROTECTED] > > > 831-461-7100 x115 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > LeeAnn Pultz > ExtraView Corporation > [EMAIL PROTECTED] > 831-461-7100 x115 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
