在 2014/7/29 1:29, Jeff Janes 写道:
If it were waiting on a pg_locks lock, the semop should
be coming from ProcSleep, not from LWLockAcquire,
shouldn't it?
I'm
I hate to be "that guy" but, Is this is still an issue 5 years later?? I
can't seem to get Gin/btree to use my ORDER BY column with a LIMIT no matter
what I try.
My best idea was to cluster the database by the ORDER BY column and then
just hope the index returns them in the order in the table...
On Sun, Jul 27, 2014 at 9:28 AM, Tom Lane wrote:
> Rural Hunter writes:
> >> Does that indicate something? seems it's waiting for some lock.
>
> Yeah, that's what the stack trace suggests. Have you looked into pg_locks
> and pg_stat_activity to see which lock it wants and what's holding said
>
I am now seeing another phenominom of hanging connections. They are
showing 'UPDATE' status in process list.
(gdb) bt
#0 0x7f783f79d4f7 in semop () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x005f97d3 in PGSemaphoreLock ()
#2 0x00638153 in LWLockAcquire ()
#3 0x004a9
This is the vmstat output when the high load peak happens:
# vmstat 3
procs ---memory-- ---swap-- -io -system--
cpu
r b swpd free buff cache si sobibo in cs us sy
id wa
54 1 756868 1047128 264572 34157347200 243 2721 2 51
