ok, I've applied that patch and ran. The stall started around 13:50:45...50 and lasted until the end
https://dl.dropbox.com/u/109778/postgresql-2012-11-16_134904-stripped.log 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 >
