On Jul 20, 2011, at 6:25 PM, Owen DeLong wrote:
SSDs can be a good alternative these days as well. Some of them have gotten to be quite fast. Sure, you'll have to replace them more often than spinning media, but,
Actually the the scale of writes associated with this application is unlikely to significantly impact the service life of an SLC nand ssd with a solid block shadowing/wear leveling implementation. back in 2007 I was convinced that we could improve on the reliability of our network appliances with industrial 2.5" sata and enterprise sas disks, and the situation has only improved since.
the write times can be quite a bit better.
like orders of magnitude.
Owen
On Jul 20, 2011, at 3:28 PM, Jimmy Hess wrote:
On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton <ncolton@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