Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 11 Aug 2004 11:07:46 -0400 (EDT)
From:      Robert Watson <rwatson@freebsd.org>
To:        Martin Blapp <mb@imp.ch>
Cc:        freebsd-current@freebsd.org
Subject:   Re: SCHEDULE and high load situations
Message-ID:  <Pine.NEB.3.96L.1040811105851.17560E-100000@fledge.watson.org>
In-Reply-To: <20040811164404.X31181@cvs.imp.ch>

next in thread | previous in thread | raw e-mail | index | archive | help

On Wed, 11 Aug 2004, Martin Blapp wrote:

> During load tests with both SCHED4BSD and SCHEDULE I found that the
> latest SCHEDULE version cannot have a load over 2-3. I stress tested the
> server really a lot, but about 500 processes did sleep and did not got
> scheduled and only 2 of 500 were run and got about 50% of CPU time. 
> 
> Is this a known problem ? 

I've found that for throughput oriented workloads, 4BSD substantially
outperforms ULE, but I haven't tried it with Jeff's latest set of patches
(committed a day or two ago).  You don't mention if your box is SMP, btw
-- I've noticed some load balancing problems with ULE previously, but
haven't checked if they were resolved.  Anecdotal opinion seems generally
to be that interactivity is observably better with ULE than 4BSD, but that
4BSD appears to do a better job under load.

This weekend I'll be rerunning a number of benchmarks across a broad range
of variables (scheduler, smp support, htt, various locking models,
different netisr models, threading libraries, etc) to evaluate progress
over the last month, and I'll see how things look with ULE.

FYI, when I started benchmarking MySQL a couple of months ago, I was
seeing about 2800 transactions/sec on a benchmark on my dual P4 with
(GENERIC - DEBUGGING).  Now I'm seeing about 7100-7200 transactions/sec. 
I've merged pretty much all of the changes necessary to see that
transition except moving to 4BSD by default, disabling HTT by default, and
enabling Giant-free networking by default.  UP has also improved, but only
be a relatively small fraction, so I've been shifting attention to UP from
SMP.  Some of the wins on SMP have been from moving to adaptive mutexes by
default (most recently, for Giant on i386); others from improved fine
grain locking in VM and networking, and general optimization of
synchronization primitives, scheduling, wakeups/locking, etc.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert@fledge.watson.org      Principal Research Scientist, McAfee Research



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040811105851.17560E-100000>