3 ms·
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 -
by sc68cal 15y ago
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.
- pointyhat 15y agoThe 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
- trafficlight 15y agoI 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?
- pointyhat 15y agoSome bits buried in here: http://frankdenneman.nl/2010/02/sizing-vms-and-numa-nodes/ http://frankdenneman.nl/2010/02/sizing-vms-and-numa-nodes/
- zwischenzug 15y agoI'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.
- jeremyw 15y agoBe careful of your NUMA boundaries. 20-30% is exactly the cross-bank access cost.
- pointyhat 15y agoThat's what I was thinking. Need some analysis on it really. We throw money at the problem at the moment and it goes away :)
- spudlyo 15y agoThat'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 http://www.linuxmanpages.com/man8/numactl.8.php
- bretthoerner 15y ago> 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.
- gleb 15y agoThere 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.
- spudlyo 15y agoIs 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.
- moe 15y agoThat's not "high capacity", it's a mid-range box. The mentioned spec can be had for roughly $7000 USD, depending on CPU.
- sciurus 15y agoThe answer is that yes, Postgres can have a similar problem. http://notemagnet.blogspot.com/2008/08/linux-write-cache-mystery.html http://notemagnet.blogspot.com/2008/08/linux-write-cache-mys...