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

From Daniel Farina
Subject Re: Newbie performance problem - semop taking most of time ?
Date
Msg-id CAAZKuFZSf00V6O7JSmn5=okss7TY9i-nhV0v08amdd3naLH7fQ@mail.gmail.com
Whole thread Raw
In response to Newbie performance problem - semop taking most of time ?  ("mal.oracledba" <mal.oracledba@gmail.com>)
Responses Re: Newbie performance problem - semop taking most of time ?  ("mal.oracledba" <mal.oracledba@gmail.com>)
List 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 by date:

Previous
From: Claudio Freire
Date:
Subject: Re: Cost of opening and closing an empty transaction
Next
From: Sébastien Lorion
Date:
Subject: Re: wal_sync_method on FreeBSD 9.0 - ZFS