Re: Just-in-time Background Writer Patch+Test Results
От | Greg Smith |
---|---|
Тема | Re: Just-in-time Background Writer Patch+Test Results |
Дата | |
Msg-id | Pine.GSO.4.64.0709081449431.2440@westnet.com обсуждение исходный текст |
Ответ на | Re: Just-in-time Background Writer Patch+Test Results (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Just-in-time Background Writer Patch+Test Results
Re: Just-in-time Background Writer Patch+Test Results |
Список | pgsql-hackers |
On Sat, 8 Sep 2007, Tom Lane wrote: > I've already gotten flak about the current default of 200ms: > https://bugzilla.redhat.com/show_bug.cgi?id=252129 > I can't imagine that folk with those types of goals will tolerate an > un-tunable 10ms cycle. That's the counter-example for why lowering the default is unacceptable I was looking for. Scratch bgwriter_delay off the list of things that might be fixed to a specific value. Will return to the drawing board to figure out a way to incorporate what I've learned about running at 10ms into a tuning plan that still works fine at 200ms or higher. The good news as far as I'm concerned is that I haven't had to adjust the code so far, just tweak the existing knobs. > In fact, given the numbers you show here, I'd say you should leave the > default cycle time at 200ms. The 10ms value is eating way more CPU and > producing absolutely no measured benefit relative to 200ms... My server is a bit underpowered to run at 10ms and gain anything when doing a stress test like this; I was content that it didn't degrade performance significantly, that was the best I could hope for. I would expect the class of systems that Simon and Heikki are working with could show significant benefit from running the BGW that often. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
В списке pgsql-hackers по дате отправления: