Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Are you running an equivalent hardware setup? Similar to:

>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.



> Are you running an equivalent hardware setup? > 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.


There is similar problem in Postgres as well.

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.


Is your database extremely write heavy? You don't usually see this problem in a more balanced read/write workload. Postgres has in the past suffered from stalls and lockups that can happen at checkpoint intervals, but it appears they mostly happen for seconds rather than minutes.


The answer is that yes, Postgres can have a similar problem.

http://notemagnet.blogspot.com/2008/08/linux-write-cache-mys...


That's not "high capacity", it's a mid-range box.

The mentioned spec can be had for roughly $7000 USD, depending on CPU.


The issue is x86/x64 being a turd. Throughput of just about everything drops when you go over the 36Gb boundary for some reason. I have no idea why. It can drop by as much as 30%. This is from experience operating VMware on the physically the same type of kit (except with FC SAN / NetApp).

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


Be careful of your NUMA boundaries. 20-30% is exactly the cross-bank access cost.


That's what I thought too. There are a lot of weird problems that can happen due to NUMA architecture issues. Reading the numactl for me really drives home just how much I don't understand it.

http://www.linuxmanpages.com/man8/numactl.8.php


That's what I was thinking. Need some analysis on it really. We throw money at the problem at the moment and it goes away :)


I've seen DBs run on 128G machines on x6 and have no experience of such problems. Do you have a link or hard evidence of this?

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.


I haven't heard/experienced the 36 GB thing since I don't run anything that big right now. Are you aware of any websites or blog posts that talk about it?





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: