Re: Repeated semop calls

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Repeated semop calls
Дата
Msg-id CAMkU=1xtjYA2k5E9eJemJ9FnDL3FSC8en3B8ae5k-eL4+yScdA@mail.gmail.com
обсуждение исходный текст
Ответ на Repeated semop calls  ("Anand Kumar, Karthik" <Karthik.AnandKumar@classmates.com>)
Ответы Re: Repeated semop calls
Re: Repeated semop calls
Список pgsql-general
On Thu, Jun 26, 2014 at 1:03 PM, Anand Kumar, Karthik
<Karthik.AnandKumar@classmates.com> 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 transactions?  Such tuples can cause contention
when other processes need to check them for visibility.

You might want to upgrade and see if that fixes it, as there was a
partial fix in 9.3.4 for this (It fixed the problem where it occurred
in the planning done in the BIND phase when the unresolved tuples were
at the ends of an index).

>
> Running a perf on the process showed this:
>
> Samples: 33K of event 'cycles', Event count (approx.): 20693251070
>  26.16%  postmaster  postgres               [.] 0x0000000000188450
>  21.13%  postmaster  postgres               [.] hash_search_with_hash_value
>  10.47%  postmaster  postgres               [.] heap_page_prune_opt
>   4.21%  postmaster  postgres               [.] LWLockAcquire
>   3.71%  postmaster  postgres               [.] slot_getattr
>   1.97%  postmaster  postgres               [.] HeapTupleSatisfiesMVCC

If it is what I am guessing at, then the top anonymous address is
probably coming from LWLockAcquire, and those are coming from
HeapTupleSatisfiesMVCC.  I don't know how to verify that, though.

Cheers,

Jeff


В списке pgsql-general по дате отправления:

Предыдущее
От: David G Johnston
Дата:
Сообщение: Re: Fast data, slow data
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Repeated semop calls