On 13/09/2007, Greg Smith [EMAIL PROTECTED] wrote:
Every time the all scan writes a buffer that is frequently used, that
write has a good chance that it was wasted because the block will be
modified again before checkpoint time. Your settings are beyond regular
aggressive and into the
On 14/09/2007, Peter Childs [EMAIL PROTECTED] wrote:
On 13/09/2007, Greg Smith [EMAIL PROTECTED] wrote:
Every time the all scan writes a buffer that is frequently used, that
write has a good chance that it was wasted because the block will be
modified again before checkpoint time.
I'm having a problem with long running commits appearing in my database
logs. It may be hardware related, as the problem appeared when we moved
the database to a new server connected to a different disk array. The
disk array is a lower class array, but still more than powerful enough
to
On Fri, 14 Sep 2007, Peter Childs wrote:
Are you suggesting that reducing bgwriter_delay and bg_writer_percent
would reduce the time spent doing commits? I get quite a few commits
that take over 500ms (the point when i start logging queries).
One very common cause for transactions blocking
I'm having a problem with long running commits appearing in my database
logs. It may be hardware related, as the problem appeared when we moved
the database to a new server connected to a different disk array. The
disk array is a lower class array, but still more than powerful enough
to handle
On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
I'm having a problem with long running commits appearing in my database
logs. It may be hardware related, as the problem appeared when we moved
the database to a new server connected to a different disk array. The
disk array is a lower
Brad Nicholson [EMAIL PROTECTED] writes:
On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
I'm having a problem with long running commits appearing in my database
logs. It may be hardware related, as the problem appeared when we moved
the database to a new server connected to a
On Thu, 2007-09-13 at 11:10 -0400, Tom Lane wrote:
Brad Nicholson [EMAIL PROTECTED] writes:
On Thu, 2007-09-13 at 10:15 -0400, Brad Nicholson wrote:
I'm having a problem with long running commits appearing in my database
logs. It may be hardware related, as the problem appeared when we
On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
On Thu, 13 Sep 2007, Brad Nicholson wrote:
I'd be curious to see how you've got your background writer configured to
see if it matches situations like this I've seen in the past. The
parameters controlling the all scan are the ones you'd
On Thu, 2007-09-13 at 12:19 -0400, Brad Nicholson wrote:
On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
On Thu, 13 Sep 2007, Brad Nicholson wrote:
I'd be curious to see how you've got your background writer configured to
see if it matches situations like this I've seen in the past.
Brad Nicholson wrote:
On Thu, 2007-09-13 at 12:19 -0400, Brad Nicholson wrote:
On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
On Thu, 13 Sep 2007, Brad Nicholson wrote:
I'd be curious to see how you've got your background writer configured to
see if it matches situations like
On Thu, 2007-09-13 at 12:12 -0400, Greg Smith wrote:
Since you're probably not monitoring I/O waits and similar statistics on
how the disk array's cache is being used, whether this is happening or not
to you won't be obvious from what the operating system is reporting.
A sysadmin looked
On Thu, 13 Sep 2007, Brad Nicholson wrote:
A sysadmin looked at cache usage on the disk array. The read cache is
being used heavily, and the write cache is not.
Given that information, you can take the below (which I was just about to
send before the above update came in) as something to
13 matches
Mail list logo
