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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
