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

From: Daniel Farina <daniel(at)heroku(dot)com>
To: "mal(dot)oracledba" <mal(dot)oracledba(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Newbie performance problem - semop taking most of time ?
Date: 2012-09-22 05:50:25
Message-ID: CAAZKuFZSf00V6O7JSmn5=okss7TY9i-nhV0v08amdd3naLH7fQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, Sep 19, 2012 at 5:34 AM, mal.oracledba <mal(dot)oracledba(at)gmail(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Sébastien Lorion 2012-09-22 14:01:20 Re: wal_sync_method on FreeBSD 9.0 - ZFS
Previous Message Claudio Freire 2012-09-22 03:08:15 Re: Cost of opening and closing an empty transaction