Re: siege failing and so on

-                                                 [email protected]
---------------------------------------------------------------------


--Boundary-00=_0vZi/XgVB6TKPRM
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


<snip>

> hmm, IIRC on Linux, threads are normal processes, but sharing almost
> evrything but stack and and registers. So it shouldnt make things worse
> using threads instead of separate processes. But MT makes some things
> a little bit difficult due shared memory (so locking is required).

Not instead!! I want to say that we must hard limit the number of clones(Let 
name process or thread --- "clone"). We must do it because of factor of many 
uid/gid instances - separate processes, against usual apache. 


<snip>

>
> hmm, it normally should normally have one process per uid/gid, which itself
> has an listen thread and as many worker threads as required. (if idle, only
> the listen thread should exist) ... dont know why you get 3 ones.

My ps tree right after apache startup is in attach if it can help.
My httpd.conf:

ServerLimit 300
StartThreads 1
MaxSpareThreads 5
Multiplexer apache apache
include conf/processors.conf

NameVirtualHost *
include conf/vhost.conf


>
> > It' is nessesary to do so because on web-hosting providers many vhosts
> > has very low number of queries per second. Ususally it's << 1. That hosts
> > do not need many threads wasted system resources.
>
> At this point we should think about an start-on-call mechanism, which
> forks processors as needed. But its a little bit tricky.
> For lower amount of users it should not be so dramatic having many
> sleeping processes, since they consume almost nothing on linux.

Usual apache 1.3.27 has on my current hosting 5 forks and pretty serve ~100 
vhosts. In case of metuxmpm I get ~ 300 clones at startup only and if any 
rare requests become on some vhost it clone itself to ~20-50. If I simply 
browse each vhost in my broser once(get /index.html), It become something 
dramatic in my ps table.


<snip>

>
> We already filter, but only the first request. 
It's a hole. May be difficulty exploitable, but hole. 

--Boundary-00=_0vZi/XgVB6TKPRM
Content-Type: application/x-gzip;
  name="ps-apache-tree.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ps-apache-tree.gz"

H4sICI2YiT8AA3BzLWFwYWNoZS10cmVlALXUzU6EMBDA8TtPMS8gtFO2hb34Dno1MWXBbLPQbqDG
mPjwlo9DMa4KcThsD7D5JX+Y6Z3zMF5cKp5DnqcCsEgloBQ5D8ehZBzhfnrmYfxBPDIRTnZkHLLX
oc9ad9Jtpq/6dG6yytjs7P21hrsLDF73PpnvLMYh/DNlo6GCoZTA0ZBFsRiPXwwG8PS8wym2Ox+w
0yr3WfBnL3lrqk4PfuZkOIgSxg5y2oQrC8kT1p3x/fvyxhRdwthBQZtwZeXkCSvnnV2WBTK6QV45
kjbhylLkCa32ujXNzBHuwtgRO17VloQra+fS2DLITeeGl8ZOCcOaF1SDHDmCepBji36Qa9PpS2/8
lLD8fheW+A8JI0fc+Np/cjYljK0bS+M3a0PCdLoSbWsYHDj7CTNkO4FJCQAA

--Boundary-00=_0vZi/XgVB6TKPRM--