Hi Scott,
Thanks for the reply.
Top is showing 10157008 / 15897160 in kernel cache, so postgres is using 37%
right now, following what you are saying. I realize the load isn't peaking
right now, but wouldn't it be nice to have some of the indexes cached in memory?
In your case 1868064 / 2000000 or 7 % of your memory is being used by postgres.
That sort of proves my point. Shouldn't postgres use more than 7% of the
memory. Doesn't that seem like 93% isn't being used?
~DjK
top - 08:59:38 up 277 days, 23:03, 1 user, load average: 0.63, 0.51,
0.40Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombieCpu0 :
0.0% us, 1.0% sy, 0.0% ni, 99.0% id, 0.0% wa, 0.0% hi, 0.0% siCpu1 :
0.0% us, 0.0% sy, 0.0% ni, 99.7% id, 0.3% wa, 0.0% hi, 0.0% siCpu2 :
0.7% us, 0.7% sy, 0.0% ni, 98.3% id, 0.0% wa, 0.0% hi, 0.3% siCpu3 :
0.0% us, 0.0% sy, 0.0% ni, 99.3% id, 0.7% wa, 0.0% hi, 0.0% siMem:
15897160k total, 10477104k used, 5420056k free, 169780k buffersSwap:
16779768k total, 78912k used, 16700856k free, 10157008k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1975
postgres 15 0 33412 7932 1388 S 1.0 0.0 1211:09 postgres: stats
collector process 1971 postgres 15 0 1085m 14m 14m S 0.3 0.1 2323:28
/postgres 1 root 16 0 640 80 48 S 0.0 0.0 0:11.55 init [3]
2 root RT 0 0 0 0 S 0.0 0.0 0:02.30 [migration/0] 3
root 34 19 0 0 0 S 0.0 0.0 0:06.99 [ksoftirqd/0] 4 root
RT 0 0 0 0 S 0.0 0.0 0:00.82 [migration/1] 5 root
34 19 0 0 0 S 0.0 0.0 0:56.60 [ksoftirqd/1] 6 root RT
0 0 0 0 S 0.0 0.0 0:10.71 [migration/2] 7 root 34 19
0 0 0
> Date: Wed, 14 Nov 2007 15:20:53 -0600> From: [EMAIL PROTECTED]> To: [EMAIL
> PROTECTED]> Subject: Re: [ADMIN] cached memory> CC:
> pgsql-admin@postgresql.org> > On Nov 14, 2007 3:13 PM, dx k9 <[EMAIL
> PROTECTED]> 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
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Café. Stop by
today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline
