Michael Jerger wrote:
Hi,

a) are you sure ? Since, commercially speaking, I can't imagine what
benefit they would get from this (as opposed to e.g. limiting the amount
of RAM or disk space), I tend to have a doubt.

unfortunately I am ... and yes, I agree - this option is absolutely mindless ...

Also, I am not sure but it seems to me that if there is a maximum number of
processes built-in, that should be a configurable OS setting in Linux.

This option is set by the VM Hostingsystem - so I can't change this on os level.

b) thread != process.  See e.g.
http://manpages.ubuntu.com/manpages/intrepid/man7/pthreads.7.html

I know the difference - so to get my process count I use pstree. As I Know pstree counts processes (parent and child) - right?

Thats quite a huge issue, because I want to operate two virtual hosts:

apache-dev -- tomcat-dev -- mysql
apache-www -- tomcat-prod -- mysql

* mysql uses 50 threads in total
* apache uses 5
* tomcat_prod - 109
* tomcat_dev - 73
c) again, are you not confusing threads and processes ?
For Apache httpd e.g., depending on the MPM model used, you will be using
either processes (pre-fork MPM) or threads, or both.

No I use prefork - but I know the other mpm options to so I will switch to threading as soon as I understand the tomcat behaviour.

In a prefork MPM, that can indeed lead to up to 51 simultaneous *processes*
(aka 1 main Apache + 50 Apache "children"), IF you have as many
simultaneous requests being processed. I run many sites with Maxclients
20, or less (specially for development sites).

Maxclinets is defined for two v-hosts - prod with 40 and dev with 3 so your right, I can save 7 processes here :-)


I am not sure, but you may have the wrong understanding of v-hosts. Are you talking about Apache VirtualHosts, or (VMware) virtual machines here ? What I mean is that the MaxClients setting for Apache httpd is global, and does not apply to VirtualHosts separately.



* mod_jk connection_pool_size (3/40), socket_keepalive=false
There is not really any benefit to have more Apache-Tomcat connections,
than your MaxClients setting above.

(3/40) means 3 for dev and 40 for prod.

* server.xml:

<Executor name="tomcatDevThreadPool" namePrefix="catalina-exec-"

        daemon="false" maxThreads="(3/40)" maxSpareThreads="5"

minSpareThreads="1"/>
Ideally, you need as many threads as there can be individual *tomcat*
requests in the course of being processed at the same time.  There is no
benefit in having (or starting) more than that.
Since presumably all requests pass first through Apache before there reach
Tomcat, you need as a maximum number of Tomcat threads, the same number ax
MaxClients in Apache.

Your right - I will decrease my maxclients for 7. But how can I limit the number of tomcat-processes? Even if I assume that a java thread is mapped to one os-process I don't understand the 109 tomcat processes in a nearly idle tomcat with maxthreads 4 configured at his only connector!


I have no idea how the following is going to show up in an email, but this is what I get when I enter "pstree" on one of my linux Debian production systems running Apache httpd and tomcat :

evm2:~# pstree
init─┬─acpid
     ├─apache2───25*[apache2]
     ├─avahi-daemon───avahi-daemon
     ├─cron
     ├─dbus-daemon
     ├─6*[getty]
     ├─2*[java───14*[{java}]]
     ├─jsvc─┬─jsvc
     │      └─jsvc───40*[{jsvc}]
     ├─klogd
     ├─nmbd
     ├─nullmailer-send
     ├─portmap
     ├─rpc.statd
     ├─smbd───3*[smbd]
     ├─sshd─┬─sshd───bash
     │      └─sshd───bash───pstree
     ├─syslogd
     ├─udevd
     └─vmware-guestd


According to the man page of pstree, child /processes/ are shown between (only) [square brackets], and child /threads/ are shown between [{square and curly brackets}]. On that system, tomcat is running under "jsvc" (see "Apache commons daemon" project), so what is shown above as "jsvc" processes are actually the Java JVM instances running tomcat. A "ps -ef" command shows only 3 jsvc processes for tomcat, thus matching the 3 instances of jsvc above, but not the "40*[{jsvc}]" part, which I tend to think then are really threads, not processes. Now, independently of the "Connector" threads, which process the HTTP/AJP requests, I know that Tomcat (and the JVM) start a number of additional threads to handle various things. For example, there will be at least one JVM thread taking care of periodic garbage collection; and at least one (optional) Tomcat thread taking care of watching the webapps directories for any changes; and each "event listener" probably has its own thread and so on. But they should not count as processes.

In the case above, the relevant part of the Tomcat (5.5) configuration is (I am not using an Executor, just plain Connectors) :

    <Connector port="8180" maxHttpHeaderSize="8192"
               maxThreads="50" minSpareThreads="5" maxSpareThreads="25"
               enableLookups="false" redirectPort="8443" acceptCount="100"
               connectionTimeout="20000" disableUploadTimeout="true" />
                        
    <Connector port="8009" protocol="AJP/1.3"
                connectionTimeout="2000" maxThreads="50" minSpareThreads="10" 
maxSpareThreads="25"
        />

and Apache httpd settings are :

<IfModule mpm_prefork_module>
    StartServers          15
    MinSpareServers       15
    MaxSpareServers      25
    MaxClients          200
    MaxRequestsPerChild   0
</IfModule>

(So as you see, I am not even following my own principles ;-) ).
But even with the above settings on a running system, "top" shows only 100 
processes :

Tasks: 100 total,   2 running,  98 sleeping,   0 stopped,   0 zombie

(And that includes quite a bit of cron jobs, samba and vmware daemons, denyhosts and a bunch of similar things. And I have no problems starting scripts or making connections to the system).

Are you sure that the problems you have in starting scripts/connecting to the system are really due to that process limit ?
What for instance does the command "netstat -an --tcp" show ?


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

Reply via email to