Does anyone have any suggestions on performance tuning a DHCP server?
Basically the problem that I'm running into is that my server isn't able to
handle any more than 20 DHCP requests per second Any more requests than
that and basically my UDP buffers fill up and not all of the requests are
answered. By the wonders of UDP this turns into a snowball effect and the
numbers of DHCP requests per second goes up since the clients aren't seeing
all of the responses.
I've attempted to change the UDP buffers from a default of 128k to 1Mb and
8Mb with no changes in the outcome.
Mathematically I'm figuring that the server should be getting about 24
requests per second. This is figured out with 47110 current leases with a
7200 sec default lease time with a 14400 max-lease. Additionally I have 531
leases that have a 30 sec lease time. Since we use a MAC address
registration system the pool with the 30 sec leases are for unregistered MAC
addresses.
In my testing with TCPDump over a 72 second capture it was getting 45
requests per sec and the replies were at 33 per second during the same
capture.
Here is a quick overview of what I'm running with:
ISC DHCP V3.0.5
RedHat Enterprise 3.0
HP DL380 G3 server with Dual Xeon 2.8Ghz proc and 4 Gb RAM.
Raid5 setup includes 3 32gig UltraSCSI drive.
Current Sysctl Settings:
net.core.wmem_default = 65535
net.core.wmem_max = 131071
net.core.rmem_default = 131071
net.core.rmem_max = 131071
Any responses would be greatly appreciated.
Cory

PGP SIGNED MESSAGE
Hash: SHA1

27 Mar 2007, at 21:52, Cory Meyer wrote:

Next steps would be to try and
reduce the dependency on fsync().

Look to your syslog.conf, and consider which subsystems you need
immediate logging for. Search the output from `man syslog.conf'
for `omit sync'. A few servers ago, this bought us a big improvement
on a saturated box which was overdue for replacement.

Best regards,

Niall 'Reilly
University College Dublin IT Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

PGP SIGNATURE
Version: GnuPG v1.4.1 (Darwin)

4kJfIuBuQhUm2Ip3EoXNQ=
=rvQZ
PGP SIGNATURE

What about writing the dhcpd.leases file to a virtual disk or flash?

Frank

Message
From: dhcp-users-bounce (AT) isc (DOT) org [mailto:dhcp-users-bounce (AT) isc (DOT) org] Behalf
Cory Meyer
Sent: Tuesday, March 27, 2007 11:31 AM
To: dhcp-users (AT) isc (DOT) org
Subject: DHCP/UDP performance tuning

Does anyone have any suggestions on performance tuning a DHCP server?
Basically the problem that I'm running into is that my server isn't able to
handle any more than 20 DHCP requests per second Any more requests than
that and basically my UDP buffers fill up and not all of the requests are
answered. By the wonders of UDP this turns into a snowball effect and the
numbers of DHCP requests per second goes up since the clients aren't seeing
all of the responses.

I've attempted to change the UDP buffers from a default of 128k to 1Mb and
8Mb with no changes in the outcome.

Mathematically I'm figuring that the server should be getting about 24
requests per second. This is figured out with 47110 current leases with a
7200 sec default lease time with a 14400 max-lease. Additionally I have 531
leases that have a 30 sec lease time. Since we use a MAC address
registration system the pool with the 30 sec leases are for unregistered MAC
addresses.

In my testing with TCPDump over a 72 second capture it was getting 45
requests per sec and the replies were at 33 per second during the same
capture.

Here is a quick overview of what I'm running with:

ISC DHCP V3.0.5
RedHat Enterprise 3.0
HP DL380 G3 server with Dual Xeon 2.8Ghz proc and 4 Gb RAM.
Raid5 setup includes 3 32gig UltraSCSI drive.

Current Sysctl Settings:
net.core.wmem_default = 65535
net.core.wmem_max = 131071
net.core.rmem_default = 131071
net.core.rmem_max = 131071

Any responses would be greatly appreciated.

Cory

PGP SIGNED MESSAGE
Hash: SHA1

28 Mar 2007, at 04:10, Frank Bulk wrote:
What about writing the dhcpd.leases file to a virtual disk or flash?

Possibly. The key task is to locate the bottleneck first.
What led us to tackle our logging back whenever was that
we identified syslog very clearly as the bottleneck.

Virtual disk might not meet the requirement for saving state
to non-volatile storage.

Best regards,

Niall 'Reilly
University College Dublin IT Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

PGP SIGNATURE
Version: GnuPG v1.4.1 (Darwin)

NqjtKDLI6wJ0rUM4CAGHFc8=
=E4xW
PGP SIGNATURE