the actual log has more data (including statement following each 'spin delay' record), but there is some sensitive info inside which I can't share with public.
-- Vlad
yup. this problem doesn't smell like lwlock issues. typically there
the problem manifests as low cpu performance, everybody waits. classic spinlock contention (at least from what i've seen) is very high *userspace* cpu utilization and low work output. this time it's different -- OP is bogging in the kernel so it's not impossible we're troubleshooting the symptom, not the cause.
> In 9.3 there is a new field that tells how many spin delays there were > on the mutex that is behind each lock. That was commit > b79ab00144e64217d41, maybe he can port that back to his version. > > But that only tells you about LWLock mutexes, not about all the other > ones in PG. > > The attached patch logs every spin delay with where in the source it comes from.
yeah, OP should fire this off. good stuff. I'll bet lunch (if we ever happen to meet) it's on buffer pin. merlin
