Watching performance on a DHCP Server

Blake Hudson blake at ispn.net
Mon Feb 11 22:37:57 UTC 2008



-------- Original Message  --------
Subject: Re: Watching performance on a DHCP Server
From: Olaf van der Spek <olafvdspek at gmail.com>
To: dhcp-users at isc.org
Date: Monday, February 11, 2008 3:55:24 PM
> On Feb 11, 2008 7:49 PM, Blake Hudson <blake at ispn.net> wrote:
>   
>> You may want to review the thread from the beginning. My network currently
>> has 10,000+ DHCP clients (and I plan on accommodating double that within the
>> lifetime of this server). I have a beefy server (4x 3.0GHz Xeon, 2x 15k
>> RAID1) and it was only able to reliably handle 10 to 20 4-way discover
>>     
>
> Isn't that too much CPU power, too little HDD power for this job?
>   

The server has eight directly attached 147GB 15k drives... it just 
happens that the leases file is on a RAID 1 array. Without fsyncs, the 
next limiting factor is CPU power... which I hit very quickly at around 
40 4-way handshakes a second (unfortunately dhcpd is not multithreaded). 
I have not been able to accurately measure 2-way handshakes after 
removing the fsync code. I'm guessing it's 5,000 or more per second... 
way more than I need.

>   
>> handshakes a second, 2-way handshakes were maybe double or triple those
>> numbers. When pounded by DHCP requests, it's possible that even less are
>> processed in a timely manner due to collisions, timeouts, etc.
>>
>>  The potential convergence time concerns me if there were an enterprise wide
>> prolonged outage. Increasing the lease time means less leases processed on a
>> regular basis (not as much of a concern) as well as reducing the need for a
>> 4 way handshake and being able to use a 2 way handshake if a prolonged
>> outage occurs (my main concern I'd like to accommodate).
>>     
>
> I just read the thread and the disk IO indeed changes the game. ;)
> Still, the gap between theoretical top performance and actual
> performance seems extreme.
> Even if you have the requirement that leases have to be committed to
> disk before you respond to the client.
>
>   

fsyncs are the most I/O intensive operation you can perform on magnetic 
media. If I remember correctly it takes at least 2 full rotations of the 
disk for an fsync to occur, although it may take longer to commit more 
data. This is were solid state rules over magnetic storage.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080211/4fd4fd4b/attachment.html>


More information about the dhcp-users mailing list