On Wed, May 03, 2006 at 01:37:03PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Tue, May 02, 2006 at 11:06:59PM -0400, Tom Lane wrote:
> >> 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.
>
> > Do we take specific steps to ensure that we don't block when attempting
> > to write to these sockets?
>
> Well, we have the socket set to O_NONBLOCK mode. Whether that avoids
> the problem you're seeing ...
A quick grep through the source code doesn't look too promising, so
maybe that's not the proper way not to block on FBSD. Though Larry was
telling me that there's recently been changes made in the socket code,
so maybe this problem was fixed recently.
> > BTW, this server does have command string logging on, so if this is a
> > stats issue that probably made the problem worse.
>
> Can you turn that off for a bit and see if it affects things?
That would require being able to easily reproduce the problem, which I'm
not sure will be possible, since the site was handling over 400
concurrent requests at a time from the web when this happened. That's
why I'm wondering if it might be a better idea to test on another
machine with a copy of the code that's been hacked to send a big pile of
data to the stats process with every query. That would hopefully allow
pgbench to exhibit the same behavior.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461