On 06/05/2011 09:12 PM, Heikki Linnakangas wrote: > 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.
well yeah - we are broken right now with only being able to use ~20% of CPU on a modern mid-range box, but using 80% CPU (or 4x like in the above case) and only getting less than 2x the performance seems wrong as well. I also wonder if we are still missing something fundamental - because even with the current patch we are quite far away from linear scaling and light-years from some of our competitors... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
