Re: Shared Memory Sizing

Curt Sampson wrote:
> On Fri, 28 Jun 2002, Bruce Momjian wrote:
>
> > You have the block in the kernel buffer when you copy it to the
> > PostgreSQL buffers, but nothing says you have to keep that block in the
> > kernel buffers while PostgreSQL has it. Only when it is written does it
> > return to the kernel, and if it is only read, it never returns to the
> > kernel.
>
> Sure. But the OS doesn't know that after you read a block it may
> immediately abandon buffering of that block. It's going to use the
> same strategy it does for any other block, which is to keep it in
> memory for a while, preferring to get rid of older blocks.
>
> If you had a way to tell the OS, "I'm buffering block X, so you
> don't need to" that would be one thing. But you don't.
>
> > > For most workloads, in the long run, that will force you to do disk
> > > I/O that you would not have had to do otherwise. A single disk I/O
> > > is far more expensive than hundreds of copies between the OS buffer
> > > cache and postgres' shared memory.
> >
> > Yes, if you swap, you went too far. That has always been the upper
> > limit.
>
> Not just swap: disk I/O for blocks that would have been buffered
> by the OS if you hadn't been using memory that it could use.

Yes, but how does a smaller PostgreSQL buffer and larger kernel buffer
fix this? It seems it only makes it works because PostgreSQL is loading
its buffers more often.

--
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