You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Laurent Sinitambirivoutin <du...@eurosport.com> on 1999/06/29 20:31:28 UTC

about threads (yes it's an obsession :-)

hello guys :-)

before bothering you again i've read the docs about linuxthreads
well, under linux threads are "viewed" as processes by the kernel, i
mean they enter in the 512 entries of a regular linux kernel. I still
see this as a weak point because my real problem at eurosport is that I
just can't apache go forking (unless i want my server to kneel down of
course) I thought that threads could solve the problem cuz I believed
they wouldn't be accounted as one of the 512 process allowed... sniff !
So, my question is: will things like apr (for now) and soon mpm will
allow me to sleep well regarding the process limit ??

an other thing: i'm far from being a C-supercoder ;-), and I'm quite
good in perl. If I can be of any help on the project (instead of posting
silly questions ;), please just let me know

-- 
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !

Re: about threads (yes it's an obsession :-)

Posted by Laurent Sinitambirivoutin <du...@eurosport.com>.
Ben Laurie wrote:
> 
> > "Un tien vaut mieux que deux tu l'auras" ("one
> > yours is better that two you will have") as people say in France ;-)
> 
> "A bird in the hand is worth two in the bush" in English. :-)
> 
> Cheers,
> 
> Ben.
> 

thanks for this translation Ben :-) 

-- 
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !

