Why do you claim that 'More platters also means slower seeks
and generally slower performance.'?
More platters -> more heads -> heavier head assembly -> slower seek time
But..
More platters -> higher density -> less seek distance (in mm of head
movement) -> faster seek time
As usual, no clear-cut case, a real-life test would tell more interesting
things.
I'm not entirely sure why the extra platters should really count
as more moving parts since I think the platter assembly and
head assembly are both single parts in effect, albeit they will
be more massive with more platters. I'm not sure how much
extra bearing friction that will mean, but it is reasonable that
some extra energy is going to be needed.
Since the bearings are only on one side of the axle (not both), a heavier
platter assembly would put more stress on the bearing if the disk is
subject to vibrations (like, all those RAID disks seeking together) which
would perhaps shorten its life. Everything with conditionals of course ;)
I remember reading a paper on vibration from many RAID disks somewhere a
year or so ago, vibration from other disks seeking at the exact same time
and in the same direction would cause resonances in the housing chassis
and disturb the heads of disks, slightly worsening seek times and
reliability. But, on the other hand, the 7 disks raided in my home storage
server never complained, even though the $30 computer case vibrates all
over the place when they seek. Perhaps if they were subject to 24/7 heavy
torture, a heavier/better damped chassis would be a good investment.
It may be worth considering an alternative approach. I suspect
that a god RAID1 or RAID1+0 is worthwhile for WAL, but
Actually, now that 8.3 can sync to disk every second instead of at every
commit, I wonder, did someone do some enlightening benchmarks ? I remember
benchmarking 8.2 on a forum style load and using a separate disk for WAL
(SATA, write cache off) made a huge difference (as expected) versus one
disk for everything (SATA, and write cache off). Postgres beat the crap
out of MyISAM, lol.
Seems like Postgres is one of the rare apps which gets faster and meaner
with every release, instead of getting slower and more bloated like
everyone else.
Also, there is a thing called write barriers, which supposedly could be
used to implement fsync-like behaviour without the penalty, if the disk,
the OS, the controller, and the filesystem support it (that's a lot of
ifs)...
I haven't done this, so YMMV. But the prices are getting
interesting for OLTP where most disks are massively
oversized. The latest Samsung and SanDisk are expensive
in the UK but the Transcend 16GB TS16GSSD25S-S SATA
is about $300 equiv - it can do 'only' 'up to' 28MB/s write and
Gigabyte should revamp their i-RAM to use ECC RAM of a larger capacity...
and longer lasting battery backup...
I wonder, how many write cycles those Flash drives can take before
reliability becomes a problem...
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
