Watching performance on a DHCP Server
dhcp1 at thehobsons.co.uk
Wed Feb 13 19:52:20 UTC 2008
Enrique Perez-Terron wrote:
> > Now consider the case (the normal case for a server that's been
>> installed for a while on a busy network) that there are NO unused
>> leases at all.
>What happens if somebody connects a new PC to such a network?
>> Also consider that in the situations mentioned (long
>> term power outage), nearly all the clients will have had prior leases.
>Don't the leases expire?
This is NOT a Micro$oft DHCP server !
Yes leases expire, but they are NOT deleted - they are marked as
expired and available for re-use.
Initially, with a fresh config and fresh leases file, clients will be
allocated from a pool of "never previously used" addresses. Leases
that expire get marked as free but are NOT re-allocated at this stage.
Once there are no "not previously used addresses", then the server
will start to re-use addresses that have been allocated before - and
it does this on a least recently used basis. Ie, the address whose
lease expired the longest ago will be re-used.
This means that a client can leave the network for a long period, and
when it returns it may get the same address back - if the size of the
pools, number of clients, and churn rate are such that it's old
address hasn't been reused for another client.
What does NOT happen (with the ISC server, it does with the non-rfc
complaint Micro$oft server) is that a client returning to the network
after it's lease has expires gets a new random address (unless the
address has already been reassigned).
> > In both these cases, there is no list of unused leases to
>> pre-allocate - if you go ahead and pre-allocate expired leases, then
>> you risk violating the protocol by pre-allocating an address that a
>> client later wants to come back and use.
>ISPs use DHCP to assign addresses to N computers from a pool of M
>addresses with M < N. When a client comes back and wants an address, it
>gets a different address because the previous address has been
>reassigned to a different client.
Not usually true any more - with always on connections like ADSL, the
size of the pool needs to be considerably larger.
> > But the main issue is that
>> when these clients with expired leases come back online - do you a)
>> give them their old lease back (your method has gained nothing),
>I fail to see the connection. Why has my method gained nothing?
>The point was to avoid fsync for each transaction.
The client won't be given one of your pre-selected addresses, it gets
it's old address back. Thus your pre-selecting of addresses to lease
has done nothing useful in this case.
There are easier ways to avoid the fsync after every transaction -
like simply not calling fsync each time as is already being
done/planned in V4.
>The advantage of my proposed scheme over turning off fsync alltogether,
>is that after a crash you know that the addresses in the lost leases -
>if any - belong to a small set that you can dispense with, having a few
>more addresses than computers.
OK, I see where you are coming from now, but to be perfectly honest
it does sound a complicated system for something that I think we've
already agreed has simpler workarounds. The simplest seems to be to
enable the write-back cache in a battery backed raid controller -
then the fsync doesn't actually involve a physical write to disk
there and then. My personal opinion is that a raid controller with
battery backup should be no less reliable than a single disk - if you
raid controller dies then your server is screwed anyway and quite
possibly your whole leases database.
>Or, perhaps there is yet another way: delay responses to the clients,
>process other incoming request, and upon timeout (a few milliseconds),
>send all the offers to the log in a single transaction, fsync(), then
>send out all the offers to the clients. However, this may require a far
>bigger rewrite of the server.
It would indeed.
More information about the dhcp-users