On Thu, Oct 19, 2006 at 06:00:54PM +0200, Tobias Brox wrote: > [Jim C. Nasby - Thu at 10:28:31AM -0500] > > I think it'd be much better to experiment with using much larger > > shared_buffers settings. The conventional wisdom there is from 7.x days > > when you really didn't want a large buffer, but that doesn't really > > apply with the new buffer management we got in 8.0. I know of one site > > that doubled their performance by setting shared_buffers to 50% of > > memory. > > Oh, that's interessting. I will give it a shot. Our config is > "inheritated" from the 7.x-days, so we have a fairly low setting > compared to available memory. From the 7.x-days the logic was that "a > lot of careful thought has been given when designing the OS cache/buffer > subsystem, we don't really want to reinvent the wheel" or something like > that. Yeah, test setups are a good thing to have... > Sadly it's not easy to measure the overall performance impact of such > tunings in a production environment, so such a setting tends to be tuned > by religion rather than science :-) > > > Something else to consider is that many people will put pg_xlog on the > > same drives as the OS (and swap). It's pretty important that those > > drives not have much activity other than pg_xlog, so any swap activity > > would have an even larger than normal impact on performance. > > Hm ... that's actually our current setting, we placed the postgres > database itself on a separate disk, not the xlog. So we should have > done it the other way around? No wonder the performance is badly > affected by backups etc ... Well, typically I see setups where people dedicate say 6 drives to the data and 2 drives for the OS and pg_xlog. The issue with pg_xlog is you don't need bandwidth... you need super-low latency. The best way to accomplish that is to get a battery-backed RAID controller that you can enable write caching on. In fact, if the controller is good enough, you can theoretically get away with just building one big RAID10 and letting the controller provide the low-latency fsyncs that pg_xlog depends on. -- Jim Nasby jim@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
