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
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
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 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...
在 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
