Re: [PATCHES] ARC Memory Usage analysis

On Wed, 26 Oct 2004, Greg Stark wrote:

> > I don't see why mmap is any more out of reach than O_DIRECT; it's not
> > all that much harder to implement, and mmap (and madvise!) is more
> > widely available.
>
> Because there's no way to prevent a write-out from occurring and no way to be
> notified by mmap before a write-out occurs, and Postgres wants to do its WAL
> logging at that time if it hasn't already happened.

I already described a solution to that problem in a post earlier in this
thread (a write queue on the block). I may even have described it on
this list a couple of years ago, that being about the time I thought
it up. (The mmap idea just won't die, but at least I wasn't the one to
bring it up this time. :-))

> Well firstly it depends on the work profile. It can probably get much higher
> than we saw in that profile....

True, but 1% was is much, much lower than I'd expected. That tells me
that my intuitive idea of the performance model is wrong, which means,
for me at least, it's time to shut up or put up some benchmarks.

> Secondly it also reduces the amount of cache available. If you have 256M of
> ram with about 200M free, and 40Mb of ram set aside for Postgres's buffer
> cache then you really only get 160Mb. It's costing you 20% of your cache, and
> reducing the cache hit rate accordingly.

Yeah, no question about that.

> Thirdly the kernel doesn't know as much as Postgres about the load. Postgres
> could optimize its use of cache based on whether it knows the data is being
> loaded by a vacuum or sequential scan rather than an index lookup. In practice
> Postgres has gone with ARC which I suppose a kernel could implement anyways,
> but afaik neither linux nor BSD choose to do anything like it.

madvise().

cjs
--
Curt Sampson <cjs(at)cynic(dot)net> +81 90 7737 2974 http://www.NetBSD.org
Make up enjoying your city life...produced by BIC CAMERA