Обсуждение: About shared cache invalidation mechanism

<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​I know that all invalid cache
messagesare stored in the shmInvalidationBuffer ring buffer and that they should be consumed by all other backends to
keeptheir own cache fresh. Since there may be some "stragglers" which process the SI message quite slow, we use
*catchup*interrupt(signal) to accelerate their cosuming shared invalid messages. Here comes my questions :</div><div
class="gmail_default"style="font-family:arial,helvetica,sans-serif">(1). When the current number of messages in the
shmInvalidationBufferexceeds a threshold, it needs to be cleaned up by using SICleanupQueue. After that, if the number
stillexceeds MAXNUMMESSAGES/2, threshold will be calculated by the following formula：</div><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><spanstyle="background-color:rgb(243,243,243)"><font
color="#ff0000">Threshold= (numMsgs/CLEANUP_QUANTUM + 1) * CLEANUP_QUANTUM</font></span></div><div
class="gmail_default"style="font-family:arial,helvetica,sans-serif"><span
style="background-color:rgb(255,255,255)">(2).For those slow backends, if their *nextMsgNum* value is less than
*lowbound*,they will be reset, and the *lowbound* is calculated by</span></div><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><spanstyle="background-color:rgb(255,255,255)"><font
color="#ff0000">lowbound= maxMsgNum - MAXNUMMESSAGES + minFree,</font></span></div><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><spanstyle="background-color:rgb(255,255,255)">and if their *nextMsgNum*
valueis less than *minsig*, they will get catchup signals to speed up, *minsig* is calculated by</span></div><div
class="gmail_default"style="font-family:arial,helvetica,sans-serif"><span
style="background-color:rgb(255,255,255)"><fontcolor="#ff0000">minsig = maxMsgNum -
MAXNUMMESSAGES/2</font></span></div><divclass="gmail_default" style="font-family:arial,helvetica,sans-serif"><span
style="background-color:rgb(255,255,255)"><br/></span></div><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif"><spanstyle="background-color:rgb(255,255,255)">Here, I want to ask why
threshold,lowbound and minsig are calculated like that ? Do the three formulas have any performance considerations when
designed? I have searched through the old mail list archives, but found nothing about these(these changes emerged in
pg8.4firstly), any help would be appreciated.</span></div></div> 

On Sun, Dec 8, 2013 at 1:55 AM, huaicheng Li <lhcwhu@gmail.com> wrote:
> I know that all invalid cache messages are stored in the
> shmInvalidationBuffer ring buffer and that they should be consumed by all
> other backends to keep their own cache fresh. Since there may be some
> "stragglers" which process the SI message quite slow, we use *catchup*
> interrupt(signal) to accelerate their cosuming shared invalid messages. Here
> comes my questions :
> (1). When the current number of messages in the shmInvalidationBuffer
> exceeds a threshold, it needs to be cleaned up by using SICleanupQueue.
> After that, if the number still exceeds MAXNUMMESSAGES/2, threshold will be
> calculated by the following formula：
> Threshold = (numMsgs/CLEANUP_QUANTUM + 1) * CLEANUP_QUANTUM
> (2). For those slow backends, if their *nextMsgNum* value is less than
> *lowbound*, they will be reset, and the *lowbound* is calculated by
> lowbound = maxMsgNum - MAXNUMMESSAGES + minFree,
> and if their *nextMsgNum* value is less than *minsig*, they will get catchup
> signals to speed up, *minsig* is calculated by
> minsig = maxMsgNum - MAXNUMMESSAGES/2
>
> Here, I want to ask why threshold, lowbound and minsig are calculated like
> that ? Do the three formulas have any performance considerations when
> designed ? I have searched through the old mail list archives, but found
> nothing about these(these changes emerged in pg8.4 firstly), any help would
> be appreciated.

Since the invalidation queue is a ring buffer, it will eventually wrap
around, with new invalidation messages overwriting previously-written
ones.  Once that happens, any backends that hadn't yet processed some
message that's since been overwritten have to be reset.  Since there's
no longer any way of knowing exactly which parts of their
backend-local cache need to be flushed, they'll just have to flush
everything.  That's the point of the lowbound.

However, that's expensive, so we want to prevent it from happening.
To do that, when we notice that a backend is way behind, we send it a
catchup signal.  Hopefully, it will respond to the catchup signal by
reading the messages it hasn't yet processed from the queue.  But if
it doesn't do that, or doesn't do it quickly enough, and more messages
keep arriving, then eventually the queue will wrap around and we'll
have to just reset it.

Does that help?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company