Re: BUG #4575: All page cache in shared_buffers pinned (duplicated by OS, always)

Thanks Tom, Gregory, and Pavan,

I have looked into this on a few other sysstems and what I first thought was a Linux issue, then thought was Postgres related, looks more like Linux again. There is a combination of more memory than expected not being able to drop from the OS page cache, and some odd numbers being reported by 'free', or even the /proc raw data. It all doesn't add up to what the documentation claims it does.

I am unaware of anything that may pin pages in os cache from userland, but am certainly not completely knowledgeable on all the things possible in that realm. Now that I am comfortable that you understand the symptoms I see, and you are confident its elsewhere, I trust that the issue's cause must be elsewhere.

Thanks!

-Scott

On 12/11/08 1:16 PM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

Scott Carey <scott(at)richrelevance(dot)com> writes:
> I am 99.9% certian its not a fluke of "top" (or 'free'). Or a fluke with the drop_caches linux vm signal. Otherwise, the system would not spin at 100% System cpu getting no work done if an attempt to allocate memory above that threshold, the original symptom that led me down this path of investigation.

That's certainly a kernel bug.

> If there are any ideas on how I could truly distinguish where this bug actually is, or further characterize it in ways that would be useful to that end, that would be great.

It's in the kernel. Userland doesn't have any way to "pin" OS disk cache
pages in memory, which AFAICT is what you are claiming happens.

regards, tom lane