On Nov 14, 2007 3:13 PM, dx k9 <bitsandbytes88@hotmail.com> wrote:
>
> In looking at some cacti memory usage graphs, the Oracle servers show
> only 6 of a total of16 GB of RAM as 'Total Available'. Whereas, our
> Postgres version 8.24 servers show all 16 GB of RAM totally available or
> free. Some people are asking why Postgres doesn't take that memory and
> lock into it, so you can't see less 'total available' memory. We use a lot
> of B-tree indexes. This may or may not be related, but it there a good way
> to make sure those stay in memory?
Not sure what you mean by totally available. Is the OS using it to
cache? If so, why should postgresql do what the OS already does so
well.
Oracle was written back when OSes were barely more than program
loaders and it had to do everything, from having its own file systems
to buffering / caching to memory management to job schedulers.
PostgreSQL was written as Unix was maturing (mostly) and takes
advantage of all the cool things a modern unix comes with, and one of
those things is kernel level caching of disk files.
So, what does free / top have to say about your memory? And how hard
have these servers been working. For instance, my RHEL4 reporting
server, with only 2 Gigs in it shows 1868064 used as kernel cache.
The rest is mostly pgsql processes