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  (Andres Freund <andres@2ndquadrant.com>)
Re: slow startup due to LWLockAssign() spinlock  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: bgworker crashed or not?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: bgworker crashed or not?