From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: sblock state on FreeBSD 6.1 |
Date: | 2006-05-03 03:06:59 |
Message-ID: | 9717.1146625619@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Jim C. Nasby" <jnasby(at)pervasive(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas DCP SD | 2006-05-03 07:54:39 | Re: XLOG_BLCKSZ vs. wal_buffers table |
Previous Message | elein | 2006-05-03 02:45:13 | Re: Is a SERIAL column a "black box", or not? |