Watching performance on a DHCP Server
blake at ispn.net
Fri Feb 8 23:44:39 UTC 2008
-------- 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users