Re: [Testperf-general] Re: First set of OSDL Shared Memscalability results, some wierdness ...

> Bruce Momjian
> Tom Lane wrote:
> > > I've been thinking about implementing a scheme that helps you
> decide how
> > > big the shared_buffers SHOULD BE, by making the LRU list
> bigger than the
> > > cache itself, so you'd be able to see whether there is
> beneficial effect in
> > > increasing shared_buffers.
> >
> > ARC already keeps such a list --- couldn't you learn what you want to
> > know from the existing data structure? It'd be fairly cool if we could
> > put out warnings "you ought to increase shared_buffers" analogous to the
> > existing facility for noting excessive checkpointing.

First off, many thanks for taking the time to provide the real detail on the
code.

That gives us some much needed direction in interpreting the oprofile
output.

>
> Agreed. ARC already keeps a list of buffers it had to push out recently
> so if it needs them again soon it knows its sizing of recent/frequent
> might be off (I think). Anyway, such a log report would be super-cool,
> say if you pushed out a buffer and needed it very soon, and the ARC
> buffers are already at their maximum for that buffer pool.
>

OK, I guess I hadn't realised we were half-way there.

The "increase shared_buffers" warning would be useful, but it would be much
cooler to have some guidance as to how big to set it, especially since this
requires a restart of the server.

What I had in mind was a way of keeping track of how the buffer cache hit
ratio would look at various sizes of shared_buffers, for example 50%, 80%,
120%, 150%, 200% and 400% say. That way you'd stand a chance of plotting the
curve and thereby assessing how much memory could be allocated. I've got a
few ideas, but I need to check out the code first.

I'll investigate both simple/complex options as an 8.1 feature.

Best Regards, Simon Riggs