>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.
>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.
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.
http://notemagnet.blogspot.com/2008/08/linux-write-cache-mys...
The mentioned spec can be had for roughly $7000 USD, depending on CPU.
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.