On Jul 20, 2011, at 3:37 PM, Walter Keen wrote: > We've recently setup ISC DHCPd with failover for lease information, and > LDAP as a configuration source (mostly because of our need for > dynamically adding dhcp reservations for cable modems, etc) -- we don't > have any performance issues thus far, but I'd imagine in a failover > environment, it might be safe to consider a ramdisk for leases. > Obvoiusly breaks RFC2131, but...
Use an ssd, all the cool kids with monolithic databases and tpc-c style workloads are doing it and since your storage requirements are negligible it ought to be fairly cheap. http://www.intel.com/design/flash/nand/extreme/index.htm Bandwidth Sustained sequential read: up to 250 MB/s Sustained sequential write: up to 170 MB/s Read latency 75 microseconds I/O Per Second (IOPS) Random 4KB Reads: >35,000 IOPS Random 4KB Writes: >3,300 IOP and that's for just one disk. > Walter Keen > Network Engineer > Rainier Connect > > (P) 360-832-4024 > (C) 253-302-0194 > > > On 07/20/2011 03:28 PM, Jimmy Hess wrote: >> 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. >> >> I do not recommend use of a RAMDISK; it's safer to bend the rule than break >> it >> entirely; a safer way is probably to use a storage system on a >> battery-backed >> NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server >> application, allowing the storage system to aggregate the I/O. >> >> >> Of course, committing to a RAMDISK tricks the DHCP server software. >> The danger is that if your DHCP server suffers an untimely reboot, you >> will have no transactionally safe record of the leases issued, when the >> replacement comes up, or the DHCP server completes its reboot cycle. >> >> As a result, you can generate conflicting IP address assignments, unless you: >> (a) Have an extremely short max lease duration (which can increase >> DHCP server load), or >> (b) Have a policy of pinging before assigning an IP, which limits DHCP server >> performance and is not fool proof. >> >> -- >> -JH >> >> _____ >> NANOG mailing list >> NANOG@nanog.org >> https://mailman.nanog.org/mailman/listinfo/nanog > > _____ > NANOG mailing list > NANOG@nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
