You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/12/10 13:59:25 UTC
SYSV Semaphores.
How many platforms are using SYSV Semaphores in 2.0? I seem to think that
a great deal of platforms are, which is probably pretty bad. 1.3 almost
never uses SYSV Semaphores, and we probably want to do the same thing.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SYSV Semaphores.
Posted by Bill Stoddard <bi...@wstoddard.com>.
> "Victor J. Orlikowski" wrote:
> >
> > Ryan,
> >
> > I'm looking into the use of SysV sems, for performance reasons. The
> > reason we shut down on using them in 1.3 was the possibility of a
> > denial-of-service using CGIs. However, after bothering Dean about it
> > when he suggested their use on Linux, it appears that there are a
> > couple of other ways to perform a denial of service using CGIs and the
> > other locking methods, so the sems didn't look so bad, considering the
> > performance boost they gave over flock. However, some measures seem to
> > give conflicting results about the performance gain, so I am doing my
> > own measurements now.
>
> Hmmm ... don't remember that, but if that's the only reason, I say we
> have a HOSTILE_CGI compilation mode to avoid them, coz it isn't usually
> something we need to guard against.
>
> Roll on a decent secure OS!
>
First posts on this mailing list in Aug. 97. Roy posted some performance testing results (Nov. 97)
on Solaris that indicate SYSVSEMs perform MUCH better with large numbers of concurrent clients than
does fcntl. fcntl doesn't scale well on AIX either, which is why Victor changed to using
PTHREAD_SERIALIZED_ACCEPT in the 1.3.14 timeframe. That change made a huge performance difference
when running 1000's of processes on a 16 way AIX machines we were playing with.
There were three issues raised with Roy's results:
1. DoS attack by CGIs (raised by Dean, see referenced posts). I think this is really not an issue
now.
2. Solaris funkyness that prevented MaxClients > 29 (or so) on some machines. I recently tracked
this down to a kernel setting (thanks to some folks at Netegrity). If we use SYSVSEMS on Solaris by
default, will need to doc this good. (probably same issues on other OSes as well)
3. Instability. Roy had one failure in his testing. Not sure what version of the Solaris kernel;
May have been fixed now and may have been related to 2). Wasn't clear at the time.
Bill
Re: SYSV Semaphores.
Posted by Ben Laurie <be...@algroup.co.uk>.
"Victor J. Orlikowski" wrote:
>
> Ryan,
>
> I'm looking into the use of SysV sems, for performance reasons. The
> reason we shut down on using them in 1.3 was the possibility of a
> denial-of-service using CGIs. However, after bothering Dean about it
> when he suggested their use on Linux, it appears that there are a
> couple of other ways to perform a denial of service using CGIs and the
> other locking methods, so the sems didn't look so bad, considering the
> performance boost they gave over flock. However, some measures seem to
> give conflicting results about the performance gain, so I am doing my
> own measurements now.
Hmmm ... don't remember that, but if that's the only reason, I say we
have a HOSTILE_CGI compilation mode to avoid them, coz it isn't usually
something we need to guard against.
Roll on a decent secure OS!
Cheers,
Ben.
Re: SYSV Semaphores.
Posted by Bill Stoddard <bi...@wstoddard.com>.
>
> There is another problem with SysV semaphores that needs to be seriously
> considered. If we kill ourselves off incorrectly, we will keep the
> semaphore. Also, anytime we choose a semaphore as a lock method, that is
> all APR will use. When APR is compiled as a shared library, this means
> every APR program will use semaphores. Since semaphores are usually
> scarce, this is probably a bad idea.
>
Hummm... This would seem to suggest that APR needs another degree of freedom
with regard to selecting accept serialization. fcntl locking is good for
relatively small number of processes contending for the lock, it works most
everywhere and is reliable. It really does suck for serializing 100's of
processes though.
Bill
Re: SYSV Semaphores.
Posted by rb...@covalent.net.
> > Hmmm... We have seen some platforms not removing the semaphores
> > though. I believe on FreeBSD, that if we didn't clean the semaphores,
> > then the kernel wasn't doing it for us.
>
> that sounds like a bug in freebsd then, worth reporting. if you word
> search for "semadj" in the single unix spec you'll see that SEM_UNDO
> cleanup at process exit is part of the standard.
>
> double-check that you're using SEM_UNDO in 2.0... it's definitely there in
> 1.3.
SEM_UNDO is definately there. I'll double check that we are actually
leaking semaphores and report it if we are. Thanks for the info.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SYSV Semaphores.
Posted by dean gaudet <dg...@arctic.org>.
On Sun, 31 Dec 2000 rbb@covalent.net wrote:
>
> > > There is another problem with SysV semaphores that needs to be seriously
> > > considered. If we kill ourselves off incorrectly, we will keep the
> > > semaphore.
> >
> > this is not a problem with sysv semaphores. they are kernel objects.
> > the kernel cleans them up on process exit (assuming SEM_UNDO is set, as we
> > do -- iirc the limitation on solaris is a static number of undo records in
> > the kernel).
> >
> > this is a problem with pthreads mutexes. these are userland objects that
> > the kernel has no record of.
>
> Hmmm... We have seen some platforms not removing the semaphores
> though. I believe on FreeBSD, that if we didn't clean the semaphores,
> then the kernel wasn't doing it for us.
that sounds like a bug in freebsd then, worth reporting. if you word
search for "semadj" in the single unix spec you'll see that SEM_UNDO
cleanup at process exit is part of the standard.
double-check that you're using SEM_UNDO in 2.0... it's definitely there in
1.3.
-dean
Re: SYSV Semaphores.
Posted by rb...@covalent.net.
> > There is another problem with SysV semaphores that needs to be seriously
> > considered. If we kill ourselves off incorrectly, we will keep the
> > semaphore.
>
> this is not a problem with sysv semaphores. they are kernel objects.
> the kernel cleans them up on process exit (assuming SEM_UNDO is set, as we
> do -- iirc the limitation on solaris is a static number of undo records in
> the kernel).
>
> this is a problem with pthreads mutexes. these are userland objects that
> the kernel has no record of.
Hmmm... We have seen some platforms not removing the semaphores
though. I believe on FreeBSD, that if we didn't clean the semaphores,
then the kernel wasn't doing it for us.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SYSV Semaphores.
Posted by dean gaudet <dg...@arctic.org>.
On Mon, 11 Dec 2000 rbb@covalent.net wrote:
> There is another problem with SysV semaphores that needs to be seriously
> considered. If we kill ourselves off incorrectly, we will keep the
> semaphore.
this is not a problem with sysv semaphores. they are kernel objects.
the kernel cleans them up on process exit (assuming SEM_UNDO is set, as we
do -- iirc the limitation on solaris is a static number of undo records in
the kernel).
this is a problem with pthreads mutexes. these are userland objects that
the kernel has no record of.
-dean
Re: SYSV Semaphores.
Posted by rb...@covalent.net.
There is another problem with SysV semaphores that needs to be seriously
considered. If we kill ourselves off incorrectly, we will keep the
semaphore. Also, anytime we choose a semaphore as a lock method, that is
all APR will use. When APR is compiled as a shared library, this means
every APR program will use semaphores. Since semaphores are usually
scarce, this is probably a bad idea.
Ryan
> I'm looking into the use of SysV sems, for performance reasons. The
> reason we shut down on using them in 1.3 was the possibility of a
> denial-of-service using CGIs. However, after bothering Dean about it
> when he suggested their use on Linux, it appears that there are a
> couple of other ways to perform a denial of service using CGIs and the
> other locking methods, so the sems didn't look so bad, considering the
> performance boost they gave over flock. However, some measures seem to
> give conflicting results about the performance gain, so I am doing my
> own measurements now.
>
> Victor
> --
> Victor J. Orlikowski
> ======================
> v.j.orlikowski@gte.net
> vjo@raleigh.ibm.com
> vjo@us.ibm.com
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SYSV Semaphores.
Posted by "Victor J. Orlikowski" <v....@gte.net>.
Ryan,
I'm looking into the use of SysV sems, for performance reasons. The
reason we shut down on using them in 1.3 was the possibility of a
denial-of-service using CGIs. However, after bothering Dean about it
when he suggested their use on Linux, it appears that there are a
couple of other ways to perform a denial of service using CGIs and the
other locking methods, so the sems didn't look so bad, considering the
performance boost they gave over flock. However, some measures seem to
give conflicting results about the performance gain, so I am doing my
own measurements now.
Victor
--
Victor J. Orlikowski
======================
v.j.orlikowski@gte.net
vjo@raleigh.ibm.com
vjo@us.ibm.com
Re: SYSV Semaphores.
Posted by rb...@covalent.net.
> > How many platforms are using SYSV Semaphores in 2.0? I seem to think that
> > a great deal of platforms are, which is probably pretty bad. 1.3 almost
> > never uses SYSV Semaphores, and we probably want to do the same
> > thing.
>
> We've only had a way to choose this for a week or so, and OS/390 is
> the only platform for which we select SysV sems currently. As far as
> autodetection goes, it is hard to believe that SysV sems would be
> selected anywhere.
That's what I wanted to know. Cool.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: SYSV Semaphores.
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> How many platforms are using SYSV Semaphores in 2.0? I seem to think that
> a great deal of platforms are, which is probably pretty bad. 1.3 almost
> never uses SYSV Semaphores, and we probably want to do the same
> thing.
We've only had a way to choose this for a week or so, and OS/390 is
the only platform for which we select SysV sems currently. As far as
autodetection goes, it is hard to believe that SysV sems would be
selected anywhere.
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...