Re: about threads (yes it's an obsession :-)

Posted by Ben Laurie <be...@algroup.co.uk>.
> "Un tien vaut mieux que deux tu l'auras" ("one
> yours is better that two you will have") as people say in France ;-)

"A bird in the hand is worth two in the bush" in English. :-)

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Re: about threads (yes it's an obsession :-)

Posted by Laurent Sinitambirivoutin <du...@eurosport.com>.
> I realise this is probably heresy, but what about using something other
> than Linux? FreeBSD, for example? I'm not saying it will necessarily
> help, but I don't think it has a 512 process limit.
> 
> Cheers,
> 
> Ben.

no this isn't heresy ;-)
... but i just can't change of OS like I change shirts ;-)
and my boss (and I ;-) invested a lot in Linux, so i'm not in a position
to use an other OS (besides i'm really not a *BSD expert ;-) Sure linux
isn't perfect (but which OS is ?) but hey i'm using it since 5 years
now, i'm happy with it and since technical happiness is not that
frequent is this job... "Un tien vaut mieux que deux tu l'auras" ("one
yours is better that two you will have") as people say in France ;-)

-- 
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !

Re: about threads (yes it's an obsession :-)

Posted by Ben Laurie <be...@algroup.co.uk>.
Laurent Sinitambirivoutin wrote:
> 
> hello guys :-)
> 
> before bothering you again i've read the docs about linuxthreads
> well, under linux threads are "viewed" as processes by the kernel, i
> mean they enter in the 512 entries of a regular linux kernel. I still
> see this as a weak point because my real problem at eurosport is that I
> just can't apache go forking (unless i want my server to kneel down of
> course) I thought that threads could solve the problem cuz I believed
> they wouldn't be accounted as one of the 512 process allowed... sniff !
> So, my question is: will things like apr (for now) and soon mpm will
> allow me to sleep well regarding the process limit ??

I realise this is probably heresy, but what about using something other
than Linux? FreeBSD, for example? I'm not saying it will necessarily
help, but I don't think it has a 512 process limit.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

Re: about threads (yes it's an obsession :-) (getting more processes under Linux)

Posted by Tani Hosokawa <un...@riverstyx.net>.
This is kinda off-topic, I guess, but edit
/usr/src/linux/include/linux/tasks.h and set NR_TASKS to 2048, with 1800
as MAX_TASKS_PER_USER and you won't run into that wall again.  Those are
just the settings I prefer, and they work fine for me.

On Tue, 29 Jun 1999, Laurent Sinitambirivoutin wrote:

> hello guys :-)
> 
> before bothering you again i've read the docs about linuxthreads
> well, under linux threads are "viewed" as processes by the kernel, i
> mean they enter in the 512 entries of a regular linux kernel. I still
> see this as a weak point because my real problem at eurosport is that I
> just can't apache go forking (unless i want my server to kneel down of
> course) I thought that threads could solve the problem cuz I believed
> they wouldn't be accounted as one of the 512 process allowed... sniff !
> So, my question is: will things like apr (for now) and soon mpm will
> allow me to sleep well regarding the process limit ??
> 
> an other thing: i'm far from being a C-supercoder ;-), and I'm quite
> good in perl. If I can be of any help on the project (instead of posting
> silly questions ;), please just let me know

---
tani hosokawa
river styx internet



Re: about threads (yes it's an obsession :-)

Posted by Laurent Sinitambirivoutin <du...@eurosport.com>.
Tani Hosokawa wrote:
 
> I wouldn't consider that to be a short-term solution.  I run servers that
> do over 1500 processes for hours at a time, on *MUCH* smaller hardware.
> The standard kernel isn't configured for production server usage... just
> increase NR_TASKS, it'll be fine.

thanks Tani for the advice. I'll make the changes as soon as i can 

-- 
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !

Re: about threads (yes it's an obsession :-)

Posted by Tani Hosokawa <un...@riverstyx.net>.
On Tue, 29 Jun 1999, Laurent Sinitambirivoutin wrote:

> well, as a matter of fact, i use a regular linux on top of a bipentium
> II xeon 400, with 21GB raid5 and 1GB ram. Until the Roland Garros tennis
> tournament, we never had any problem. At that occasion we served pages
> which were refreshed every minute. We had more than 130 000 users a day
> on Rolland Garros only. Besides the fact that our bandwith wasn't big
> enough anymore (though it was a 4Mb one), I suddenly saw apache
> generating about 400 processes... and shortly after that my server
> wasn't responding anymore (i had to wait for a lower load and
> reconfigure apache to 250 process max but of course the site got very
> slow to respond). Of course, I could raise my process limit, but beside
> the fact that I can't just reboot the server every now and then, i feel
> this would be a very short term solution. Well, i think that load
> balancing can help me on this. But now, if apache-pthreads can handle
> the same job than 1.3.3 with only 81 process, i have to seriously
> consider the option

I wouldn't consider that to be a short-term solution.  I run servers that
do over 1500 processes for hours at a time, on *MUCH* smaller hardware.
The standard kernel isn't configured for production server usage... just
increase NR_TASKS, it'll be fine.

---
tani hosokawa
river styx internet



Re: about threads (yes it's an obsession :-)

Posted by Laurent Sinitambirivoutin <du...@eurosport.com>.
Dean Gaudet wrote:
> apache-nspr can solve it as well (nspr uses userland threads).

yeah this one works fine on my workstation (linux 2.2.5) but keeps on
giving me seg fault on the server (linux 2.2.1) though both apache and
nspr compiled fine...
 
> Or using squid in front of an apache-1.3 (see the accelerator docs for
> squid).

i'll get a look on this ;-)

> or using multiple machines, or a bigger machine (more RAM?).

more ram would be pointless, since i've already got 1GB. The server was
bought b4 my arrival in the company, and I always thought it was far too
big.
anyway, I'm seriouly considering to go for load-balancing...

> I'm honestly surprised you have enough bandwidth that one box isn't
> satisfactory.  Either you have dynamic content chewing CPU (in which case
> a threaded apache is going to be of little extra help); or you haven't
> tuned your server; or ... I don't know.  But unless you've got enough
> traffic to be filling many many T-1s I don't think the problem is Apache.

well, as a matter of fact, i use a regular linux on top of a bipentium
II xeon 400, with 21GB raid5 and 1GB ram. Until the Roland Garros tennis
tournament, we never had any problem. At that occasion we served pages
which were refreshed every minute. We had more than 130 000 users a day
on Rolland Garros only. Besides the fact that our bandwith wasn't big
enough anymore (though it was a 4Mb one), I suddenly saw apache
generating about 400 processes... and shortly after that my server
wasn't responding anymore (i had to wait for a lower load and
reconfigure apache to 250 process max but of course the site got very
slow to respond). Of course, I could raise my process limit, but beside
the fact that I can't just reboot the server every now and then, i feel
this would be a very short term solution. Well, i think that load
balancing can help me on this. But now, if apache-pthreads can handle
the same job than 1.3.3 with only 81 process, i have to seriously
consider the option
Moreover, i'm continuously afflicted with sudden drops of apache
activity. As far as i've understood it reading the bug base, it seems to
be a linux problem, sth with fnctl/flock-serialization. Neither of those
methods are of any good for me, someone wrote that he solved this using
2.2.7 but he couldn't figure out what had changed in the kernel. I
understand that a threaded serialization method exists, but i couldn't
use it (linuxthreads and solaris are not really compatible it seems).
For now, i'm solving this by restarting apache every 5mn (!) which
freaks me out. Unhappily, 2.2.7 isn't present in any mainstream
distributions (i can't afford to upgrade bits of the server... cohesion
cohesion ah!) and anyway i'm not even sure that his solution is good for
me :-(
well here are my tiny problems. Maybe now you understand why i came to
think of a threaded apache as a graal-like solution

> You should probably find some unix tuning documentation, there's some new
> linux docs... I don't know where they are, I can't help you find them.
> 
> Start with "vmstat 1", maybe it'll provide you with some insight.
 
huhu.. well, i'll try to get doc on this ;-)

thank for your time, guys. As I said in my last posting, i'm ready to
help (i'm better in perl than C, but hell my C is still better than my
english ;-). Just tell me

-- 
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !

Re: about threads (yes it's an obsession :-)

Posted by Dean Gaudet <dg...@arctic.org>.
On Tue, 29 Jun 1999, Laurent Sinitambirivoutin wrote:

> hello guys :-)
> 
> before bothering you again i've read the docs about linuxthreads
> well, under linux threads are "viewed" as processes by the kernel, i
> mean they enter in the 512 entries of a regular linux kernel. I still
> see this as a weak point because my real problem at eurosport is that I
> just can't apache go forking (unless i want my server to kneel down of
> course) I thought that threads could solve the problem cuz I believed
> they wouldn't be accounted as one of the 512 process allowed... sniff !
> So, my question is: will things like apr (for now) and soon mpm will
> allow me to sleep well regarding the process limit ??

no apr, or apache-apr/pthreads won't solve it (they use native threads). 

the MPM I'm working on can solve it, but you'll be waiting for longer (it
only requires as many threads as there are active connections at any one
instant). 

apache-nspr can solve it as well (nspr uses userland threads). 

As can using zeus, or thttpd... (neither use threads). 

Or using squid in front of an apache-1.3 (see the accelerator docs for
squid).

or using multiple machines, or a bigger machine (more RAM?). 

I'm honestly surprised you have enough bandwidth that one box isn't
satisfactory.  Either you have dynamic content chewing CPU (in which case
a threaded apache is going to be of little extra help); or you haven't
tuned your server; or ... I don't know.  But unless you've got enough
traffic to be filling many many T-1s I don't think the problem is Apache.

You should probably find some unix tuning documentation, there's some new
linux docs... I don't know where they are, I can't help you find them.

Start with "vmstat 1", maybe it'll provide you with some insight.

Dean