Low values for cached size - Mailing list pgsql-general

From Carlos Henrique Reimer
Subject Low values for cached size
Date
Msg-id 2f136390909251428n420da878gaeade44f131d72cd@mail.gmail.com
Whole thread Raw
Responses Re: Low values for cached size  (Scott Marlowe <scott.marlowe@gmail.com>)
List pgsql-general
Hi,
 
We're facing performance problems in a Linux box running CentOS release 5 (Final) and PostgreSQL 8.2.4. I've done some basic checks in the configuration but everything looks fine to me. One weird behaviour I've found is the cached size showed by the
"top" and "free" Linux commands:


top - 08:32:17 up 3 days, 19:04,  1 user,  load average: 1.09, 1.07, 1.10
Tasks: 173 total,   2 running, 170 sleeping,   0 stopped,   1 zombie
Cpu(s):  9.5%us,  0.5%sy,  0.0%ni, 88.2%id,  1.7%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3631900k total,  3378056k used,   253844k free,    25488k buffers
Swap:  4192956k total,      100k used,  4192856k free,  2356588k cached

[postgres@server01 etc]$ free
             total       used       free     shared    buffers     cached
Mem:       3631900    3174804     457096          0      14280    2086184
-/+ buffers/cache:    1074340    2557560
Swap:      4192956        108    4192848
[postgres@server01 etc]$

Both commands show values ranging from 2GB to 2.3GB for the cached size and the server has 3.5GB RAM. I do usally see  cached values with sizes bearing the size of the RAM in other servers. It seams that something is consuming the RAM and not letting it free to be used as cache for Linux files, right?
The shared_buffers (256MB) is not high and I can not see a reason for this. Initially I've thought the problem was
because the system was running with runlevel 5, but now, it's running with runlevel 3 and even so the values for
cached size does not change.

Any suggestions or directions I could follow to discover the reason?

Reimer


--
Reimer
47-3457-0881 47-9183-0547 msn: carlosreimer@hotmail.com
skype: carlosreimer

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: lazy vacuum and AccessExclusiveLock
Next
From: Tom Lane
Date:
Subject: Re: lazy vacuum and AccessExclusiveLock