Re: sblock state on FreeBSD 6.1

On Thu, May 11, 2006 at 07:39:23PM +0200, Martijn van Oosterhout wrote:
> On Thu, May 11, 2006 at 12:09:56PM -0500, Jim C. Nasby wrote:
> > Unfortunately, I suspect some of these were grabbed after the process
> > had already moved past whatever was holding it in sblock.
> >
> > Here's the traces that we captured...
> >
> > Got 2 of these:
> > #0 0x000000080135bd2c in recvfrom () from /lib/libc.so.6
> > #1 0x00000000004f9898 in secure_read (port=0x834800, ptr=0x7cebe0, len=8192) at be-secure.c:320
>
> This is an idle backend waiting for the user.

So why would that be waiting to lock the socket? My understanding is
that nothing else should be contending for that socket, no?

> > #0 0x000000080137638c in sendto () from /lib/libc.so.6
> > #1 0x0000000000535e67 in pgstat_report_tabstat () at pgstat.c:846
>
> This definitly the statistics collector, which is something that was
> speculated upthread. Do you get a lot of these?

I included everything that was captured, but of course that's only a
small sampling. If it's helpful we could probably setup something that
would automatically grab stack traces for a larger number of backends
and then see how many were in that state.

What's interesting is that while we were able to re-create the same
state, this time we didn't see any messages in the log about the
statistics collector filling it's buffer.

BTW, I should point out that the goal is to try and ensure that the
machine doesn't end up in a state where all the CPU is going to system
calls, but I'm suspecting that maybe this is an OS issue and not a
PostgreSQL issue at this point...

> > I suspect the rest of these probably happened after the sblock state had
> > cleared, but here they are anyway in case I'm wrong. Also, I removed the
> > 'incriminating evidence' from the query strings; there wasn't anything
> > unusual about those queries, so I don't think it should matter.
>
> The rest look like backends going through normal query functions...
> There was one waiting for a lock but that's unlikely to be
> significant...

Yeah, my suspicion is that those processes had moved past waiting on the
socket lock by the time gdb got to them. Any idea of how you could tell
what state (as reported by top) the process was in when gdb stopped it?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461