Re: Linux/PostgreSQL scalability issue - problem with 8 cores - Mailing list pgsql-performance

From Tom Lane
Subject Re: Linux/PostgreSQL scalability issue - problem with 8 cores
Date
Msg-id 26502.1199745090@sss.pgh.pa.us
Whole thread Raw
In response to Re: Linux/PostgreSQL scalability issue - problem with 8 cores  (Jakub Ouhrabka <kuba@comgate.cz>)
List pgsql-performance
Jakub Ouhrabka <kuba@comgate.cz> writes:
> We've tried several times to get stacktrace from some of the running
> backends during spikes, we got always this:

> 0x00002b005d00a9a9 in semop () from /lib/libc.so.6
> #0  0x00002b005d00a9a9 in semop () from /lib/libc.so.6
> #1  0x000000000054fe53 in PGSemaphoreLock (sema=0x2b00a04e5090,
> interruptOK=0 '\0') at pg_sema.c:411
> #2  0x0000000000575d95 in LWLockAcquire (lockid=SInvalLock,
> mode=LW_EXCLUSIVE) at lwlock.c:455
> #3  0x000000000056fbfe in ReceiveSharedInvalidMessages
> (invalFunction=0x5e9a30 <LocalExecuteInvalidationMessage>,
>     resetFunction=0x5e9df0 <InvalidateSystemCaches>) at sinval.c:159
> #4  0x0000000000463505 in StartTransactionCommand () at xact.c:1439
> #5  0x000000000056fa4b in ProcessCatchupEvent () at sinval.c:347
> #6  0x000000000056fb20 in CatchupInterruptHandler
> (postgres_signal_arg=<value optimized out>) at sinval.c:221

CatchupInterruptHandler, eh?  That seems to let NOTIFY off the hook, and
instead points in the direction of sinval processing; which is to say,
propagation of changes to system catalogs.  Does your app create and
destroy a tremendous number of temp tables, or anything else in the way
of frequent DDL commands?

            regards, tom lane

pgsql-performance by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: concurrent inserts into two separate tables are very slow
Next
From: Sergei Shelukhin
Date:
Subject: Re: concurrent inserts into two separate tables are very slow