Re: Performance monitor signal handler

> Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026