Neil Padgett <npadgett@redhat.com> writes:
> Initial results (top five -- if you would like a complete profile, let
> me know):
> Each sample counts as 1 samples.
> % cumulative self self total
> time samples samples calls T1/call T1/call name
> 26.57 42255.02 42255.02 FindLockCycleRecurse
Yipes. It would be interesting to know more about the locking pattern
of your benchmark --- are there long waits-for chains, or not? The
present deadlock detector was certainly written with an eye to "get it
right" rather than "make it fast", but I wonder whether this shows a
performance problem in the detector, or just too many executions because
you're waiting too long to get locks.
> However, this seems to be a red herring. Removing the deadlock detector
> had no effect. In fact, benchmarking showed removing it yielded no
> improvement in transaction processing rate on uniprocessor or SMP
> systems. Instead, it seems that the deadlock detector simply amounts to
> "something to do" for the blocked backend while it waits for lock
> acquisition.
Do you have any idea about the typical lock-acquisition delay in this
benchmark? Our docs advise trying to set DEADLOCK_TIMEOUT higher than
the typical acquisition delay, so that the deadlock detector does not
run unnecessarily.
> For example, there has been some suggestion
> that perhaps some component of the database is causing large lock
> contention.
My thought as well. I would certainly recommend that you use more than
one test case while looking at these things.
regards, tom lane