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/25 18:48:24 UTC
thanks for the explanations
thanks for the explanations
i've run the hybrid server, it works fine, but still a lot of processes,
though a lot less than my actual server (81 processes instead of more
than 200 :)
Still I thought I wouldn't have more than 8 processes since MaxClients
is set to 8... So I'm a little bit confused. In fact, I've set
ThreadsPerChild to 32 instead of 8 and woee I got my 256 processes... So
I guess I must have missed something though ldd shows that httpd is
linked with pthreads
as for the apr stuff, i've compiled it and now i'm feeling dumb about it
: got lots of libs but don't have a clue about how it's supposed to get
along with apache (unless of course i'm so stupid i didn't realise i had
to code the stuff myself ;-)
--
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !
Re: newbie thread/process model question in hybrid server
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 11 Jul 1999, Tony Finch wrote:
> Dean Gaudet <dg...@arctic.org> wrote:
> >
> >You fool yourself if you think that without buffering your logs are sorted
> >by date. You just get lucky because a context switch doesn't occur at
> >exactly the wrong time most of the time.
>
> Indeed, but they are sorted enough :-)
That's what everyone keeps telling me when I whine about this :)
Dean
Re: newbie thread/process model question in hybrid server
Posted by Tony Finch <do...@dotat.at>.
Dean Gaudet <dg...@arctic.org> wrote:
>
>You fool yourself if you think that without buffering your logs are sorted
>by date. You just get lucky because a context switch doesn't occur at
>exactly the wrong time most of the time.
Indeed, but they are sorted enough :-)
Tony.
--
f.a.n.finch dot@dotat.at fanf@demon.net
Winner, International Obfuscated C Code Competition 1998
Re: newbie thread/process model question in hybrid server
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 9 Jul 1999, Tony Finch wrote:
> Dean Gaudet <dg...@arctic.org> wrote:
> >On Fri, 9 Jul 1999, Tani Hosokawa wrote:
> >
> >> It would also let you consolidate all your log writing into one burst to
> >> make your disk activity more efficient... Like with IIS, where you can set
> >> it to only log when its got 'x' bytes to write to disk. I do that right
> >> now using a piped log, but it might be more efficient if it was done in
> >> the server.
> >
> >-DBUFFERED_LOGS
>
> That reduces the number of syscalls performed by Apache but has the
> disadvantage of requiring a post-processor to sort them. I don't think
> there is a way of getting around that problem.
You fool yourself if you think that without buffering your logs are sorted
by date. You just get lucky because a context switch doesn't occur at
exactly the wrong time most of the time.
Dean
Re: newbie thread/process model question in hybrid server
Posted by Tony Finch <do...@dotat.at>.
Dean Gaudet <dg...@arctic.org> wrote:
>On Fri, 9 Jul 1999, Tani Hosokawa wrote:
>
>> It would also let you consolidate all your log writing into one burst to
>> make your disk activity more efficient... Like with IIS, where you can set
>> it to only log when its got 'x' bytes to write to disk. I do that right
>> now using a piped log, but it might be more efficient if it was done in
>> the server.
>
>-DBUFFERED_LOGS
That reduces the number of syscalls performed by Apache but has the
disadvantage of requiring a post-processor to sort them. I don't think
there is a way of getting around that problem.
Tony.
--
f.a.n.finch dot@dotat.at fanf@demon.net
Winner, International Obfuscated C Code Competition 1998
Re: newbie thread/process model question in hybrid server
Posted by Tani Hosokawa <un...@riverstyx.net>.
On Fri, 9 Jul 1999, Dean Gaudet wrote:
> > It would also let you consolidate all your log writing into one burst to
> > make your disk activity more efficient... Like with IIS, where you can set
> > it to only log when its got 'x' bytes to write to disk. I do that right
> > now using a piped log, but it might be more efficient if it was done in
> > the server.
>
> -DBUFFERED_LOGS
Oops.
---
tani hosokawa
river styx internet
Re: newbie thread/process model question in hybrid server
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 9 Jul 1999, Tani Hosokawa wrote:
> It would also let you consolidate all your log writing into one burst to
> make your disk activity more efficient... Like with IIS, where you can set
> it to only log when its got 'x' bytes to write to disk. I do that right
> now using a piped log, but it might be more efficient if it was done in
> the server.
-DBUFFERED_LOGS
Dean
Re: newbie thread/process model question in hybrid server
Posted by Tani Hosokawa <un...@riverstyx.net>.
On Fri, 9 Jul 1999, Vincent Janelle wrote:
> Also, some systems limit the max number of FDS per process to a tiny
> amount, and this doesn't get changed with a threaded process. The
> entire webserver would only be able to handle up to `uname -n` open
> files across the system. This means read(), etc.. The forked off
> processes would handle that AFAIK.
>
> I still like the idea of a logger process though. Oh well. It would
> handle the opening of all the logs, etc.. It could also make it
> possible to do remote logging?
>
> I think I've been talking to the fhttpd author too much =)
It would also let you consolidate all your log writing into one burst to
make your disk activity more efficient... Like with IIS, where you can set
it to only log when its got 'x' bytes to write to disk. I do that right
now using a piped log, but it might be more efficient if it was done in
the server.
---
tani hosokawa
river styx internet
Re: newbie thread/process model question in hybrid server
Posted by Vincent Janelle <vj...@home.com>.
Also, some systems limit the max number of FDS per process to a tiny
amount, and this doesn't get changed with a threaded process. The
entire webserver would only be able to handle up to `uname -n` open
files across the system. This means read(), etc.. The forked off
processes would handle that AFAIK.
I still like the idea of a logger process though. Oh well. It would
handle the opening of all the logs, etc.. It could also make it
possible to do remote logging?
I think I've been talking to the fhttpd author too much =)
Manoj Kasichainula wrote:
>
> On Sat, Jul 10, 1999 at 03:37:33AM +1000, Brian Havard wrote:
> > Why is hybrid more scalable than purely threaded (with proper kernel
> > threads)? What advantage is there in dividing the threads between multiple
> > processes?
>
> Many (most?) systems limit the number of threads per process. In a
> thread-per-request model (which the hybrid server uses), if you want
> to handle 2000 concurrent requests but your threads/process = 512, you
> have to have multiple processes to handle the load.
>
> --
> Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
> "Life is like an analogy." - Aaron Allston
--
------------
If life is merely a joke, the question still remains: for whose
amusement?
--http://random.gimp.org --mailto:random@gimp.org --UIN 23939474
Re: newbie thread/process model question in hybrid server
Posted by Manoj Kasichainula <ma...@io.com>.
On Sat, Jul 10, 1999 at 03:37:33AM +1000, Brian Havard wrote:
> Why is hybrid more scalable than purely threaded (with proper kernel
> threads)? What advantage is there in dividing the threads between multiple
> processes?
Many (most?) systems limit the number of threads per process. In a
thread-per-request model (which the hybrid server uses), if you want
to handle 2000 concurrent requests but your threads/process = 512, you
have to have multiple processes to handle the load.
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"Life is like an analogy." - Aaron Allston
Re: newbie thread/process model question in hybrid server
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> >But how do you know? If you can't be sure that no memory corruption has
> >taken place, then continuing is completely invalid, as far as I am
> >concerned.
>
> Can you ever be sure your memory isn't corrupted? Not all corruption causes a
> segfault.
I suppose, but a seg fault is a pretty good clue that someone wrote
somewhere in memory that they shouldn't have.
Not that I really care, I don't use OS/2, I'd just hate to see this sort
of approach in any production server I run.
-Rasmus
Re: newbie thread/process model question in hybrid server
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sun, 11 Jul 1999 10:03:46 -0400 (Eastern Daylight Time), Rasmus Lerdorf
wrote:
>> Maybe, maybe not. If the segfault is just an accidental NULL dereference then
>> no damage is done.
>>
>> The problem is that if the shared memory space is the entire server, in the
>> case of single process / multithread, you lose all active connections. Even
>> in hybrid mode you lose a large number. If there's a chance to recover by
>> just killing the thread you may as well try.
>
>But how do you know? If you can't be sure that no memory corruption has
>taken place, then continuing is completely invalid, as far as I am
>concerned.
Can you ever be sure your memory isn't corrupted? Not all corruption causes a
segfault.
>For all you know someone used a buffer overrun to insert a
>hack and on each subsequent request your server will email your password
>file to the world. Ok, an extreme and unlikely case, especially on OS/2,
>but I think the point still holds.
An instruction that segfaults doesn't complete so it gives the hacker no
advantage. He just has to reduce the number of bytes written until it fits in
valid memory so it doesn't segfault and it works again.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: newbie thread/process model question in hybrid server
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> Maybe, maybe not. If the segfault is just an accidental NULL dereference then
> no damage is done.
>
> The problem is that if the shared memory space is the entire server, in the
> case of single process / multithread, you lose all active connections. Even
> in hybrid mode you lose a large number. If there's a chance to recover by
> just killing the thread you may as well try.
But how do you know? If you can't be sure that no memory corruption has
taken place, then continuing is completely invalid, as far as I am
concerned. For all you know someone used a buffer overrun to insert a
hack and on each subsequent request your server will email your password
file to the world. Ok, an extreme and unlikely case, especially on OS/2,
but I think the point still holds.
-Rasmus
Re: newbie thread/process model question in hybrid server
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sun, 11 Jul 1999 00:22:02 -0700 (PDT), Tani Hosokawa wrote:
>On Sun, 11 Jul 1999, Brian Havard wrote:
>> If a child's pool could be cleaned up after a segfault, is there much chance
>> of it working if the above occurs?
>
>If you've just had a segfault, I think it'd be far safer to just toss the
>entire shared memory space (and the process along with it) rather than
>hope that everything will be "OK enough" to proceed. I mean, really... if
>somethings gone that awry in the process, chances are its tainted
>*something* that'll come back and bite you a couple requests down the
>line...
Maybe, maybe not. If the segfault is just an accidental NULL dereference then
no damage is done.
The problem is that if the shared memory space is the entire server, in the
case of single process / multithread, you lose all active connections. Even
in hybrid mode you lose a large number. If there's a chance to recover by
just killing the thread you may as well try.
My problem is that the only way to run multiple processes is to fork() and
doing so is extremely inefficient in OS/2 as it's not supported by the
kernel, it's kluged by the C library for unix compatibility. In the current
preforked model each server process consumes over 600k of memory because of
this. With the spmt mpm I'm working on it uses around 1MB plus 20k per (idle)
thread and performance is also up.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: newbie thread/process model question in hybrid server
Posted by Tani Hosokawa <un...@riverstyx.net>.
On Sun, 11 Jul 1999, Brian Havard wrote:
> >>>A segfault won't take out 100% of your server's capacity,
> >>>for one thing.
> >BH> Yeah, fair point but this isn't a problem on OS/2 where I can trap segfaults
> >BH> (and other fatal errors like div 0) and just kill the offending thread.
> >
> >Not when this "offending thread" already destroyed important structures :-))
> >Common address space is common address space...
>
> Hmmm, good point. How prone are pools to corruption if some code writes past
> the end of its allocated space (the most common cause of heap corruption)?
>
> If a child's pool could be cleaned up after a segfault, is there much chance
> of it working if the above occurs?
If you've just had a segfault, I think it'd be far safer to just toss the
entire shared memory space (and the process along with it) rather than
hope that everything will be "OK enough" to proceed. I mean, really... if
somethings gone that awry in the process, chances are its tainted
*something* that'll come back and bite you a couple requests down the
line...
My two bits.
---
tani hosokawa
river styx internet
Re: newbie thread/process model question in hybrid server
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Sat, 10 Jul 1999 13:00:21 +0400 (MSD), Khimenko Victor wrote:
>10-Jul-99 14:39 you wrote:
>BH> On Fri, 09 Jul 1999 14:07:40 -0400, Rodent of Unusual Size wrote:
>
>>>Brian Havard wrote:
>>>>
>>>> Why is hybrid more scalable than purely threaded (with proper kernel
>>>> threads)? What advantage is there in dividing the threads between multiple
>>>> processes?
>>>
>>>A segfault won't take out 100% of your server's capacity,
>>>for one thing.
>
>BH> Yeah, fair point but this isn't a problem on OS/2 where I can trap segfaults
>BH> (and other fatal errors like div 0) and just kill the offending thread.
>
>Not when this "offending thread" already destroyed important structures :-))
>Common address space is common address space...
Hmmm, good point. How prone are pools to corruption if some code writes past
the end of its allocated space (the most common cause of heap corruption)?
If a child's pool could be cleaned up after a segfault, is there much chance
of it working if the above occurs?
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: newbie thread/process model question in hybrid server
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
I have spoken to MANY people about this in the last few days. There are
now two platforms I know of which can handle a seg fault within a thread.
They are MVS and AS/400. It is possible for OS/2 to catch a sigsegv, it
is also possible for UNIX to do this. I have spoken to two different OS/2
programmers, who agree that catching a sigsegv and treating it as if it
never happened is not a good idea. There is no garauntee that the thread
that caused the sigsegv will be the one to get the signal. IMHO, this is
a bad idea, and it should be re-considered.
Ryan
On Sat, 10 Jul 1999, Khimenko Victor wrote:
> 10-Jul-99 14:39 you wrote:
> BH> On Fri, 09 Jul 1999 14:07:40 -0400, Rodent of Unusual Size wrote:
>
> >>Brian Havard wrote:
> >>>
> >>> Why is hybrid more scalable than purely threaded (with proper kernel
> >>> threads)? What advantage is there in dividing the threads between multiple
> >>> processes?
> >>
> >>A segfault won't take out 100% of your server's capacity,
> >>for one thing.
>
> BH> Yeah, fair point but this isn't a problem on OS/2 where I can trap segfaults
> BH> (and other fatal errors like div 0) and just kill the offending thread.
>
> Not when this "offending thread" already destroyed important structures :-))
> Common address space is common address space...
>
>
>
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: newbie thread/process model question in hybrid server
Posted by Khimenko Victor <ap...@khim.sch57.msk.ru>.
10-Jul-99 14:39 you wrote:
BH> On Fri, 09 Jul 1999 14:07:40 -0400, Rodent of Unusual Size wrote:
>>Brian Havard wrote:
>>>
>>> Why is hybrid more scalable than purely threaded (with proper kernel
>>> threads)? What advantage is there in dividing the threads between multiple
>>> processes?
>>
>>A segfault won't take out 100% of your server's capacity,
>>for one thing.
BH> Yeah, fair point but this isn't a problem on OS/2 where I can trap segfaults
BH> (and other fatal errors like div 0) and just kill the offending thread.
Not when this "offending thread" already destroyed important structures :-))
Common address space is common address space...
Re: newbie thread/process model question in hybrid server
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > Well, I can see that the hybrid model makes sense on some platforms but I
> > don't believe OS/2 is one of them so I'll continue working on my single
> > process/multi-thread OS/2 mpm. This model may also be suitable for other
> > platforms like BeOS or Win32.
>
> You know I'm starting to agree with you on unix systems which have kernel
> threads, it's looking more and more complex to support multiple process
> hybrid models.
Yes, it is complex to support a hybrid server. But it is also MUCH more
reliable than a purely threaded model. Unless, that is, we want to get
rid of third-party modules. We take the risk that a third-party module is
going to do something it shouldn't, and seg-fault the server process, and
take it down. We should not be catching SIGSEGV on any system where
threads cannot reliably catch their own signals (e.g. UNIX, Windows). If
we get a sigsegv, we should just be dying and allowing our parent to bring
back anothr child process.
Ryan
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: newbie thread/process model question in hybrid server
Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 10 Jul 1999, Brian Havard wrote:
> Well, I can see that the hybrid model makes sense on some platforms but I
> don't believe OS/2 is one of them so I'll continue working on my single
> process/multi-thread OS/2 mpm. This model may also be suitable for other
> platforms like BeOS or Win32.
You know I'm starting to agree with you on unix systems which have kernel
threads, it's looking more and more complex to support multiple process
hybrid models.
Dean
Re: newbie thread/process model question in hybrid server
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Fri, 09 Jul 1999 14:07:40 -0400, Rodent of Unusual Size wrote:
>Brian Havard wrote:
>>
>> Why is hybrid more scalable than purely threaded (with proper kernel
>> threads)? What advantage is there in dividing the threads between multiple
>> processes?
>
>A segfault won't take out 100% of your server's capacity,
>for one thing.
Yeah, fair point but this isn't a problem on OS/2 where I can trap segfaults
(and other fatal errors like div 0) and just kill the offending thread.
On Fri, 9 Jul 1999 13:14:24 -0500, Manoj Kasichainula wrote:
>Many (most?) systems limit the number of threads per process. In a
>thread-per-request model (which the hybrid server uses), if you want
>to handle 2000 concurrent requests but your threads/process = 512, you
>have to have multiple processes to handle the load.
Ok. Also not applicable to OS/2 which has no thread per process limit other
than the system limit which is user configurable (though needs a reboot to
change it).
On Fri, 09 Jul 1999 12:01:46 -0700, Vincent Janelle wrote:
>Also, some systems limit the max number of FDS per process to a tiny
>amount, and this doesn't get changed with a threaded process. The
>entire webserver would only be able to handle up to `uname -n` open
>files across the system. This means read(), etc.. The forked off
>processes would handle that AFAIK.
Ditto for file handles as for threads. Actually, OS/2 does impose a limit but
this can be set to any value (up to the system limit) by a single API call.
Well, I can see that the hybrid model makes sense on some platforms but I
don't believe OS/2 is one of them so I'll continue working on my single
process/multi-thread OS/2 mpm. This model may also be suitable for other
platforms like BeOS or Win32.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: newbie thread/process model question in hybrid server
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Brian Havard wrote:
>
> Why is hybrid more scalable than purely threaded (with proper kernel
> threads)? What advantage is there in dividing the threads between multiple
> processes?
A segfault won't take out 100% of your server's capacity,
for one thing.
--
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: newbie thread/process model question in hybrid server
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 6 Jul 1999 07:52:09 -0400 (EDT), Ryan Bloom wrote:
>Wow. That's the big advantage of the hybrid server. It also looks like
>the hybrid approach is MUCH more scalable than either process or thread
>based. At least it is on any of the platforms we have looked at.
Why is hybrid more scalable than purely threaded (with proper kernel
threads)? What advantage is there in dividing the threads between multiple
processes?
>> Because of this I suspect that I can do a purely threaded approach and will
>> start doing an MPM for it once I figure out how to do that :)
Well I'm happy to say that I've actually got it working :)
It's pretty rough at the moment but I've successfully had it serving static
pages. I'll commit it some time soon so if anyone wants to they can take a
look and point out the huge errors I'm sure are there.....
I did hit one problem that may affect other platforms. In
http_protocol.c:ap_send_fd_length() it does:
while ((n = read(fd, buf, o)) < 1 &&
(errno == EINTR || errno == EAGAIN) &&
!ap_is_aborted(r->connection))
continue;
This would sometimes result in an endless loop as read() returns 0 on EOF
without changing errno. If there had been a previous EAGAIN or EINTR it loops
forever. Changing the 1 to a 0 fixes it, which I'll commit if nobody objects.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: newbie thread/process model question in hybrid server
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Wow. That's the big advantage of the hybrid server. It also looks like
the hybrid approach is MUCH more scalable than either process or thread
based. At least it is on any of the platforms we have looked at.
Ryan
On Tue, 6 Jul 1999, Brian Havard wrote:
> On Tue, 6 Jul 1999 07:08:30 -0400 (EDT), Ryan Bloom wrote:
>
> >Actually, the argument for a hybrid approach has nothing to do with memory
> >leak. That is the argument for a static number of threads. The argument
> >for a hybrid server, is reliability. Threads go down, just like processes
> >do, but when a thread goes down, so do the rest of the threads in the
> >process. I have yet to see an OS that can recover a process when one of
> >it's threads dies unexpectedly.
>
> OS/2 can (I wrote a test program to prove it actually works too). Is this the
> only benefit of the hybrid approach? In OS/2 I can trap segfaults (and any
> other kind of fatal error) in an exception handler which can simply terminate
> the thread, possibly after doing some cleanup. It can also detect reentry
> into the exception handler so that if the cleanup segfaults it doesn't end up
> in an endless loop.
>
> Because of this I suspect that I can do a purely threaded approach and will
> start doing an MPM for it once I figure out how to do that :)
>
> --
> ______________________________________________________________________________
> | Brian Havard | "He is not the messiah! |
> | brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
> ------------------------------------------------------------------------------
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: newbie thread/process model question in hybrid server
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Tue, 6 Jul 1999 07:08:30 -0400 (EDT), Ryan Bloom wrote:
>Actually, the argument for a hybrid approach has nothing to do with memory
>leak. That is the argument for a static number of threads. The argument
>for a hybrid server, is reliability. Threads go down, just like processes
>do, but when a thread goes down, so do the rest of the threads in the
>process. I have yet to see an OS that can recover a process when one of
>it's threads dies unexpectedly.
OS/2 can (I wrote a test program to prove it actually works too). Is this the
only benefit of the hybrid approach? In OS/2 I can trap segfaults (and any
other kind of fatal error) in an exception handler which can simply terminate
the thread, possibly after doing some cleanup. It can also detect reentry
into the exception handler so that if the cleanup segfaults it doesn't end up
in an endless loop.
Because of this I suspect that I can do a purely threaded approach and will
start doing an MPM for it once I figure out how to do that :)
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: newbie thread/process model question in hybrid server
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Actually, the argument for a hybrid approach has nothing to do with memory
leak. That is the argument for a static number of threads. The argument
for a hybrid server, is reliability. Threads go down, just like processes
do, but when a thread goes down, so do the rest of the threads in the
process. I have yet to see an OS that can recover a process when one of
it's threads dies unexpectedly. If we write a purely threaded server, we
take the chance of having a 3rd party module that seg faults on every
1000th request, taking down the entire server. With a hybrid approach,
that isn't possible, if we have the same faulty module, we only lose 1/n
requests, where n is the number of processes.
Ryan
On Mon, 5 Jul 1999, Thorsten von Eicken wrote:
> Thanks for clarifying the current hybrid approach. I guess the fact that
> many thread libs leak memory is a good argument for keeping a hybrid
> approach as opposed to having the alternative between a pure multiprocess
> approach and a pure multithreaded approach: restart those processes from
> time to time as they get too big...
> Thanks,
> Thorsten
>
>
>
> At 10:56 AM 7/5/99 -0400, you wrote:
> >yOn Sat, 3 Jul 1999, Thorsten von Eicken wrote:
> >
> > > I've been reading 2.0/mpm for a couple of days and am still a bit puzzled
> > > by the hybrid server's strategy of using processes and threads. More
> > > precisely, I don't understand why the number of threads per process is
> > > constant and the number of processes varies with load.
> >
> >The reasoning behind this is largely historical. It was decided to use a
> >variable number of processes, and a fixed number of threads, because it
> >was easier to code, and this was a first draft/prototype. We also looked
> >at some previous implementations of similar code that tried to grow the
> >thread pool, and most pthread libraries have memory leaks. When a thread
> >is destroyed, either by itself, or by another thread, it almost always
> >leaves some memory around, and this can get quite large in time. We were
> >going for a proof of concept, and proff that a hybrid Apache was more
> >scalable.
> >
> >This also would have required a very different scheme for controlling
> >threads/processes. The parent process really couldn't determine when to
> >tell a process to create a new thread in the current communication model.
> >Dean is trying to solve this problem, but it isn't a problem we wanted to
> >tackle in the first implementation. We wanted to keep the basic
> >architecture for Apache the same.
> >
> >Ryan
> >
> > >
> > > From a parallel computing background I would have done the opposite. I
> > > would have expected to set the number of processes to approx the number of
> > > processors in the system, and then used the threads to basically multiplex
> > > one processor. Ideally some affinity between processes and processors
> > could
> > > be set-up to improve cache behavior. Thus the threads are used to keep
> > > track of the state for the N requests each process has up in the air at a
> > > given time and the processes are used to get parallelism across the
> > > processors of a multiprocessor machine.
> > >
> > > Can a kind soul explain to me how to think about the approach taken in the
> > > hybrid server?
> > >
> > > Thanks,
> > > Thorsten von Eicken
> > >
> > > ~~~~~
> > > Thorsten von Eicken
> > > expertcity.com Phone: (805) 964-0383 x313
> > > 5385 Hollister Ave #111 Fax: (805) 964-6103
> > > Santa Barbara, CA 93111 Cell: (805) 403-0982
> > >
> >
> >_______________________________________________________________________
> >Ryan Bloom rbb@raleigh.ibm.com
> >4205 S Miami Blvd
> >RTP, NC 27709 It's a beautiful sight to see good dancers
> > doing simple steps. It's a painful sight to
> > see beginners doing complicated patterns.
>
> ~~~~~
> Thorsten von Eicken
> expertcity.com Phone: (805) 964-0383 x313
> 5385 Hollister Ave #111 Fax: (805) 964-6103
> Santa Barbara, CA 93111 Cell: (805) 403-0982
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: newbie thread/process model question in hybrid server
Posted by Thorsten von Eicken <tv...@expertcity.com>.
Thanks for clarifying the current hybrid approach. I guess the fact that
many thread libs leak memory is a good argument for keeping a hybrid
approach as opposed to having the alternative between a pure multiprocess
approach and a pure multithreaded approach: restart those processes from
time to time as they get too big...
Thanks,
Thorsten
At 10:56 AM 7/5/99 -0400, you wrote:
>yOn Sat, 3 Jul 1999, Thorsten von Eicken wrote:
>
> > I've been reading 2.0/mpm for a couple of days and am still a bit puzzled
> > by the hybrid server's strategy of using processes and threads. More
> > precisely, I don't understand why the number of threads per process is
> > constant and the number of processes varies with load.
>
>The reasoning behind this is largely historical. It was decided to use a
>variable number of processes, and a fixed number of threads, because it
>was easier to code, and this was a first draft/prototype. We also looked
>at some previous implementations of similar code that tried to grow the
>thread pool, and most pthread libraries have memory leaks. When a thread
>is destroyed, either by itself, or by another thread, it almost always
>leaves some memory around, and this can get quite large in time. We were
>going for a proof of concept, and proff that a hybrid Apache was more
>scalable.
>
>This also would have required a very different scheme for controlling
>threads/processes. The parent process really couldn't determine when to
>tell a process to create a new thread in the current communication model.
>Dean is trying to solve this problem, but it isn't a problem we wanted to
>tackle in the first implementation. We wanted to keep the basic
>architecture for Apache the same.
>
>Ryan
>
> >
> > From a parallel computing background I would have done the opposite. I
> > would have expected to set the number of processes to approx the number of
> > processors in the system, and then used the threads to basically multiplex
> > one processor. Ideally some affinity between processes and processors
> could
> > be set-up to improve cache behavior. Thus the threads are used to keep
> > track of the state for the N requests each process has up in the air at a
> > given time and the processes are used to get parallelism across the
> > processors of a multiprocessor machine.
> >
> > Can a kind soul explain to me how to think about the approach taken in the
> > hybrid server?
> >
> > Thanks,
> > Thorsten von Eicken
> >
> > ~~~~~
> > Thorsten von Eicken
> > expertcity.com Phone: (805) 964-0383 x313
> > 5385 Hollister Ave #111 Fax: (805) 964-6103
> > Santa Barbara, CA 93111 Cell: (805) 403-0982
> >
>
>_______________________________________________________________________
>Ryan Bloom rbb@raleigh.ibm.com
>4205 S Miami Blvd
>RTP, NC 27709 It's a beautiful sight to see good dancers
> doing simple steps. It's a painful sight to
> see beginners doing complicated patterns.
~~~~~
Thorsten von Eicken
expertcity.com Phone: (805) 964-0383 x313
5385 Hollister Ave #111 Fax: (805) 964-6103
Santa Barbara, CA 93111 Cell: (805) 403-0982
Re: newbie thread/process model question in hybrid server
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
yOn Sat, 3 Jul 1999, Thorsten von Eicken wrote:
> I've been reading 2.0/mpm for a couple of days and am still a bit puzzled
> by the hybrid server's strategy of using processes and threads. More
> precisely, I don't understand why the number of threads per process is
> constant and the number of processes varies with load.
The reasoning behind this is largely historical. It was decided to use a
variable number of processes, and a fixed number of threads, because it
was easier to code, and this was a first draft/prototype. We also looked
at some previous implementations of similar code that tried to grow the
thread pool, and most pthread libraries have memory leaks. When a thread
is destroyed, either by itself, or by another thread, it almost always
leaves some memory around, and this can get quite large in time. We were
going for a proof of concept, and proff that a hybrid Apache was more
scalable.
This also would have required a very different scheme for controlling
threads/processes. The parent process really couldn't determine when to
tell a process to create a new thread in the current communication model.
Dean is trying to solve this problem, but it isn't a problem we wanted to
tackle in the first implementation. We wanted to keep the basic
architecture for Apache the same.
Ryan
>
> From a parallel computing background I would have done the opposite. I
> would have expected to set the number of processes to approx the number of
> processors in the system, and then used the threads to basically multiplex
> one processor. Ideally some affinity between processes and processors could
> be set-up to improve cache behavior. Thus the threads are used to keep
> track of the state for the N requests each process has up in the air at a
> given time and the processes are used to get parallelism across the
> processors of a multiprocessor machine.
>
> Can a kind soul explain to me how to think about the approach taken in the
> hybrid server?
>
> Thanks,
> Thorsten von Eicken
>
> ~~~~~
> Thorsten von Eicken
> expertcity.com Phone: (805) 964-0383 x313
> 5385 Hollister Ave #111 Fax: (805) 964-6103
> Santa Barbara, CA 93111 Cell: (805) 403-0982
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.
Re: newbie thread/process model question in hybrid server
Posted by Dean Gaudet <dg...@arctic.org>.
Actually I think I've said the same thing to manoj... I'm planning to use
a fixed number of processes and a varying number of threads in the model
I'm working on.
Dean
On Sat, 3 Jul 1999, Thorsten von Eicken wrote:
> I've been reading 2.0/mpm for a couple of days and am still a bit puzzled
> by the hybrid server's strategy of using processes and threads. More
> precisely, I don't understand why the number of threads per process is
> constant and the number of processes varies with load.
>
> From a parallel computing background I would have done the opposite. I
> would have expected to set the number of processes to approx the number of
> processors in the system, and then used the threads to basically multiplex
> one processor. Ideally some affinity between processes and processors could
> be set-up to improve cache behavior. Thus the threads are used to keep
> track of the state for the N requests each process has up in the air at a
> given time and the processes are used to get parallelism across the
> processors of a multiprocessor machine.
>
> Can a kind soul explain to me how to think about the approach taken in the
> hybrid server?
>
> Thanks,
> Thorsten von Eicken
>
> ~~~~~
> Thorsten von Eicken
> expertcity.com Phone: (805) 964-0383 x313
> 5385 Hollister Ave #111 Fax: (805) 964-6103
> Santa Barbara, CA 93111 Cell: (805) 403-0982
>
>
newbie thread/process model question in hybrid server
Posted by Thorsten von Eicken <tv...@expertcity.com>.
I've been reading 2.0/mpm for a couple of days and am still a bit puzzled
by the hybrid server's strategy of using processes and threads. More
precisely, I don't understand why the number of threads per process is
constant and the number of processes varies with load.
From a parallel computing background I would have done the opposite. I
would have expected to set the number of processes to approx the number of
processors in the system, and then used the threads to basically multiplex
one processor. Ideally some affinity between processes and processors could
be set-up to improve cache behavior. Thus the threads are used to keep
track of the state for the N requests each process has up in the air at a
given time and the processes are used to get parallelism across the
processors of a multiprocessor machine.
Can a kind soul explain to me how to think about the approach taken in the
hybrid server?
Thanks,
Thorsten von Eicken
~~~~~
Thorsten von Eicken
expertcity.com Phone: (805) 964-0383 x313
5385 Hollister Ave #111 Fax: (805) 964-6103
Santa Barbara, CA 93111 Cell: (805) 403-0982
Re: thanks for the explanations
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Jun 25, 1999 at 10:11:14PM +0200, Laurent Sinitambirivoutin wrote:
> indeed I run Linux 2.2.5
> Still, the nspr version runs with only 7 processes (created at launch)
> whatever the load.
Probably because the NSPR inside apache-nspr uses user-level threads.
> And if I've read the httpd.conf correctly, 8 clients with 8 threads each
> should get me 64 entries in ps, not 81 ... Tricky tricky
There's other overhead as well.
1 parent process
1 thread per process for waiting on signals
1 monitor thread per process, created by LinuxThreads
--
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"'Why do you blow on people?' I don't know." -- Benny Hinn
Re: thanks for the explanations
Posted by Laurent Sinitambirivoutin <du...@eurosport.com>.
Ryan Bloom wrote:
>
> If you are running on Linux, threads and processes are both reported in
> ps. In fact, most tools report both threads and processes on Linux. If
> you are on a different OS, then there is a problem, that we will need to
> look into.
indeed I run Linux 2.2.5
Still, the nspr version runs with only 7 processes (created at launch)
whatever the load.
And if I've read the httpd.conf correctly, 8 clients with 8 threads each
should get me 64 entries in ps, not 81 ... Tricky tricky
--
Laurent.D.Sinitambirivoutin
Root of Eurosport Website
duredhel@eurosport.com
Get all about sport on http://www.eurosport.com !
Re: thanks for the explanations
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
If you are running on Linux, threads and processes are both reported in
ps. In fact, most tools report both threads and processes on Linux. If
you are on a different OS, then there is a problem, that we will need to
look into.
The APR stuff should be ignored. It is on-going work, and it is not
currently integrated into the server. It is just hanging off that
repository for now. When it is done, the Apache server will use it, and
it will all be a part of building Apache.
Ryan
On Fri, 25 Jun 1999, Laurent Sinitambirivoutin wrote:
> thanks for the explanations
>
> i've run the hybrid server, it works fine, but still a lot of processes,
> though a lot less than my actual server (81 processes instead of more
> than 200 :)
> Still I thought I wouldn't have more than 8 processes since MaxClients
> is set to 8... So I'm a little bit confused. In fact, I've set
> ThreadsPerChild to 32 instead of 8 and woee I got my 256 processes... So
> I guess I must have missed something though ldd shows that httpd is
> linked with pthreads
>
> as for the apr stuff, i've compiled it and now i'm feeling dumb about it
> : got lots of libs but don't have a clue about how it's supposed to get
> along with apache (unless of course i'm so stupid i didn't realise i had
> to code the stuff myself ;-)
>
> --
> Laurent.D.Sinitambirivoutin
> Root of Eurosport Website
> duredhel@eurosport.com
> Get all about sport on http://www.eurosport.com !
>
_______________________________________________________________________
Ryan Bloom rbb@raleigh.ibm.com
4205 S Miami Blvd
RTP, NC 27709 It's a beautiful sight to see good dancers
doing simple steps. It's a painful sight to
see beginners doing complicated patterns.