Running PG 8.1.11 on AIX 5.3
Trying to track down the cause of long running commits on one of our DB
servers.
I can rule checkpoints out (I've set log_min_messages to debug2 and the commits
are not happening during checkpoints).
We have this problem over a period of ~ 35 minutes per day only
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 fo
> 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 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 ch
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 th
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 thi
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
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 si
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 th
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 yo
On Thu, 13 Sep 2007, Brad Nicholson wrote:
One big difference though is that the old array had 16 GB of cache, the
new one has 4 GB.
We have enough IO to spare that we have the bgwriter cranked up pretty
high, dirty buffers are getting quickly.
If your system is very active, running the bgw
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 w
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 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 lo
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 th
15 matches
Mail list logo
