Re: Planning a new server - help needed
От | Greg Smith |
---|---|
Тема | Re: Planning a new server - help needed |
Дата | |
Msg-id | Pine.GSO.4.64.0803300031060.5780@westnet.com обсуждение исходный текст |
Ответ на | Re: Planning a new server - help needed (PFC <lists@peufeu.com>) |
Ответы |
Re: Planning a new server - help needed
|
Список | pgsql-performance |
On Sat, 29 Mar 2008, PFC wrote: >> 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 I recall seeing many designs with more platters that have slower seek times in benchmarks, and I always presumed this was the reason. That's the basis for that comment. I'll disclaim that section a bit. > 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've seen some really heavy workloads where using async commit helped group commits in a larger batches usefully, but I personally haven't found it to be all that useful if you're already got a caching controller to accelerate writes on the kinds of hardware most people have. It's a great solution for situations without a usable write cache though. > 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)... The database can't use fsync-like behavior for the things it calls fsync for; it needs the full semantics. You're either doing the full operation, or you're cheating and it doesn't do what it's supposed to. Write barriers aren't any improvement over a good direct I/O sync write setup for the WAL. There may be some limited value to that approach for the database writes at checkpoint time, but again there's a real fsync coming at the end of that and it's not satisfied until everything is on disk (or in a good disk controller cache). > Gigabyte should revamp their i-RAM to use ECC RAM of a larger > capacity... and longer lasting battery backup... I saw a rumor somewhere that they were close to having a new version of that using DDR2 ready, which would make it pretty easy to have 8GB on there. > I wonder, how many write cycles those Flash drives can take before > reliability becomes a problem... The newer SSD drives with good write leveling should last at least as long as you'd expect a mechanical drive to, even in a WAL application. Lesser grades of flash used as disk could be a problem though. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-performance по дате отправления: