In article <CAAAwwbUDj4yGudeVRohAPywj=39zjmapt0kyjw8wa2szhb9...@mail.gmail.com> you write: >On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton <ncol...@allophone.net> wrote: >> We were seeing similar issues with low leases, moved the dhcpd.leases file >> to a ramdisk and went from ~200 leases per second to something like 8,000 >> leases per second. > >Yes, blame RFC2131's requirement that a DHCP server is to ensure that any >lease is committed to persistent storage, strictly before a DHCP >server is allowed to >send the response to the request; a fully compliant DHCP server with >sufficient traffic >is bound by the disk I/O rate of underlying storage backing its database.
Well, that's easily fixed (if the architecture of the server allows it): just queue up but don't send out the replies, then every 10ms sync the changes to the filesystem and then send out the replies. "fsync batching". Perhaps someone should suggest this to the ISC DHCPD developers. Mike. _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog