Thanks Michael. Are you saying the 'used' column is the irrelevant number? Is the number that is more pertinent is 1416880? Is that the actual amount of memory in use? I agree about the allocation of a bogus amount of memory but the issue occurred after-hours when the application(s) were not running. Or are you saying the app whacked the DB during the day and never recovered?
Tim
-----Original Message-----
From: pgsql-performance-owner@xxxxxxxxxxxxxx [mailto:pgsql-performance-owner@xxxxxxxxxxxxxx] On Behalf Of Michael Stone
Sent: Friday, May 05, 2006 10:41 AM
To: pgsql-performance@xxxxxxxxxxxxxx
Subject: Re: [PERFORM] Memory and/or cache issues?
On Fri, May 05, 2006 at 10:27:10AM -0400, mcelroy, tim wrote:
>Sorry, been up all night and maybe provided too much information or not the
>right information and only confused folks, tired I guess. When I say 'in
>use' I am referring to the 'used' column.
Which is a mostly irrelevant number.
>Here's free from PROD001:
>[root@wbibsngwyprod001 kernel]# free -k -t
> total used free shared buffers cached
>Mem: 7643536 6975772 667764 0 165496 5393396
>-/+ buffers/cache: 1416880 6226656
>Swap: 8185108 5208 8179900
>Total: 15828644 6980980 8847664
You've got 1.4G in use, 5.3G of disk cache, 165M of buffers and 667M
free. That doesn't seem unreasonable. If an application needs more
memory the amount of disk cache will decrease. As I said in an earlier
email, the problem is that the application is trying to allocate a bogus
amount of memory, not that you have a memory problem.
Mike Stone
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
