SEO

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. Thanks all who have responded to
this inquiry, I appreciate it.

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

Here's free from PROD002:
[root@wbibsngwyprod002 root]# free -k -t
total used free shared buffers cached
Mem: 7643536 6694220 949316 0 161008 4916420
-/+ buffers/cache: 1616792 6026744
Swap: 8185108 11584 8173524
Total: 15828644 6705804 9122840

Tim

-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailtogsql-performance-owner@postgresql.org] On Behalf Of Michael Stone
Sent: Friday, May 05, 2006 10:24 AM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Memory and/or cache issues?

On Fri, May 05, 2006 at 09:57:58AM -0400, mcelroy, tim wrote:
>Are you saying the kernel's disc cache may be getting whacked? No, I
>understand that PG should use as much memory as it can and the system as
>well. The main problem here is that with almost all the 8GB of RAM 'in
use'
>when I try to do a pg_dump or vacuumdb I run out of memory and the system
>crashes....

You need to be way more specific about what "in use" means. Try pasting
the output of actual commands like "free". The main problem here
according to the output you sent is that your process is trying to
allocate 10billion terabytes of RAM (which ain't gonna work) and dies.
That is not a memory issue.

Mike Stone

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

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. Thanks all who have
> responded to this inquiry, I appreciate it.
>
> 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

On Linux (unlike most Unix systems), "used" includes both processes AND the kernel's file-system buffers, which means "used" will almost always be close to 100%. Starting with a freshly-booted system, you can issue almost any command that scans files, and "used" will go up and STAY at nearly 100% of memory. For example, reboot and try "tar cf - / >/dev/null" and you'll see the same sort of "used" numbers.

In My Humble Opinion, this is a mistake in Linux. This confuses just about everyone the first time they see it (including me), because the file-system buffers are dynamic and will be relenquished by the kernel if another process needs memory. On Unix systems, "used" means, "someone else is using it and you can't have it", which is what most of us really want to know.

Craig

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Fri, May 05, 2006 at 10:40:33AM -0400, Michael Stone wrote:
> 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

Actually, it indiciates a bunch of memory not being used, but IIRC Tim's
database is approximately 4G in size, so the 5.3G of disk cache makes
sense if the system was recently rebooted.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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

Do you have any budget for support or training, either from the company
selling you the app or a company that provides PostgreSQL support? I
suspect some money invested there would result in a lot less
frustration. It'd also certainly be cheaper than switching to Oracle.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match