Re: Performance monitor signal handler

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Only shared memory gives us near-zero cost for write/read. 99% of
> > backends will not be using stats, so it has to be cheap.
>
> Not with a circular buffer it's not cheap, because you need interlocking
> on writes. Your claim that you can get away without that is simply
> false. You won't just get lost messages, you'll get corrupted messages.

How do I get corrupt messages if they are all five bytes? If I write
five bytes, and another does the same, I guess the assembler could
intersperse the writes so the oid gets to be a corrupt value. Any cheap
way around this, perhaps by skiping/clearing the write on a collision?

>
> > The collector program can read the shared memory stats and keep hashed
> > values of accumulated stats. It uses the "Loops" variable to know if it
> > has read the current information in the buffer.
>
> And how does it sleep until the counter has been advanced? Seems to me
> it has to busy-wait (bad) or sleep (worse; if the minimum sleep delay
> is 10 ms then it's guaranteed to miss a lot of data under load).

I figured it could just wake up every few seconds and check. It will
remember the loop counter and current pointer, and read any new
information. I was thinking of a 20k buffer, which could cover about 4k
events.

Should we think about doing these writes into an OS file, and only
enabling the writes when we know there is a collector reading them,
perhaps using a /tmp file to activate recording. We could allocation
1MB and be sure not to miss anything, even with a circular setup.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026