>Are there a lot of tuples in the table that have been inserted or
updated by still-open transactions?
Yes, there are likely to be inserts. That table is a log capture table
used by our replication software, so essentially every
update/delete/insert will have a record inserted into the table. It
>1. disabling zone_reclaim (echo 0 > /proc/sys/vm/zone_reclaim_mode)
> 2. disabling transparent hugepage support - this has various names on
> different kernel/distributions, but "find /sys | grep -i
> transparent.*hugepage.*enable" will find it, and then just echo never there.
Thank you, yes,
On 2014-06-27 10:51:20 -0700, Jeff Janes wrote:
> On Thu, Jun 26, 2014 at 1:03 PM, Anand Kumar, Karthik
> > Samples: 33K of event 'cycles', Event count (approx.): 20693251070
> > 26.16% postmaster postgres [.] 0x00188450
> > 21.13% postmaster postgres [.] h
On Thu, Jun 26, 2014 at 1:03 PM, Anand Kumar, Karthik
wrote:
> Hi,
>
> We run postgres 9.3.3 on Centos 6.3, kernel 2.6.32-431.3.1. Every once in a
> while, we see postgres processes spinning on semop:
Are there a lot of tuples in the table that have been inserted or
updated by still-open transact
On Thu, Jun 26, 2014 at 10:03 PM, Anand Kumar, Karthik <
karthik.anandku...@classmates.com> wrote:
> We run postgres 9.3.3 on Centos 6.3, kernel 2.6.32-431.3.1. Every once in
> a while, we see postgres processes spinning on semop:
>
it might be long shot, but when we had problems with lots of bac
Hi,
We run postgres 9.3.3 on Centos 6.3, kernel 2.6.32-431.3.1. Every once in a
while, we see postgres processes spinning on semop:
Here is an output from an strace on a delete process:
root@site-db01a:~ # strace -p 53744
Process 53744 attached - interrupt to quit
semop(21692498, {{6, 1, 0}}, 1
