>>> 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 f
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 didn't
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
http://www.postgresql.org
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 co
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 usi
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.
A
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 prett
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 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
"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 reli
>>> 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 |
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 yo
>>> 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 t
"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
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; yo
>>> 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 memor
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
"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 eithe
>>> 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
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, the
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
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) H
"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 o
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 write
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
> degrad
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 are
26 matches
Mail list logo