On 05.06.2011 22:04, Stefan Kaltenbrunner wrote:
> and one for the -j80 case(also patched).
>
>
> 485798 48.9667 postgres s_lock
> 60327 6.0808 postgres LWLockAcquire
> 57049 5.7503 postgres LWLockRelease
> 18357 1.8503 postgres hash_search_with_hash_value
> 17033 1.7169 postgres GetSnapshotData
> 14763 1.4881 postgres base_yyparse
> 14460 1.4575 postgres SearchCatCache
> 13975 1.4086 postgres AllocSetAlloc
> 6416 0.6467 postgres PinBuffer
> 5024 0.5064 postgres SIGetDataEntries
> 4704 0.4741 postgres core_yylex
> 4625 0.4662 postgres _bt_compare
Hmm, does that mean that it's spending 50% of the time spinning on a
spinlock? That's bad. It's one thing to be contended on a lock, and have
a lot of idle time because of that, but it's even worse to spend a lot
of time spinning because that CPU time won't be spent on doing more
useful work, even if there is some other process on the system that
could make use of that CPU time.
I like the overall improvement on the throughput, of course, but we have
to find a way to avoid the busy-wait.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
