"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Just experienced a server that was spending over 50% of CPU time in the
> system, apparently dealing with postmasters that were in the sblock
> state. Looking at the FreeBSD source, this indicates that the process is
> waiting for a lock on a socket. During this time the machine was doing
> nearly 200k context switches a second.
Which operations require such a lock? If plain read/write needs the
lock then heavy contention is hardly surprising.
> Any ideas what areas of the code could be locking a socket?
> Theoretically it shouldn't be the stats collector, and the site is using
> pgpool as a connection pool, so this shouldn't be due to trying to
> connect to backends at a furious rate.
Actually, the stats socket seems like a really good bet to me, since all
the backends will be interested in the same socket. The
client-to-backend sockets are only touched by two processes each, so
don't seem like big contention sources.
regards, tom lane