Watching performance on a DHCP Server

[Blake Hudson]

-------- Original Message  --------
Subject: Re: Watching performance on a DHCP Server
From: David W. Hankins <David_Hankins at isc.org>
To: dhcp-users at isc.org
Date: Friday, February 08, 2008 4:53:15 PM
> On Fri, Feb 08, 2008 at 03:27:23PM -0600, Blake Hudson wrote:
>   
>> Seems like it would make sense that this I/O could be non-blocking.... 
>>     
>
> That's just it, we feel it can't be, or else you run the risk of
> duplicate allocations on a restart.  The simple way of saying it is
> the database isn't consistent.
>
> It's the same sort of thing that makes an e-commerce system want to
> 'SQL COMMIT' before replying down an http socket that an order has
> gone through.  If you crash and need to recover data from disk, you'd
> rather have the customer's money and order than an order number that's
> a duplicate for some other customer because your system walked over it
> when it came back up.
>
> Same deal; we deal in leases which are a lot like transactions.  A
> promise is made that an address is good for a given time.  Money may
> not change hands, but things break if you reneg, things work if you
> delay or even drop the request waiting...the far end retransmits.
>
>
> I don't mind it being configurable behaviour, heck all you have to do
> is comment out a single line and rebuild the sources if you were
> intent on it, but we haven't got a patch for that.
>
>   
I was thinking about that [patch] while composing my last message. I 
truly appreciate your time and expertise in this matter.

The pros of fsync are that I can say I will never lose a lease (assuming 
my disks don't die, RAID controller doesn't die, file system doesn't 
corrupt, RAM doesn't go bad, server doesn't hit the bricks, etc). The 
downside is that I have to spend twice as much on server hardware to 
handle the increased load (or build a custom workaround such as tempfs 
that could lead to loss of a lot more data) and still may end up with 
less capacity compared to an async setup.

The pros of async are that I can spend much less on server hardware, the 
cons being that I might lose 5 seconds (default commit time for ext3) of 
leases (single digits?) if my server were to freeze (again making the 
same assumptions about hardware failure).

There are a lot of things that can go wrong with a server (or network 
for that matter). From a practical perspective, the thought of losing 5 
seconds of leases in server lockup is a non-issue to me (and probably 
others). If I had the choice of penalizing every request, versus 
penalizing a few requests in several years time I would choose the later.

I'd love to see this available as an option left up to the server 
administrator. I'll take a gander at the source next week and see 
exactly what it might take. Any changes I make will probably not be as 
useful as I'd prefer to stick with the src rpm provided by my 
distribution (Fedora), which is currently 3.0.x based.

Thanks again,
-Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080208/3acf718c/attachment.html>