Re: slow startup due to LWLockAssign() spinlock
От | Tom Lane |
---|---|
Тема | Re: slow startup due to LWLockAssign() spinlock |
Дата | |
Msg-id | 32090.1391444565@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | slow startup due to LWLockAssign() spinlock (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: slow startup due to LWLockAssign() spinlock
Re: slow startup due to LWLockAssign() spinlock |
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On larger, multi-socket, machines, startup takes a fair bit of time. As > I was profiling anyway I looked into it and noticed that just about all > of it is spent in LWLockAssign() called by InitBufferPool(). Starting > with shared_buffers=48GB on the server Nate Boley provided, takes about > 12 seconds. Nearly all of it spent taking the ShmemLock spinlock. > Simply modifying LWLockAssign() to not take the spinlock when > !IsUnderPostmaster speeds it up to 2 seconds. While certainly not making > LWLockAssign() prettier it seems enough of a speedup to be worthwile > nonetheless. Hm. This patch only works if the postmaster itself never assigns any LWLocks except during startup. That's *probably* all right, but it seems a bit scary. Is there any cheap way to make the logic actually be what your comment claims, namely "Interlocking is not necessary during postmaster startup"? I guess we could invent a ShmemInitInProgress global flag ... regards, tom lane
В списке pgsql-hackers по дате отправления: