From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
---|---|
To: | "Kavan, Dan (IMS)" <KavanD(at)imsweb(dot)com> |
Cc: | postgres <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: memory allocation ; postgresql-8.0 |
Date: | 2005-05-12 15:20:53 |
Message-ID: | 1115911253.3868.262.camel@state.g2switchworks.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Thu, 2005-05-12 at 10:10, Kavan, Dan (IMS) wrote:
> Hi Scott,
>
> Thanks again for all your tips.
>
> If I knock the buffer size down to 65,536 (still higher than what you
> are recommending) then my shmmax becomes:
> 256,000 + 550,292,685 (65536*8396.8) + 1,454,100 = 552,002,785
>
> That will leave me with 3.5 GB of free memory for the system & work
> memory to use.
> Will those free system resources ever get used with a 10 million record,
> 10 GB database?
Certainly. As you access the data the kernel will cache all the data
sent through it. Once the machine's been up and processing for a while
you should see a top output that shows "free" memory at a few megs (8 to
30 meg is typical) and all the rest of the memory being used as kernel
cache.
> If I go with 65,536 as my buffer size, Would having the SHMMAX set to 1
> GB on my sysctl.conf system parameters allow me to run two seperate
> instances of postgresql on 2 seperate ports?
Yes, but you may want to set it just a tad higher for things like fsm
and whatnot.
Definitely benchmark both the 64k setting of shared_buffers and lower
settings, looking for a knee with your data set. It may well be that
the best performance happens at a lower number, and doesn't really
increase as you bump up the shared_buffers. Be sure to test things as
realistically as possible, i.e. the right amount of parallel users and
all that.
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2005-05-12 15:23:36 | Re: Query Plan - Index Scan & Seq Scan |
Previous Message | Tom Lane | 2005-05-12 15:14:30 | Re: Query Plan - Index Scan & Seq Scan |