Re: big transaction slows down over time - but disk seems almost unused - Mailing list pgsql-performance

From Ben
Subject Re: big transaction slows down over time - but disk seems almost unused
Date
Msg-id 5D3F6FE2-740B-4D87-A4FF-47378B1969ED@silentmedia.com
Whole thread Raw
In response to big transaction slows down over time - but disk seems almost unused  (Ben <bench@silentmedia.com>)
List pgsql-performance
Memory usage remains consistent, which is to say that postgres is
using most available system memory all the time, as I configured it
to. There is no swapping going on.

It's not clear to me why forcing a WAL checkpoint would help
anything.... but it doesn't matter, as only superusers can do it, so
it's not an option for me. Unless there's a whole other meaning you
were implying....?

On Nov 1, 2006, at 1:21 AM, Andreas Kostyrka wrote:

> Am Dienstag, den 31.10.2006, 21:58 -0800 schrieb Ben:
>> I've got a long-running, update-heavy transaction that
>> increasingly slows
>> down the longer it runs. I would expect that behavior, if there
>> was some
>> temp file creation going on. But monitoring vmstat over the life
>> of the
>> transaction shows virtually zero disk activity. Instead, the
>> system has
>> its CPU pegged the whole time.
>>
>> So.... why the slowdown? Is it a MVCC thing? A side effect of calling
>> stored proceedures a couple hundred thousand times in a single
>
> Memory usage? Have you tried to checkpoint your transaction from
> time to
> time?
>
> Andreas
>
>> transaction? Or am I just doing something wrong?
>>
>> ---------------------------(end of
>> broadcast)---------------------------
>> TIP 5: don't forget to increase your free space map settings


pgsql-performance by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: big transaction slows down over time - but disk seems
Next
From: Andreas Kostyrka
Date:
Subject: Re: big transaction slows down over time - but disk