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" <t...@sss.pgh.pa.us> wrote:
Scott Carey <sc...@richrelevance.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
