Re: Low values for cached size

From: Carlos Henrique Reimer <carlos(dot)reimer(at)opendb(dot)com(dot)br>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Low values for cached size
Date: 2009-09-25 23:47:49
Message-ID: 2f136390909251647j709b586aj9671fc480f4196ed@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Scott,

The top and M option:

top - 20:37:52 up 8:19, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 96 total, 1 running, 95 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.5%id, 0.3%wa, 0.0%hi, 0.0%si,
0.0%st
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4011 postgres 18 0 298m 276m 251m S 0 7.8 0:40.16 postgres
2950 postgres 15 0 271m 232m 231m S 0 6.6 0:01.06 postgres
2938 postgres 18 0 271m 7120 6748 S 0 0.2 0:00.31 postgres
3012 root 18 0 10852 5644 1588 S 0 0.2 0:00.01 miniserv.pl
2660 root 15 0 13448 4616 968 S 0 0.1 0:00.01 python
2732 ntp 15 0 4316 4316 3312 S 0 0.1 0:00.04 ntpd
2397 root 12 -3 10100 3860 2272 S 0 0.1 0:00.08 python
2870 haldaemo 18 0 5700 3724 1608 S 0 0.1 0:01.51 hald
5917 root 18 0 10424 2804 1388 S 0 0.1 0:00.00 httpd
5992 root 15 0 9000 2724 2204 S 0 0.1 0:00.03 sshd
5140 root 16 0 8996 2720 2204 S 0 0.1 0:00.04 sshd
5918 apache 23 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5920 apache 23 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5921 apache 23 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5922 apache 23 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5923 apache 25 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5924 apache 25 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5925 apache 25 0 10424 2084 632 S 0 0.1 0:00.00 httpd
5926 apache 25 0 10424 2084 632 S 0 0.1 0:00.00 httpd
2696 root 18 0 9676 1968 1360 S 0 0.1 0:00.00 cupsd
2757 root 15 0 9028 1860 776 S 0 0.1 0:00.00

Thank you!

sendmail2009/9/25 Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>

> On Fri, Sep 25, 2009 at 3:28 PM, Carlos Henrique Reimer
> <carlos(dot)reimer(at)opendb(dot)com(dot)br> wrote:
> > 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(at)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(at)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?
>
> If you run top, then hit M, and post the first 20 or so rows after
> what you have here I can take a guess.
>

--
Reimer
47-3457-0881 47-9183-0547 msn: carlosreimer(at)hotmail(dot)com
skype: carlosreimer

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Merlin Moncure 2009-09-26 00:27:59 Re: stored procedure: RETURNS record
Previous Message Ron Mayer 2009-09-25 23:35:24 Re: generic modelling of data models; enforcing constraints dynamically...