From: | Gregor Mosheh <stigmata(at)blackangel(dot)net> |
---|---|
To: | Curt Sampson <cjs(at)cynic(dot)net> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: memory strangeness (fwd) |
Date: | 2002-07-05 17:47:23 |
Message-ID: | 20020705101359.V48217-100000@osiris.deathkeep.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)cynic(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Shattuck | 2002-07-05 19:55:56 | Re: Oracle data -> PostgreSQL |
Previous Message | Jeff Boes | 2002-07-05 17:18:22 | WAL files in 7.2 vs. 7.1 |