Re: Performance Tuning, hardware-wise

> I wonder why there is no mention at all in the documentation about
hardware considerations
> - aside from CPU and Memory stuff, which is probably a) _way_ to obvious
(a faster CPU
> will always make everything faster) and b) too bound up with both
fincancials and also
> this vast zoo that we have, of different brands and architectures, which
is a minefield of
> potential flamewars - what I mean is simple, straightforward stuff such as
disk layout?!

    A truly bad disk layout can indeed cripple a database, but running Linux
and assuming you have enough RAM, the disk I/O has never been that much of a
problem for us.   I'll tell you about our setup, maybe it will help with
performance planning.

    When we were small, we used a single dual-processor machine with an IDE
drive, and ran the web server, CGI, and database all on the same machine.
Despite the efficiency of Postgres and Apache, as our load got significantly
heavier, that single box with twin 600's just simply couldn't cut it,
running at 100% CPU utilization most of the time.

    As for the drive in that machine, doing inserts on it was SLOW.   Slower
even than on our beater development machine.  I suppose I could have fiddled
with hdparm to increase the disk I/O, but that would have been a temporary
fix at best.  Our CGI applications were eating lots of CPU time, and we just
needed more processors.

     So, we moved to a large database machine to service a group of web
servers.  The database machine has four Xeon 700's in it, with 512 megs of
RAM.  For the disk, we did decide to go with a RAID array, for disk
redundancy as much as efficiency.  The fast disk array makes inserts go
tremedously fast, but for selects, well, it's still the same - you're
limitted by CPU and memory.   Why not disk I/O?  Well, the entire dataset is
in the disk cache anyway, so there's very little disk I/O involved with
selects.

     Our data directory is 340 megs, and the machine has 512 megs of RAM,
and Postgres is just too efficient with RAM.   ; )  I start up the
postmaster with 3072 buffer blocks, and yesterday increased the amount of
memory each postmaster can use for sorting from the default of 4 megs to 32
megs, which did give a small speed increase, but the machine *still* has at
least 120 megs completely unused at all times.  Maybe I'll give each backend
more RAM for sorting. : )

> A more extreme idea: If I know that the total size of my database won't
grow over, say, a
> gigabyte, then why shouldn't I invest my money in RAM (little more than
$500 these days,
> for a G of RAM), create a ramdisk of 1 G (provided my architecture can
house that much RAM
> but that's beside the point), and mount /usr/local/pgsql/data right
there?!

  Under Linux, RAM disks aren't much faster/better than regulsr disks, from
the benchmarks I've seen.  Besides, then a power-outtage can really hose
you. : )

Steve