On Thu, Apr 21, 2011 at 3:08 PM, Tory M Blue <tmblue@xxxxxxxxx> wrote: > On Thu, Apr 21, 2011 at 1:04 PM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote: >> On Thu, Apr 21, 2011 at 11:15 AM, Tory M Blue <tmblue@xxxxxxxxx> wrote: >> >>> While I don't mind the occasional slap of reality. This configuration >>> has run for 4+ years. It's possible that as many other components each >>> fedora release is worse then the priors. >> >> How many of those 300 max connections do you generally use? If you've >> always used a handful, or you've used more but they weren't memory >> hungry then you've been lucky. > > max of 45 > >> work_mem is how much memory postgresql can allocate PER sort or hash >> type operation. Each connection can do that more than once. A >> complex query can do it dozens of times. Can you see that going from >> 20 to 200 connections and increasing complexity can result in memory >> usage going from a few megabytes to something like 200 connections * >> 100Megabytes per sort * 3 sorts = 60Gigabytes. >> >>> The Os has changed 170 days ago from fc6 to f12, but the postgres >>> configuration has been the same, and umm no way it can operate, is so >>> black and white, especially when it has ran performed well with a >>> decent sized data set for over 4 years. >> >> Just because you've been walking around with a gun pointing at your >> head without it going off does not mean walking around with a gun >> pointing at your head is a good idea. > > > Yes that is what I gathered. It's good information and I'm always open > to a smack if I learn something, which in this case I did. > > We were already working on moving to 64bit, but again the oom_killer > popping up without the system even attempting to use swap is what has > caused me some pause. Your shared_buffers is way way to high...you have dangerously oversubscribed this system. I would consider dropping down to 256-512mb. Yeah, you have PAE but that only helps so much. Your server can only address so much memory and you allocated a huge chunk of it right off the bat. Also, you might want to consider connection pooler to keep your #backends down, especially if you need to keep work_mem high. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance