Load times for Large Subnets

David W. Hankins David_Hankins at isc.org
Tue Oct 9 20:20:24 UTC 2007


On Tue, Oct 09, 2007 at 10:51:12AM -0700, Larry Apolonio wrote:
> Basically I up'd that number by an order of magnitude + some (I think it 
> was 20000003) and my load times dropped from 20 minutes to 6 seconds.

Are you sure you also aren't comparing across-feature-trains?  E.g.,
3.0.x vs 3.1.x?

If not I wonder if we still have some lease hash collision problems,
and you'd be doing me a favor if you could rebuild with
REPORT_HASH_PERFORMANCE defined and the default hash table size (that
only works in 3.1 or 4.0).

Going from 3:1 to 1:48 buckets shouldn't net such wide results.

> This section was in dhcp-3.1.0 and dhcp-4.0.0.a3 but it was not in the 
> RHEL SRPMS dhcp-3.0.5.

3.0.x uses 'DEFAULT_HASH_SIZE' for everything, 9973.  You could up it,
but you'd up it for -all hash tables-.

> There certainly was a huge cost in memory, I think it took nearly a GB 
> of RAM, but dhcperf showed similar results in 4 way handshakes. 

That hash size is used for several tables, and consumes a pointer
for each bucket.

So it's a rather multiplicative increase in memory footprint.

> Does anyone know if there are any other problems that will arise when I 
> increased this number?  What other tweaks are there that I can do to 
> improve transaction performance.  Would be nice to be able to do 100,000 
> four way handshakes per hour.

If you're going to run on tmpfs, and you're going to be editing
sources anyway, comment out the fsync() call.  It's an extra system
call at that point.  Not doing anyone any good.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins


More information about the dhcp-users mailing list