|
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.40 Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie Cpu0 : 0.0% us, 1.0% sy, 0.0% ni, 99.0% id, 0.0% wa, 0.0% hi, 0.0% si Cpu1 : 0.0% us, 0.0% sy, 0.0% ni, 99.7% id, 0.3% wa, 0.0% hi, 0.0% si Cpu2 : 0.7% us, 0.7% sy, 0.0% ni, 98.3% id, 0.0% wa, 0.0% hi, 0.3% si Cpu3 : 0.0% us, 0.0% sy, 0.0% ni, 99.3% id, 0.7% wa, 0.0% hi, 0.0% si Mem: 15897160k total, 10477104k used, 5420056k free, 169780k buffers Swap: 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: scott.marlowe@xxxxxxxxx > To: bitsandbytes88@xxxxxxxxxxx > Subject: Re: [ADMIN] cached memory > CC: pgsql-admin@xxxxxxxxxxxxxx > > On Nov 14, 2007 3:13 PM, dx k9 <bitsandbytes88@xxxxxxxxxxx> 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! |
