| Lists: | pdxpug |
|---|
| From: | Gregor at HostGIS <gregor(at)hostgis(dot)com> |
|---|---|
| To: | Portland PostgreSQL <pdxpug(at)postgresql(dot)org> |
| Subject: | Hey hey |
| Date: | 2009-03-27 02:21:44 |
| Message-ID: | 49CC3838.8050708@hostgis.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pdxpug |
Just a hello to everybody. I met a few of y'all at PG East last year,
and now I live only an hour and a half from Portland. I'll be attending
Open Source GIS stuff in Portland, so I figured why not add Pg to my list?
It's too bad I missed y'all's last meeting; I found out about it as it
was starting. How to re-optimize a 900GB set of transportation data; yummy.
--
HostGIS, Open Source solutions for the global GIS community
Greg Allensworth - SysAdmin, Programmer, GIS Person, Security
Network+ Server+ A+ Security+
| From: | Selena Deckelmann <selenamarie(at)gmail(dot)com> |
|---|---|
| To: | Gregor at HostGIS <gregor(at)hostgis(dot)com> |
| Cc: | Portland PostgreSQL <pdxpug(at)postgresql(dot)org> |
| Subject: | Re: Hey hey |
| Date: | 2009-03-27 14:42:32 |
| Message-ID: | 2b5e566d0903270742i6c9e790cxb6fe12e54355e41c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pdxpug |
Hi Gregor!
On Thu, Mar 26, 2009 at 7:21 PM, Gregor at HostGIS <gregor(at)hostgis(dot)com> wrote:
> Just a hello to everybody. I met a few of y'all at PG East last year, and
> now I live only an hour and a half from Portland. I'll be attending Open
> Source GIS stuff in Portland, so I figured why not add Pg to my list?
Sweet! Can you keep us informed about the GIS stuff? Some of us are
on the mailing list, but forwarding meeting announcements would be
sweet.
-selena
--
Selena Deckelmann
Open Source Bridge - http://www.opensourcebridge.org
PDXPUG - http://pugs.postgresql.org/pdx
Me - http://www.chesnok.com/daily
| From: | "Ewan, Michael" <michael(dot)ewan(at)intel(dot)com> |
|---|---|
| To: | Portland PostgreSQL <pdxpug(at)postgresql(dot)org> |
| Subject: | PostgreSQL 8.4 tuning question |
| Date: | 2009-07-09 21:56:09 |
| Message-ID: | 66C9C47441840949A66773F8F0D9D6A76F84A0DF@rrsmsx503.amr.corp.intel.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pdxpug |
I'm installing a new DB server on an Intel Xeon X5460 server (eight cores) with 32GB memory. The kernel resources section (17.4) of the manual says to check kernel.shmmax and kernel.shmall, and set them to something like 128MB and 2M pages respectively. However the defaults on SuSE SLES 10 are
kernel.shmmax = 18446744073709551615
kernel.shmall = 1152921504606846720
I'm assuming I should just shake my head, walk away, and not try to figure out what Novell is doing here. Anyone have any experience with PostgreSQL on SuSE SLES 10? Any other tuning issues I should for?
| From: | Devin Ben-Hur <devin(at)ben-hur(dot)net> |
|---|---|
| To: | "Ewan, Michael" <michael(dot)ewan(at)intel(dot)com> |
| Cc: | Portland PostgreSQL <pdxpug(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL 8.4 tuning question |
| Date: | 2009-07-11 16:20:14 |
| Message-ID: | 4A58BBBE.3040800@ben-hur.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pdxpug |
Ewan, Michael wrote:
> kernel.shmmax = 18446744073709551615
> kernel.shmall = 1152921504606846720
>
> I'm assuming I should just shake my head, walk away, and not try to
> figure out what Novell is doing here.
No real advice about tuning beyond what you've already read, but wanted
to point out that those two enormous numbers are 2^64-1 and 2^60-1
respectively.
So, Novell's SHMMAX is specifying the largest allowed shared memory
segment as the largest range of a 64bit address. This probably has
little overhead, but should more reasonably be set to a number less than
your real physical memory.
Their SHMALL seems silly. SHMALL is the total shared memory available
and is measured in pages under Linux. The standard page size is 4K ( $
getconf PAGE_SIZE ), so, if Novel was following their 64bit maxuint
pattern, I would have expected their shmall to be 2^52.
On a system with one principle shared memory consumer (eg a db server),
just pick your shmmax as the largest amount of your real memory you want
any software to use, set shmall to shmax/PAGE_SIZE, and configure your
db to use less shared memory than shmmax.
You'll probably find pg shared buffers somewhere between 4G and 10G of
your 32G total will be effective, but it depends a lot on the specifics
of your usage.
--
-Devin