Skip site navigation (1) Skip section navigation (2)

Re: inefficient use of relation extension?

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: inefficient use of relation extension?
Date: 2009-10-28 20:26:02
Message-ID: 20091028202602.GL5018@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:

> > I regularly (several times a day) see five or six processes all with
> > pg_locks locktype=extend granted=f on the same table, waiting for a long
> > time.
> 
> I'm not sure what's causing that, but I *seriously* doubt that adding
> new pages to FSM right away would make it better.  What it sounds like
> is someone is getting hung up while holding the lock.  You should try to
> investigate who's got the lock when this happens, and what they're doing
> or waiting for.

After some more research, these facts have arisen:

- the relation extension lock in question is on a toast table
- the entries stored in that table are long enough that they need more
than one page
- the BufMappingLock is seen as severely contended among the various
processes trying to extend the table

So the dozen+ processes fight the BufMapping lwlock while attempting to
extend the toast table, to get a free buffer for the new page; do this
one page at a time, and then go back to do the same thing over and over.

Shared_buffers is large (4.6 GB) and I'm not clear if this is just
inefficiency in the 8.1 bufmgr code, or that bgwriter is not aggresive
enough about clearing pages from the LRU end of the buffer pool.

I'm not really sure what the right way to attack this problem is, but
getting off 8.1 has now gotten a priority.

sinval was tracked too and we found out that it's not an issue at all.

Thanks everyone.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Devrim GÜNDÜZDate: 2009-10-28 20:28:09
Subject: Re: alpha2 bundled -- please verify
Previous:From: Josh BerkusDate: 2009-10-28 20:24:29
Subject: Re: Parsing config files in a directory

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group