Re: sblock state on FreeBSD 6.1

"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