| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Andomar <andomar(at)aule(dot)net>, <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: Waiting on ExclusiveLock on extension |
| Date: | 2015-04-19 20:18:32 |
| Message-ID: | 55340D98.40601@BlueTreble.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On 4/19/15 3:08 PM, Jim Nasby wrote:
>> > I do suspect your pgfree/s is very high though; putting 200k
>> pages/s on
>> > the free list seems like something's broken.
>> >
>> The system has constant and considerable load of small writes. The
>> pg_activity tool shows 300 IOPs sustained (it claims max IPs above
>> 11000.) Postgres 9.3 had a comparable pgfree/s.
>
> That leads me to a new theory... you may be running into problems
> finding free buffers in the buffer pool. We need to have a buffer before
> we can extend a relation, and if you have a lot of pressure on shared
> buffers it can take quite a bit of CPU to find one. To make matters
> worse, that search for a buffer takes place while holding the extension
> lock.
>
> Would you be able to get a stack trace of a backend that's holding an
> extension lock? Or maybe perf would provide some insight.
BTW,
http://postgresql.org/message-id/flat/20150329185619(dot)GA29062(at)alap3(dot)anarazel(dot)de
has some useful info about this.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tim Uckun | 2015-04-20 02:53:31 | Re: Help with slow table update |
| Previous Message | Jim Nasby | 2015-04-19 20:08:38 | Re: Waiting on ExclusiveLock on extension |