On Tue, 4 Sep 2007, Josh Berkus wrote:
In about 200 benchmark test runs, I don't feel like we ever came up with a
set of bgwriter settings we'd happily recommend to others. SO it's hard
for me to tell whether this is true or not.
Are you talking about 200 runs with 8.2.4 or 8.3? If you've
Greg,
Are you talking about 200 runs with 8.2.4 or 8.3?
8.2.4.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
On Wed, 5 Sep 2007, Josh Berkus wrote:
Are you talking about 200 runs with 8.2.4 or 8.3?
8.2.4.
Right, then we're in agreement here. I did something like 4000 small test
runs with dozens of settings under various 8.2.X releases and my
conclusion was that in the general case, it just
On Wed, Sep 5, 2007 at 1:54 PM, in message
[EMAIL PROTECTED], Greg Smith
[EMAIL PROTECTED] wrote:
On Wed, 5 Sep 2007, Josh Berkus wrote:
While there certainly are some cases where we've heard about people whose
workloads were such that the background writer worked successfully for
them,
Greg,
As far as I'm concerned, that function of the background writer has been
replaced by the load distributed checkpoint features now controlled by
checkpoint_completion_target, which is believed to be a better solution
in several respects. I'm been trying to motivate people happily using
On 8/24/2007 1:17 AM, Greg Smith wrote:
On Thu, 23 Aug 2007, Tom Lane wrote:
It is doubtless true in a lightly loaded system, but once the kernel is
under any kind of memory pressure I think it's completely wrong.
The fact that so many tests I've done or seen get maximum throughput in
terms
On 8/24/2007 8:41 AM, Heikki Linnakangas wrote:
If anyone out there has a repeatable test case where bgwriter does help,
I'm all ears. The theory of moving the writes out of the critical path
does sound reasonable, so I'm sure there is test case to demonstrate the
effect, but it seems to be
On Fri, 31 Aug 2007, Jan Wieck wrote:
Again, the original theory for the bgwriter wasn't moving writes out of the
critical path, but smoothing responsetimes that tended to go completely down
the toilet during checkpointing, causing all the users to wake up and
overload the system entirely.
On Sun, Aug 26, 2007 at 7:35 PM, in message
[EMAIL PROTECTED], Kevin Grittner
[EMAIL PROTECTED] wrote:
On Sun, Aug 26, 2007 at 4:16 PM, in message
[EMAIL PROTECTED], Greg Smith
[EMAIL PROTECTED] wrote:
I'll try to get some more meaningful numbers tomorrow.
Well, I ran the query against
Kevin Grittner [EMAIL PROTECTED] writes:
Is it my imagination, or are we coming pretty close to the point where we
could accomadate the oft-requested feature of dealing directly with a raw
volume, rather than going through the file system at all?
Or O_DIRECT.
I think the answer is that we've
On Sun, Aug 26, 2007 at 12:51 AM, in message
[EMAIL PROTECTED], Greg Smith
[EMAIL PROTECTED] wrote:
On Sat, 25 Aug 2007, Kevin Grittner wrote:
in our environment there tends to be a lot of activity on a singe court
case, and then they're done with it.
I submitted a patch to 8.3 that
On Sun, 26 Aug 2007, Kevin Grittner wrote:
usagecount | count | isdirty
+---+-
0 | 8711 | f
1 | 9394 | f
2 | 1188 | f
3 | 869 | f
4 | 160 | f
5 | 157 | f
Here's a typical sample from your set. Notice how
On Sun, Aug 26, 2007 at 4:16 PM, in message
[EMAIL PROTECTED], Greg Smith
[EMAIL PROTECTED] wrote:
On Sun, 26 Aug 2007, Kevin Grittner wrote:
usagecount | count | isdirty
+---+-
0 | 9093 | f
1 | 6702 | f
2 | 2267 | f
3 |
Greg Smith [EMAIL PROTECTED] writes:
On Sun, 26 Aug 2007, Kevin Grittner wrote:
I also think we need to somehow develop a set of tests which report maximum
response time on (what should be) fast queries while the database is under
different loads, so that those of us for whom reliable
On Fri, Aug 24, 2007 at 5:47 PM, in message
[EMAIL PROTECTED], Greg Smith
[EMAIL PROTECTED] wrote:
On Fri, 24 Aug 2007, Kevin Grittner wrote:
I would be fine with that if I could configure the back end to always write
a
dirty page to the OS when it is written to shared memory. That
On Sat, 25 Aug 2007, Kevin Grittner wrote:
in our environment there tends to be a lot of activity on a singe court
case, and then they're done with it.
I submitted a patch to 8.3 that lets contrib/pg_buffercache show the
usage_count data for each of the buffers. It's actually pretty tiny;
Tom Lane [EMAIL PROTECTED] writes:
Greg Smith [EMAIL PROTECTED] writes:
In the interest of closing work on what's officially titled the Automatic
adjustment of bgwriter_lru_maxpages patch, I wanted to summarize where I
think this is at ...
2) Having backends write their own buffers out
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Greg Smith [EMAIL PROTECTED] writes:
In the interest of closing work on what's officially titled the Automatic
adjustment of bgwriter_lru_maxpages patch, I wanted to summarize where I
think this is at ...
2) Having backends write
Gregory Stark [EMAIL PROTECTED] writes:
How does all of this relate to your epiphany that we should just have
bgwriter be a full clock sweep ahead clock hand without retracing its
steps?
Well, it's still clearly silly for the bgwriter to rescan buffers it's
already cleaned. But I think we've
On Fri, 24 Aug 2007, Tom Lane wrote:
Heikki makes a good point nearby that if you are not disk write
bottlenecked then it's perfectly OK for backends to issue writes, as
it'll just result in a transfer to kernel cache space, and no actual
wait for I/O. And if you *are* write-bottlenecked,
On Fri, Aug 24, 2007 at 7:41 AM, in message
[EMAIL PROTECTED], Heikki Linnakangas
[EMAIL PROTECTED] wrote:
I was not able to find a test where turning bgwriter on performed better
than turning it off.
Any tests which focus just on throughput don't address the problems which
caused us so
Kevin Grittner [EMAIL PROTECTED] writes:
Any tests which focus just on throughput don't address the problems which
caused us so much grief.
This is a good point: a steady-state load is either going to be in the
regime where you're not write-bottlenecked, or the one where you are;
and either way
On Fri, 24 Aug 2007, Kevin Grittner wrote:
I would be fine with that if I could configure the back end to always write a
dirty page to the OS when it is written to shared memory. That would allow
Linux and XFS to do their job in a timely manner, and avoid this problem.
You should take a look
In the interest of closing work on what's officially titled the Automatic
adjustment of bgwriter_lru_maxpages patch, I wanted to summarize where I
think this is at, what I'm working on right now, and see if feedback from
that changes how I submit my final attempt for a useful patch in this area
Greg Smith [EMAIL PROTECTED] writes:
In the interest of closing work on what's officially titled the Automatic
adjustment of bgwriter_lru_maxpages patch, I wanted to summarize where I
think this is at ...
2) Having backends write their own buffers out does not significantly
degrade
On Thu, 23 Aug 2007, Tom Lane wrote:
It is doubtless true in a lightly loaded system, but once the kernel is
under any kind of memory pressure I think it's completely wrong.
The fact that so many tests I've done or seen get maximum throughput in
terms of straight TPS with the background
26 matches
Mail list logo
