Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.mb-net.net!news.babsi.de!open-news-network.org!news.gnuher.de!news.enyo.de!.POSTED!not-for-mail From: Florian Weimer Newsgroups: comp.databases.berkeley-db Subject: Re: I have a quick question about exporting or dumping a database. Date: Fri, 10 Aug 2012 22:42:37 +0200 Lines: 13 Message-ID: <87k3x6h41u.fsf@mid.deneb.enyo.de> References: <87mx22sijl.fsf@mid.deneb.enyo.de> <5ZKdnSB-04t58LjNnZ2dnUVZ5sCdnZ2d@giganews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: news.enyo.de 1344631356 7783 172.17.135.6 (10 Aug 2012 20:42:36 GMT) X-Complaints-To: news@enyo.de Cancel-Lock: sha1:XDEleb01z787O9EtV7T2w7zUuNw= Xref: csiph.com comp.databases.berkeley-db:15 * jeff: > I have reason to believe that I am pushing the limits of the hard > drive IO even though the drives I am using are not exactly slow, but > the results of trying to copy does not seem to be effected by other > virtual machines running on that system. From other tests that I have > done I have verified that memory, and CPU are not being used much at > all, but the IO on the hard drive, mostly waiting for random seeks > might be causing problems. Yes, Berkeley DB has a known bug which causes horrendous file system fragmentation in its database files. Reading them sequentially is very, very slow, even on beefy disk arrays.