Date: Thu, 30 Mar 2006 21:51:23 +0200 From: usleepless@gmail.com To: "Kris Kennaway" <kris@obsecurity.org> Cc: Miguel <mmiranda@123.com.sv>, freebsd-questions@freebsd.org Subject: Re: terrible performance in 6.1beta4 Message-ID: <c39ec84c0603301151s77b37291x3ac1f79582cd753e@mail.gmail.com> In-Reply-To: <20060330150136.GA12982@xor.obsecurity.org> References: <442B2FC6.9040001@123.com.sv> <20060330011834.GA84658@xor.obsecurity.org> <c39ec84c0603300047u5530fc1fjb1ba93fcafcd490d@mail.gmail.com> <442BF0BB.8010504@123.com.sv> <20060330150136.GA12982@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris, > > 3.0G > > Well there you go then..you're trying to access a file that is larger > than RAM, so naturally you won't be able to fit it all in RAM, and > with 1GB less RAM in your system you'll spend much more time reading > bits of it from disk and later throwing them away. i know a bit of databases, and assume you do as well, so i am hesative to question your explanation but: the importing of a DB-file ( being tab-sep-copies or SQL dumps ) is a transformation process and does not require all data to be in core ( is that the right terminology? ) at the same moment. it transform x Gigs of input to y Gigs of output. i don't see why the 2GB machine would suffer this hard. unless the 3GB-file is one big table. is it MIguel? then it might be a postgresql hitch. i will have to wait on the .conf files, Miguel has not claimed them to be identical, so i am curious. regards, usleep > > Kris > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c39ec84c0603301151s77b37291x3ac1f79582cd753e>