Re: Tomcat not scaling very well...

[Henri Gomez]

 >My recommendation is to stop using autoreload, and use IBM's VM 
because for
> what I can remember, it handles more file descriptors better than Sun's...

Yes, autoreload should be off on production servers since it cause
performance penalty and also that deploying a new application should
allways be planned.

And I confirm that IBM SDK for Linux really rocks and is very stable


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat not scaling very well...

[Pier Fumagalli]

"Pat Schaider" <[EMAIL PROTECTED]> wrote:

> Hello all --
> 
> I'm risking getting scolded for using the wrong list for this, but the
> tomcat-user list was totally useless in solving this problem.
> 
> The problem is on Tomcat 4.0.3 Standalone on Linux.  I am managing this
> machine for my university's CS department, so we are using the security
> manager to keep students out of each others' files (so one context cannot
> FileInputStream() files in another context).
> 
> We have contexts for each user for the security manager, and so that we
> can override the location of webapp directories, log files, etc.  Note
> that students do not have logins on this machine; their Tomcat-related
> files are exported to other machines.
> 
> The server starts up correctly (./startup.sh -security) and deploys and
> serves the webapps fine.  But here's the problem: when a user decides to
> make a new jsp file, Tomcat cannot compile or process that new file.
> The old files in the directory still display properly; however Tomcat
> gives a Permission Denied error for the new file citing the working
> directory version of file in question.
> 
> -> error message:
> /usr/local/jakarta-tomcat-4.0.3/work/localhost/user/tomcat/webapps/myFiles/gra
> derC$jsp.java
> (Permission denied)
> 
> I think that the machine is running out of file handles to open any
> new files.  Looking in the /proc/[pid]/fd directory shows that each of
> 500 threads is opening each of the 250 user log files in addition to the
> normal files/pipes/sockets it must open.
> 
> Here's some site-specific config info that will be useful.
> Tomcat version: 4.0.3 Standalone from binary
> There are about 250 contexts that get loaded when the server starts.  A
> `ps aux` listing shows about 500 processes associated with Tomcat
> running.  The machine is a P3-800 with 512 MB of memory, and does not
> have any other heavy services running on it, so Tomcat has full run of
> the box.  
> 
> Does anyone have experience setting up a system with this many
> contexts?  What can I do?  I realize it's probably an extension of what
> Tomcat is supposed to be used for with all the different contexts, but
> there must be a way!  Any help is appreciated.  And sorry for the lengthy
> message.

Please do mind that usually VMs (at least Sun's) are borked when using
something more that 2.5k file descriptors, so, I don't think you'll actually
manage to have 500 contexts in one single VM process...

The 500 "processes" you are seeing are Linux threads (damn Linux), and those
are roughly allright, I believe you use something like autoreload for each
context, therefore, you'll have one thread per context just doing basically
nothing... I've got some experience with more than 500 threads per VM on
Linux, but we had to switch OS because context switching was overkilling.

If you think that increasing the number of file descriptors might help, you
can always use "ulimit -n " where  is the number of FDs each process
(and all associated threads) can open (therefore, that's the MAX value for
all you 500 threads reported by PS ALL TOGETHER).

One thing to check is also the output of "lsof", gives you some very good
insight of what's going on...

My recommendation is to stop using autoreload, and use IBM's VM because for
what I can remember, it handles more file descriptors better than Sun's...

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: