dhcpd lease problems?
Alan DeKok
adekok at infoblox.com
Tue Jun 6 22:45:15 UTC 2006
David W. Hankins wrote:
> If at some point, the complaint I hear from the user community is that
> the server does not start up slow enough, then I will consider
> encumbering the server startup logic. As it stands, I hear the converse
> fairly loudly.
Our analysis using "callgrind" indicates that 90% or more of start
time is new_address_range(). Most of that is the checks for overlapping
ranges, by looking up each newly allocated lease in the
lease_ip_addr_hash. Given the fixed size of the hash table, the result
is pretty much O(N^2) in the number of managed leases.
Hence the long startup time.
If, instead, the leases are allocated as needed, DHCPOFFER's would
down a bit. But since the server is already limited by sync's and
syslog, the extra call to lease_allocate() wouldn't matter much.
> In the world where you have a dhcp daemon which is dynamically given
> its dynamic pool ranges (eg via something resembling OMAPI, but not),
> it is simply not a good idea to permit lease structures to remain around
> forever.
Once the leases are allocated as needed, rather than in one big
block, free'ing leases becomes trivial. The contiguous allocation &
initialization is causing the slow startup time, *and* the inability to
free leases.
> There is simply no compelling reason for this complexity, considering
> that reserved dynamic lease are not only what's being asked for, but
> are already completed.
I'm not clear on the difference between the current hosts, and
reserved dynamic leases. Is it just that the reserved dynamic leases
inherit the pool & range properties, where hosts don't?
Alan DeKok.
More information about the dhcp-users
mailing list