Re: Scaling with memory & disk planning (was Re: Non-linear

On Thu, 30 May 2002, Doug Fields wrote:

> If I ran PostgreSQL with a Linux 2.4 kernel and 6GB of RAM with dual P4 Xeons:
> a) Could PostgreSQL use all the RAM?

Yes, but no single process could. Since you're on a 32-bit machine
your maximum address space is 4 GB, and the Linux kernel keeps 1
GB of that for itself, so no process (i.e., no individual backend,
in this case) can address more than 3 GB of RAM.

I'm not sure how the Linux buffer caching works, but there is a
possibility that this kind of thing could give you a very nice
large buffer cache.

> c) Could PostgreSQL use this "hyperthreading" that apparently is in these
> P4 Xeons making dual processors look like four processors (obviously, on
> four separate queries)?

Does Linux come up saying there are 4 processors installed in your
system? If so, yes. If not, no.

> d) How much extra performance does having the log or indices on a different
> disk buy you, esp. in the instance where you are inserting millions of
> records into a table? An indexed table?

When inserting, log on a separate disk buys you a lot. (You don't get
the table and index writes moving the disk head away from the end of the
log file.)

Splitting index and table files may help somewhat, but that's harder to
determine. You always want to throw at them as many disk arms as you
can, but it's usually the safer bet to combine it all on one big stripe
set or raid or whatever, unless you have a very consistent workload and
are willing to play around a lot to determine how you can best optimize
this stuff.

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC