Re: Planning a new server - help needed - Mailing list pgsql-performance
From | PFC |
---|---|
Subject | Re: Planning a new server - help needed |
Date | |
Msg-id | op.t8r6d212cigqcu@apollo13.peufeu.com Whole thread Raw |
In response to | Re: Planning a new server - help needed (James Mansion <james@mansionfamily.plus.com>) |
Responses |
Re: Planning a new server - help needed
Re: Planning a new server - help needed Re: Planning a new server - help needed |
List | pgsql-performance |
> 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...
pgsql-performance by date: