You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/11/28 17:27:33 UTC
Re: flock() question (fwd)
FYI, if using a FreeBSD box of recent 2.2 vintage and you don't need
accept locking to handle multiple Listen statements, you may (or may not)
get better performance with many children using SAFE_UNSERIALIZED_ACCEPT.
This is because for each accept() only one child is woken up, but whenever
a process fights for a flock(), they all wake up.
---------- Forwarded message ----------
Date: Fri, 28 Nov 1997 03:07:25 -0800
From: David Greenman <dg...@root.com>
To: Marc Slemko <ma...@znep.com>
Cc: Charles Mott <cm...@srv.net>, hackers@FreeBSD.ORG
Subject: Re: flock() question
>Hmm. It looks like if you have multiple processes blocked on the
>same lock in FreeBSD (well, 2.2 anyway), they are all woken up when
>the lock is freed. Yes, only one will get the lock but they will
>all be woken. Unless I am reading the code wrong... This is in
>contrast to multiple processes blocking in accept(), where only
>one will be woken up.
The optimized wakeup case for accept() is that way because I optimized
it. :-) You're probably right about flock(), but I haven't gotten around to
looking at that and other potential wakeup optimizations. Changes like that
have to be made with great care...what seems obvious often doesn't turn out
that way. :-)
-DG
David Greenman
Core-team/Principal Architect, The FreeBSD Project
Re: flock() question (fwd)
Posted by Rob Hartill <ro...@imdb.com>.
On Sun, 30 Nov 1997, Random Junk wrote:
> Dean Gaudet writes:
> > +1 on SAFE_UNSERIALIZED_ACCEPT for freebsd 2.2+ then.
>
> i'm running freebsd 2.2.5/apache 1.2.4 and apache is getting stuck on
> a regular basis (i have a kill -HUP on an hourly cron to keep it
> happy). the web traffic on that machine is extremely high (30
> connections/sec pretty much continuously, maybe even more now due to
> thanksgiving vacation). top/vmstat shows a good amount of free ram
> and no swapping.
is this on your mod_perl server or a vanilla Apache ? What cpu/memory ?
What are your min/max type settings ?, and what's you keepalive
settings ?
"stuck" could just mean you're waiting for lots of things to timeout.
--
Rob Hartill Internet Movie Database (Ltd)
http://www.moviedatabase.com/ .. a site for sore eyes.
Re: flock() question (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
Do you have multiple Listen directives? If so, you need accept locking.
Only trick is that USE_FLOCK_SERIALIZED_ACCEPT is broken in 1.2. You
could try USE_FCNTL_SERIALIZED_ACCEPT instead; ie. replace the FLOCK in
the FreeBSD section of conf.h with FCNTL.
SAFE_UNSERIALIZED_ACCEPT won't do anything for 1.2.
On Sun, 30 Nov 1997, Random Junk wrote:
> Dean Gaudet writes:
> > +1 on SAFE_UNSERIALIZED_ACCEPT for freebsd 2.2+ then.
>
> i'm running freebsd 2.2.5/apache 1.2.4 and apache is getting stuck on
> a regular basis (i have a kill -HUP on an hourly cron to keep it
> happy). the web traffic on that machine is extremely high (30
> connections/sec pretty much continuously, maybe even more now due to
> thanksgiving vacation). top/vmstat shows a good amount of free ram
> and no swapping.
>
> will SAFE_UNSERIALIZED_ACCEPT help?
>
> could it also have anything to do with the listen queue on the
> machine? (somaxconn is at 128).
>
> i will experiment with both of those but i'd like to know as much as
> possible about potential impact before just blindly mucking about.
>
> --
> Jon Drukman jsd@gamespot.com SpotMedia Communications
> This calls for a very special blend of psychology and extreme violence.
>
Re: flock() question (fwd)
Posted by Random Junk <js...@gamespot.com>.
Dean Gaudet writes:
> +1 on SAFE_UNSERIALIZED_ACCEPT for freebsd 2.2+ then.
i'm running freebsd 2.2.5/apache 1.2.4 and apache is getting stuck on
a regular basis (i have a kill -HUP on an hourly cron to keep it
happy). the web traffic on that machine is extremely high (30
connections/sec pretty much continuously, maybe even more now due to
thanksgiving vacation). top/vmstat shows a good amount of free ram
and no swapping.
will SAFE_UNSERIALIZED_ACCEPT help?
could it also have anything to do with the listen queue on the
machine? (somaxconn is at 128).
i will experiment with both of those but i'd like to know as much as
possible about potential impact before just blindly mucking about.
--
Jon Drukman jsd@gamespot.com SpotMedia Communications
This calls for a very special blend of psychology and extreme violence.
Re: flock() question (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
+1 for SAFE_UNSERIALIZED_ACCEPT for all FreeBSD.
Don't think it is worth the hassle of seperating out 2.2. And 2.2.0
doesn't do the wakeup_one on accept(), only 2.20stable as of some time.
On Fri, 28 Nov 1997, Dean Gaudet wrote:
> On Fri, 28 Nov 1997, Marc Slemko wrote:
>
> > "if using a FreeBSD box of recent 2.2 vintage and you don't need accept
> > locking because you aren't using multiple Listen statements..."
>
> Excellent :)
>
> +1 on SAFE_UNSERIALIZED_ACCEPT for freebsd 2.2+ then.
>
> Dean
>
>
Re: flock() question (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 28 Nov 1997, Marc Slemko wrote:
> "if using a FreeBSD box of recent 2.2 vintage and you don't need accept
> locking because you aren't using multiple Listen statements..."
Excellent :)
+1 on SAFE_UNSERIALIZED_ACCEPT for freebsd 2.2+ then.
Dean
Re: flock() question (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Fri, 28 Nov 1997, Dean Gaudet wrote:
> You always need locking if there are multiple Listen statements.
Let me rephrase what I said:
"if using a FreeBSD box of recent 2.2 vintage and you don't need accept
locking because you aren't using multiple Listen statements..."
Yes, I mean what you say. <g>
> Otherwise FreeBSD has broken accept() semantics. Our select()/accept()
> loop is not designed for multiple tasks when there are multiple sockets.
> You end up starving sockets because children will block on a single
> socket and not wake up until they manage to get a request on that socket;
> meanwhile requests may be ready on other sockets and go unserviced.
>
> Defining SAFE_UNSERIALIZED_ACCEPT is fine with me, that only affects
> the single socket case.
>
> Dean
>
> On Fri, 28 Nov 1997, Marc Slemko wrote:
>
> > FYI, if using a FreeBSD box of recent 2.2 vintage and you don't need
> > accept locking to handle multiple Listen statements, you may (or may not)
> > get better performance with many children using SAFE_UNSERIALIZED_ACCEPT.
> >
> > This is because for each accept() only one child is woken up, but whenever
> > a process fights for a flock(), they all wake up.
> >
> > ---------- Forwarded message ----------
> > Date: Fri, 28 Nov 1997 03:07:25 -0800
> > From: David Greenman <dg...@root.com>
> > To: Marc Slemko <ma...@znep.com>
> > Cc: Charles Mott <cm...@srv.net>, hackers@FreeBSD.ORG
> > Subject: Re: flock() question
> >
> > >Hmm. It looks like if you have multiple processes blocked on the
> > >same lock in FreeBSD (well, 2.2 anyway), they are all woken up when
> > >the lock is freed. Yes, only one will get the lock but they will
> > >all be woken. Unless I am reading the code wrong... This is in
> > >contrast to multiple processes blocking in accept(), where only
> > >one will be woken up.
> >
> > The optimized wakeup case for accept() is that way because I optimized
> > it. :-) You're probably right about flock(), but I haven't gotten around to
> > looking at that and other potential wakeup optimizations. Changes like that
> > have to be made with great care...what seems obvious often doesn't turn out
> > that way. :-)
> >
> > -DG
> >
> > David Greenman
> > Core-team/Principal Architect, The FreeBSD Project
> >
> >
>
Re: flock() question (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
You always need locking if there are multiple Listen statements.
Otherwise FreeBSD has broken accept() semantics. Our select()/accept()
loop is not designed for multiple tasks when there are multiple sockets.
You end up starving sockets because children will block on a single
socket and not wake up until they manage to get a request on that socket;
meanwhile requests may be ready on other sockets and go unserviced.
Defining SAFE_UNSERIALIZED_ACCEPT is fine with me, that only affects
the single socket case.
Dean
On Fri, 28 Nov 1997, Marc Slemko wrote:
> FYI, if using a FreeBSD box of recent 2.2 vintage and you don't need
> accept locking to handle multiple Listen statements, you may (or may not)
> get better performance with many children using SAFE_UNSERIALIZED_ACCEPT.
>
> This is because for each accept() only one child is woken up, but whenever
> a process fights for a flock(), they all wake up.
>
> ---------- Forwarded message ----------
> Date: Fri, 28 Nov 1997 03:07:25 -0800
> From: David Greenman <dg...@root.com>
> To: Marc Slemko <ma...@znep.com>
> Cc: Charles Mott <cm...@srv.net>, hackers@FreeBSD.ORG
> Subject: Re: flock() question
>
> >Hmm. It looks like if you have multiple processes blocked on the
> >same lock in FreeBSD (well, 2.2 anyway), they are all woken up when
> >the lock is freed. Yes, only one will get the lock but they will
> >all be woken. Unless I am reading the code wrong... This is in
> >contrast to multiple processes blocking in accept(), where only
> >one will be woken up.
>
> The optimized wakeup case for accept() is that way because I optimized
> it. :-) You're probably right about flock(), but I haven't gotten around to
> looking at that and other potential wakeup optimizations. Changes like that
> have to be made with great care...what seems obvious often doesn't turn out
> that way. :-)
>
> -DG
>
> David Greenman
> Core-team/Principal Architect, The FreeBSD Project
>
>