Re: Newbie performance problem - semop taking most of time ?

Поиск
Список
Период
Сортировка
От Daniel Farina
Тема Re: Newbie performance problem - semop taking most of time ?
Дата
Msg-id CAAZKuFZSf00V6O7JSmn5=okss7TY9i-nhV0v08amdd3naLH7fQ@mail.gmail.com
обсуждение исходный текст
Ответ на Newbie performance problem - semop taking most of time ?  ("mal.oracledba" <mal.oracledba@gmail.com>)
Ответы Re: Newbie performance problem - semop taking most of time ?  ("mal.oracledba" <mal.oracledba@gmail.com>)
Список pgsql-performance
On Wed, Sep 19, 2012 at 5:34 AM, mal.oracledba <mal.oracledba@gmail.com> wrote:
> Running hammer ora TPC-C type load. Under 20 user load (no key and think)
> getting approx 180,000 TPM - which is about half of what I get with another
> database vendor.
>
> tracing the process (strace -r) I get outtput like that below - a lot of the
> time seems to be doing semop type operations (eg 0.001299 semop(13369414,
> {{3, -1, 0}}, 1) = 0)
>
> Just wondered if anyone could tell me what is going on there and any
> possibilities that I might have to decrease this wait time ?

I'm don't think system-call traces alone are enough to find a
performance issue; if using a sufficiently new Linux I'd highly
recommend posting the results of the tool 'perf'.  Robert Haas writes
some of his favorite incantations of it here:

http://rhaas.blogspot.com/2012/06/perf-good-bad-ugly.html

You might also want to offer some qualitative information...for
example, does the problem seem to be contention (wherein there is
spare CPU time that should be getting used, but isn't) or maybe just
too many cycles are being expended by Postgres vs Your Other Database
Vendor.

--
fdr


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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Cost of opening and closing an empty transaction
Следующее
От: Sébastien Lorion
Дата:
Сообщение: Re: wal_sync_method on FreeBSD 9.0 - ZFS