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/23 19:42:01 UTC
Re: Serious performance issue with 2.2.5-RELEASE (fwd)
---------- Forwarded message ----------
Date: Sun, 23 Nov 1997 11:19:31 +0300 (????)
From: Dmitry Khrustalev <di...@bog.msu.su>
To: Jaye Mathisen <mr...@cdsnet.net>
Cc: David Greenman <dg...@root.com>, hackers@freebsd.org
Subject: Re: Serious performance issue with 2.2.5-RELEASE
On Sat, 22 Nov 1997, Jaye Mathisen wrote:
>
> I do not believe so. What ever it is definitely appears related to
> swapping/paging somehow.
I beleive the following patch to apache should improve situation:
--- alloc.c.old Sun Nov 23 11:15:31 1997
+++ alloc.c Sun Nov 23 11:16:34 1997
@@ -199,7 +199,8 @@
/* Nope. */
min_size += BLOCK_MINFREE;
- return malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC);
+ return malloc_block((min_size > BLOCK_MINALLOC - sizeof(union block_hdr)) ?
+ min_size : BLOCK_MINALLOC - sizeof(union block_hdr));
}
>
> I get these LA spikes in the several hundreds, the disk light is on solid
> for 2-3 minutes, then it all goes away.
>
> System accounting doesn't show any unusual pattern of apps being run. The
> vast majority are perl scripts.
>
> There's about 1100 processes on the machine, give or take a few, with
> about 80MB RAM free.
>
> NFS is compiled in, but not used.
>
> I have also disabled ntpd thinking something was hanging there, but
> no dice.
>
>
>
> On Sat, 22 Nov 1997, David Greenman wrote:
>
> > >I upgraded my web server to 2.2.5 from 2.2.2-stable, dated sometime in
> > >July.
> > >
> > >Big mistake.
> > >
> > >The only update to take place was the make buildworld, make installworld,
> > >no other configuration files were modified, nor any changes to startup
> > >scripts, etc.
> > >
> > >I now get these weird pauses where everything on the machine just freezes
> > >for 30-40 seconds, sometimes longer. NFS is compiled in, but not in use.
> > >
> > >The system was a web server, and was happily serving up several hundred
> > >domains. Now with the upgrade, I'll be lucky to keep them.. Not good.
> > >
> > >It's a Super Micro P6, 384MB RAM, 2 SCSI disks off a bus-logic controller.
> > >
> > >Any ideas appreciated. I have built a new kernel from sources supped
> > >11/7, but it doesn't seem to be any better.
> >
> > Is it possible that the slowness could actually be a network related
> > problem involving the updated 'de' driver in 2.2.5?
> >
> > -DG
> >
> > David Greenman
> > Core-team/Principal Architect, The FreeBSD Project
> >
>
Re: Serious performance issue with 2.2.5-RELEASE (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Yeah I was thinking about it more while driving around today and
remembered that because there are still routines we use which use malloc()
(i.e. fopen(), opendir(), gethostbyname(), oh just about any random
function in libc) this is hopeless. We can't control alignment this way.
However it's something worth thinking about, along with that other thread
we had before regarding marking the initial configuration read-only to
improve behaviour on systems like Solaris which allocate all the backing
store when fork() happens.
Dean
On Sun, 23 Nov 1997, Marc Slemko wrote:
> On Sun, 23 Nov 1997, Dean Gaudet wrote:
>
> > It actually should round up to the size of a system page, we'd have to
> > check a few different macros to get it right. But this is probably worth
> > it because right now we tend to allocate something just over 8k, which
> > means we're probably wasting 3k+ per block.
>
> We can't reliably detect what it should round to no matter how hard we
> try. It should round to the biggest possible size that will cause malloc
> to allocate the same amount as it would for the unrounded number. This is
> more complicated than page size, because some mallocs can do funky things
> not entirely based on page size.
>
> I guess we could get into system-specific behaviours (ie. not just
> checking macros, but based on external knowledge of how the system acts)
> if desired, but that gets quite ugly.
>
> In any case, I don't think there is any system where doing the below
> change will hurt because you will never, on any system I could imagine
> (well, ignore quantum computers...) get better used allocations from 8k +
> sizeof(union block_hdr) than 8k allocations.
>
> Hmm. Making this change results in this:
>
> root 23827 5.9 2.5 1364 1148 ?? Ss 12:57PM 0:00.33 /usr/home/marcs/archive/apache/apachen/src/httpd
>
> increasing to this:
>
> root 23755 1.9 2.4 1376 1132 ?? Ss 12:56PM 0:00.32 /usr/home/marcs/archive/apache/apachen/src/httpd
>
> On a system with 2000 name based vhosts and 2000 aliases in the
> main server config.
>
> >
> > Dean
> >
> > On Sun, 23 Nov 1997, Marc Slemko wrote:
> >
> > >
> > >
> > > ---------- Forwarded message ----------
> > > Date: Sun, 23 Nov 1997 11:19:31 +0300 (????)
> > > From: Dmitry Khrustalev <di...@bog.msu.su>
> > > To: Jaye Mathisen <mr...@cdsnet.net>
> > > Cc: David Greenman <dg...@root.com>, hackers@freebsd.org
> > > Subject: Re: Serious performance issue with 2.2.5-RELEASE
> > >
> > >
> > >
> > > On Sat, 22 Nov 1997, Jaye Mathisen wrote:
> > >
> > > >
> > > > I do not believe so. What ever it is definitely appears related to
> > > > swapping/paging somehow.
> > >
> > > I beleive the following patch to apache should improve situation:
> > >
> > > --- alloc.c.old Sun Nov 23 11:15:31 1997
> > > +++ alloc.c Sun Nov 23 11:16:34 1997
> > > @@ -199,7 +199,8 @@
> > > /* Nope. */
> > >
> > > min_size += BLOCK_MINFREE;
> > > - return malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC);
> > > + return malloc_block((min_size > BLOCK_MINALLOC - sizeof(union block_hdr)) ?
> > > + min_size : BLOCK_MINALLOC - sizeof(union block_hdr));
> > > }
> > >
> > >
> > >
>
>
Re: Serious performance issue with 2.2.5-RELEASE (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Sun, 23 Nov 1997, Dean Gaudet wrote:
> It actually should round up to the size of a system page, we'd have to
> check a few different macros to get it right. But this is probably worth
> it because right now we tend to allocate something just over 8k, which
> means we're probably wasting 3k+ per block.
We can't reliably detect what it should round to no matter how hard we
try. It should round to the biggest possible size that will cause malloc
to allocate the same amount as it would for the unrounded number. This is
more complicated than page size, because some mallocs can do funky things
not entirely based on page size.
I guess we could get into system-specific behaviours (ie. not just
checking macros, but based on external knowledge of how the system acts)
if desired, but that gets quite ugly.
In any case, I don't think there is any system where doing the below
change will hurt because you will never, on any system I could imagine
(well, ignore quantum computers...) get better used allocations from 8k +
sizeof(union block_hdr) than 8k allocations.
Hmm. Making this change results in this:
root 23827 5.9 2.5 1364 1148 ?? Ss 12:57PM 0:00.33 /usr/home/marcs/archive/apache/apachen/src/httpd
increasing to this:
root 23755 1.9 2.4 1376 1132 ?? Ss 12:56PM 0:00.32 /usr/home/marcs/archive/apache/apachen/src/httpd
On a system with 2000 name based vhosts and 2000 aliases in the
main server config.
>
> Dean
>
> On Sun, 23 Nov 1997, Marc Slemko wrote:
>
> >
> >
> > ---------- Forwarded message ----------
> > Date: Sun, 23 Nov 1997 11:19:31 +0300 (????)
> > From: Dmitry Khrustalev <di...@bog.msu.su>
> > To: Jaye Mathisen <mr...@cdsnet.net>
> > Cc: David Greenman <dg...@root.com>, hackers@freebsd.org
> > Subject: Re: Serious performance issue with 2.2.5-RELEASE
> >
> >
> >
> > On Sat, 22 Nov 1997, Jaye Mathisen wrote:
> >
> > >
> > > I do not believe so. What ever it is definitely appears related to
> > > swapping/paging somehow.
> >
> > I beleive the following patch to apache should improve situation:
> >
> > --- alloc.c.old Sun Nov 23 11:15:31 1997
> > +++ alloc.c Sun Nov 23 11:16:34 1997
> > @@ -199,7 +199,8 @@
> > /* Nope. */
> >
> > min_size += BLOCK_MINFREE;
> > - return malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC);
> > + return malloc_block((min_size > BLOCK_MINALLOC - sizeof(union block_hdr)) ?
> > + min_size : BLOCK_MINALLOC - sizeof(union block_hdr));
> > }
> >
> >
> >
Re: Serious performance issue with 2.2.5-RELEASE (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
It actually should round up to the size of a system page, we'd have to
check a few different macros to get it right. But this is probably worth
it because right now we tend to allocate something just over 8k, which
means we're probably wasting 3k+ per block.
Dean
On Sun, 23 Nov 1997, Marc Slemko wrote:
>
>
> ---------- Forwarded message ----------
> Date: Sun, 23 Nov 1997 11:19:31 +0300 (????)
> From: Dmitry Khrustalev <di...@bog.msu.su>
> To: Jaye Mathisen <mr...@cdsnet.net>
> Cc: David Greenman <dg...@root.com>, hackers@freebsd.org
> Subject: Re: Serious performance issue with 2.2.5-RELEASE
>
>
>
> On Sat, 22 Nov 1997, Jaye Mathisen wrote:
>
> >
> > I do not believe so. What ever it is definitely appears related to
> > swapping/paging somehow.
>
> I beleive the following patch to apache should improve situation:
>
> --- alloc.c.old Sun Nov 23 11:15:31 1997
> +++ alloc.c Sun Nov 23 11:16:34 1997
> @@ -199,7 +199,8 @@
> /* Nope. */
>
> min_size += BLOCK_MINFREE;
> - return malloc_block((min_size > BLOCK_MINALLOC) ? min_size : BLOCK_MINALLOC);
> + return malloc_block((min_size > BLOCK_MINALLOC - sizeof(union block_hdr)) ?
> + min_size : BLOCK_MINALLOC - sizeof(union block_hdr));
> }
>
>
>
>
> >
> > I get these LA spikes in the several hundreds, the disk light is on solid
> > for 2-3 minutes, then it all goes away.
> >
> > System accounting doesn't show any unusual pattern of apps being run. The
> > vast majority are perl scripts.
> >
> > There's about 1100 processes on the machine, give or take a few, with
> > about 80MB RAM free.
> >
> > NFS is compiled in, but not used.
> >
> > I have also disabled ntpd thinking something was hanging there, but
> > no dice.
> >
> >
> >
> > On Sat, 22 Nov 1997, David Greenman wrote:
> >
> > > >I upgraded my web server to 2.2.5 from 2.2.2-stable, dated sometime in
> > > >July.
> > > >
> > > >Big mistake.
> > > >
> > > >The only update to take place was the make buildworld, make installworld,
> > > >no other configuration files were modified, nor any changes to startup
> > > >scripts, etc.
> > > >
> > > >I now get these weird pauses where everything on the machine just freezes
> > > >for 30-40 seconds, sometimes longer. NFS is compiled in, but not in use.
> > > >
> > > >The system was a web server, and was happily serving up several hundred
> > > >domains. Now with the upgrade, I'll be lucky to keep them.. Not good.
> > > >
> > > >It's a Super Micro P6, 384MB RAM, 2 SCSI disks off a bus-logic controller.
> > > >
> > > >Any ideas appreciated. I have built a new kernel from sources supped
> > > >11/7, but it doesn't seem to be any better.
> > >
> > > Is it possible that the slowness could actually be a network related
> > > problem involving the updated 'de' driver in 2.2.5?
> > >
> > > -DG
> > >
> > > David Greenman
> > > Core-team/Principal Architect, The FreeBSD Project
> > >
> >
>
>