Good luck buying X25-Es; they're out of production and all gone from supply chain. Replacement 710 and 720 models are ETA in late August at the moment.
Micron has some large-cap SLC drives in the chain for September/October/ish timeframes. Ramdisk with rsync or rdiffbackup to spinning storage will do just fine. -george On Wed, Jul 20, 2011 at 4:01 PM, Joel Jaeggli <[email protected]> wrote: > > 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<[email protected]> 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 >>> [email protected] >>> https://mailman.nanog.org/mailman/listinfo/nanog >> >> _____ >> NANOG mailing list >> [email protected] >> https://mailman.nanog.org/mailman/listinfo/nanog >> > > > _____ > NANOG mailing list > [email protected] > https://mailman.nanog.org/mailman/listinfo/nanog > -- -george william herbert [email protected] _____ NANOG mailing list [email protected] https://mailman.nanog.org/mailman/listinfo/nanog
