Re: memory strangeness (fwd) - Mailing list pgsql-admin

From Gregor Mosheh
Subject Re: memory strangeness (fwd)
Date
Msg-id 20020705101359.V48217-100000@osiris.deathkeep.com
Whole thread Raw
In response to Re: memory strangeness (fwd)  (Curt Sampson <cjs@cynic.net>)
Responses Re: memory strangeness (fwd)
List pgsql-admin
First off, thanks for your help, guys.

I'm aware of the problems of over-allocating RAM, and I surely wouldn't
want to force the buffers into swap. (thanks, Curt, for
kern.ipc.shm_use_phys) On this particular system, though, it's doing
nothing except PG. 384 MB of RAM, I can give PG 160 of it, which leaves me
with some 170 MB of idle RAM.

Here are the limits pulled from vmparam.h, by Curt's suggestion:
#define MAXTSIZ    (128UL*1024*1024)   /* max text size */
#define DFLDSIZ    (128UL*1024*1024)   /* initial data size limit */
#define MAXDSIZ    (512UL*1024*1024)   /* max data size */

I'd read somewhere (obiously outdated) that the MAXDSIZ was 128 MB. I've
since rebooted with the kernel.GENERIC...  What's the sysctl setting I use
to set/check the data size limits?

Tom: You said that max_connections shouldn't be set as low as 5. I only
intend to use 1 for the application, and I'll only need 1-2 for my own
admin use, so a setting of 3 should work for my needs. Is there a
technical reason it should be higher?




On Fri, 5 Jul 2002, Curt Sampson wrote:

> On Thu, 4 Jul 2002, Gregor Mosheh wrote:
>
> > Hiya. I've installed Postgres 7.2 on a dedicated FreeBSD system with 384
> > MB RAM. Because the system will be doing nothing except PG, I'd like to
> > dump as much memory as possible into PG's shared memory.
>
> Well, see Tom's comments on this, 'cause that's what I always say
> too. (I'm a NetBSD developer, but FreeBSD's internals aren't so
> different, really.)
>
> However, if you wanted to do it both ways, and benchmark your
> application, I'd be really interested in hearing about the results.
>
> > I rebuilt the kernel with very large limits: 330 MB on the MAXDSIZ and
> > DFLDSIZ, and 330 MB for SHMMAXPAGES. This gives me:
>
> You don't need to rebuild for DFLDSIZ; you can always bump that
> up to MAXDSIZ with sysctl (assuming you're root--do it before
> you "su pgsql -c nadanada" in your startup script). And moving
> MAXDSIZ to 330 MB looks like a reduction to me; FreeBSD's default in
> 4.6-RELEASE is 512 MB. (NetBSD's is 1GB.) You probably want to check
> /usr/include/machine/vmparam.h for default settings before changing
> stuff like this, lest you accidently lower it instead.
>
> > I still cannot set PG's shared_buffers higher than 20000 (160 MB):
>
> Shared memory pages, IIRC, are locked, meaning that they cannot be
> swapped. There's always a limit on the number of locked pages you
> may have in the system in total, if only becuase the system has only
> so much physical RAM. But for some reasont he RLIMIT_MEMLOCK parameter
> on my nearest FreeBSD 4.6 system is a bit bogus:
>
>     server2 $ ulimit -Ha | grep locked
>     lockedmem(kbytes)    unlimited
>
> (I certainly cannot lock an unlimited number of pages in this 1GB
> machine! And for some reason it's also saying that my RLIMIT_RSS
> is unlimited; again, this should return no more than the physical
> RAM available in the machine.)
>
> So I suspect you're running into some other, more secret, limit on
> the number of pages that the system or a process may lock into RAM.
> So you'll want to dig around the kernel to find out where this is,
> and tweak it.
>
> cjs
> --
> Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org
>     Don't you know, in this new Dark Age, we're all light.  --XTC
>
>


--
Gregor Mosheh, B.S.     http://www.blackangel.net/

COMPUTER:
        An electronic entity which performs sequences of useful steps in a
        totally understandable, rigorously logical manner.  If you believe
        this, see me about a bridge I have for sale in Manhattan.









pgsql-admin by date:

Previous
From: Christopher Smith
Date:
Subject: vaccumdb vacuum memory usage
Next
From: Jeff Boes
Date:
Subject: WAL files in 7.2 vs. 7.1