SEO

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@postgresql.org
[mailtogsql-performance-owner@postgresql.org] On Behalf Of Michael Stone
Sent: Friday, May 05, 2006 10:41 AM
To: pgsql-performance@postgresql.org
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

On Fri, May 05, 2006 at 10:45:21AM -0400, mcelroy, tim wrote:
>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?

Yes.

>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?

I have no idea why the bogus memory allocation happened. If it continues
to happen you might have data corruption on disk. If it never happens
again, it could have been cosmic rays.

Mike Stone

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

Michael Stone wrote:
> On Fri, May 05, 2006 at 10:45:21AM -0400, mcelroy, tim wrote:
>> 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?
>
> Yes.
>
>> 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?
>
> I have no idea why the bogus memory allocation happened. If it continues
> to happen you might have data corruption on disk. If it never happens
> again, it could have been cosmic rays.
>
> Mike Stone

have you configured your shared memory settings right?
if postgres tries to allocate more memory (because of settings enable
it) than the kernel itself is configured for, then you will see similar
error messages.

--
Üdvözlettel,
Gábriel Ákos
-=E-Mail :akos.gabriel@i-logic.hu|Web: http://www.i-logic.hu=-
-=Tel/fax:+3612367353 |Mobil:+36209278894 =-

---------------------------(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 06:33:33PM +0200, Gábriel Ákos wrote:
>if postgres tries to allocate more memory (because of settings enable
>it) than the kernel itself is configured for, then you will see similar
>error messages.

If you're talking about the shared memory limits, postgres will bomb out
fairly quickly in that case, IIRC.

Mike Stone

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Fri, May 05, 2006 at 01:09:53PM -0400, Michael Stone wrote:
> On Fri, May 05, 2006 at 06:33:33PM +0200, G?briel ?kos wrote:
> >if postgres tries to allocate more memory (because of settings enable
> >it) than the kernel itself is configured for, then you will see similar
> >error messages.
>
> If you're talking about the shared memory limits, postgres will bomb out
> fairly quickly in that case, IIRC.

More importantly I don't think it would result in trying to allocate 10
TB or whatever that huge number was.
--
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 5: don't forget to increase your free space map settings