From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jakub Ouhrabka <kuba@comgate.cz>
Cc: pgsql-performance@postgresql.org
Subject: Re: Linux/PostgreSQL scalability issue - problem with 8 cores
Date: Mon, 14 Jan 2008 10:22:14 -0500
Message-ID: <13894.1200324134@sss.pgh.pa.us> (raw)
In-Reply-To: <478B4BB9.4030208@comgate.cz>
References: <flii57$748$1@news.hub.org>
<7083.1199379570@sss.pgh.pa.us>
<477D1D59.7050002@comgate.cz>
<4782063C.7070105@comgate.cz>
<26502.1199745090@sss.pgh.pa.us>
<4782AB4D.8010009@comgate.cz>
<27655.1199750492@sss.pgh.pa.us>
<47836A4C.5080707@comgate.cz>
<10713.1199813111@sss.pgh.pa.us>
<47874EE8.2050406@comgate.cz>
<12997.1200063940@sss.pgh.pa.us>
<478B4BB9.4030208@comgate.cz>
Jakub Ouhrabka <kuba@comgate.cz> writes:
> What does it mean?
Look at src/include/storage/sinval.h and src/include/utils/syscache.h.
What you seem to have here is a bunch of tuple updates in pg_class
(invalidating caches 29 and 30, which in 8.2 correspond to RELNAMENSP
and RELOID), followed by a bunch of SharedInvalRelcacheMsg and
SharedInvalSmgrMsg.
What I find interesting is that the hits are coming against
nearly-successive tuple CTIDs in pg_class, eg these are all
on pages 25 and 26 of pg_class:
> LOG: sending inval msg 30 0 25 45 30036 4294936595
> LOG: sending inval msg 29 0 25 45 30036 2019111801
> LOG: sending inval msg 30 0 26 11 30036 4294936595
> LOG: sending inval msg 29 0 26 11 30036 2019111801
> LOG: sending inval msg 30 0 25 44 30036 4294936597
> LOG: sending inval msg 29 0 25 44 30036 3703878920
> LOG: sending inval msg 30 0 26 10 30036 4294936597
> LOG: sending inval msg 29 0 26 10 30036 3703878920
> LOG: sending inval msg 30 0 26 9 30036 4294936616
> LOG: sending inval msg 29 0 26 9 30036 3527122063
> LOG: sending inval msg 30 0 25 43 30036 4294936616
> LOG: sending inval msg 29 0 25 43 30036 3527122063
The ordering is a little strange --- not sure what's producing that.
I can think of three things that might be producing this:
1. DDL operations ... but most sorts of DDL on a table would touch
more catalogs than just pg_class, so this is a bit hard to credit.
2. VACUUM.
3. Some sort of direct update of pg_class.
The fact that we have a bunch of catcache invals followed by
relcache/smgr invals says that this all happened in one transaction,
else they'd have been intermixed better. That lets VACUUM off the
hook, because it processes each table in a separate transaction.
I am wondering if maybe your app does one of those sneaky things like
fooling with pg_class.reltriggers. If so, the problem might be soluble
by just avoiding unnecessary updates.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, kuba@comgate.cz
Subject: Re: Linux/PostgreSQL scalability issue - problem with 8 cores
In-Reply-To: <13894.1200324134@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox