Re: slow startup due to LWLockAssign() spinlock
От | Andres Freund |
---|---|
Тема | Re: slow startup due to LWLockAssign() spinlock |
Дата | |
Msg-id | 20140203235849.GB12016@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: slow startup due to LWLockAssign() spinlock (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: slow startup due to LWLockAssign() spinlock
|
Список | pgsql-hackers |
On 2014-02-03 11:22:45 -0500, Tom Lane wrote: > 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 ... So, here's a flag implementing things with that flag. I kept your name, as it's more in line with ipci.c's naming, but it looks kinda odd besides proc_exit_inprogress. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: