I've switched to PostgreSQL several years ago. Bullet proof, exactly the features I need (and more), and no problems like these. Speaking of, I'm about to upgrade my installations to 9.1 now.
When faced with this situation it seems to me you have three choices at a high level:
- throttle writes closely to your random i/o limit, eliminating your ability to accomodate brief write spikes
- throttle writes less aggressively, accommodating brief spikes but forcing stalls under sustained load as seen here
- don't throttle at all and postpone catching up until commitlog replay on restart, if necessary
None is without downside.
>Hardware: HP ProLiant DL380 G6, with 72GB of RAM and RAID10 on 8 disks.
Playing devil's advocate - there is no proof that PostgreSQL does not have any teething problems on high capacity hardware either.
I'd personally rather buy high end SPARC64 kit which has linear performance scalability but we all know what happened to Sun, plus it doesn't run Windows anyway :( whimpers a little
I have seen throughput issues on VMWare machines (and false reporting on standard linux utilities, eg "time" output and various other issues that make me distrust it for performance-sensitive software), but don't know if this is to do with 128G machines; usually it's to do with contention on one network card handling all traffic to disks.
At Disqus we run Postgres on even larger boxes without pauses described here. We would have (had to) migrate off long ago if this were par for the course.
Not nearly as bad in magnitude, and with some shared responsibility with Linux and file system code (since PG relies of filesystem's caching). Greg Smith talked about it in some detail during PGWest 2010. One of his customers had long stalls in production and Greg worked out how to reproduce and explain them.
He had some patches he was planning for Postgres 9.1, not sure if they went in.
The mentioned spec can be had for roughly $7000 USD, depending on CPU.
http://notemagnet.blogspot.com/2008/08/linux-write-cache-mys...