Re: Recommended Initial Settings

From: "Campbell, Lance" <lance(at)uiuc(dot)edu>
To: "Richard Huxton" <dev(at)archonet(dot)com>
Cc: <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Recommended Initial Settings
Date: 2007-02-23 17:14:44
Message-ID: A3AC4FA47DC0B1458C3E5396E685E63302395CE9@SAB-DC1.sab.uiuc.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Richard,
Thanks for your reply.

You said:
"Your operating-system should be doing the caching for you."

My understanding is that as long as Linux has memory available it will
cache files. Then from your comment I get the impression that since
Linux would be caching the data files for the postgres database it would
be redundant to have a large shared_buffers. Did I understand you
correctly?

Thanks,

Lance Campbell
Project Manager/Software Architect
Web Services at Public Affairs
University of Illinois
217.333.0382
http://webservices.uiuc.edu

-----Original Message-----
From: Richard Huxton [mailto:dev(at)archonet(dot)com]
Sent: Friday, February 23, 2007 10:29 AM
To: Campbell, Lance
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] Recommended Initial Settings

Campbell, Lance wrote:
> I would like to get someone's recommendations on the best initial
> settings for a dedicated PostgreSQL server. I do realize that there
are
> a lot of factors that influence how one should configure a database.
I
> am just looking for a good starting point. Ideally I would like the
> database to reside as much as possible in memory with no disk access.
> The current database size of my 7.x version of PostgreSQL generates a
6
> Gig file when doing a database dump.

Your operating-system should be doing the caching for you.

> Dedicated PostgreSQL 8.2 Server
> Redhat Linux 4.x AS 64 bit version (EM64T)
> 4 Intel Xeon Processors

If these are older Xeons, check the mailing list archives for "xeon
context switch".

> 20 Gig Memory
> Current PostgreSQL database is 6 Gig file when doing a database dump

OK, so it's plausible the whole thing will fit in RAM (as a
rule-of-thumb I assume headers, indexes etc. triple or quadruple the
size). To know better, check the actual disk-usage of $PGDATA.

> /etc/sysctl.conf file settings:
>
> # 11 Gig
>
> kernel.shmmax = 11811160064

Hmm - that's a lot of shared RAM. See shared_buffers below.

> kernel.sem = 250 32000 100 128
>
> net.ipv4.ip_local_port_range = 1024 65000
>
> net.core.rmem_default = 262144
>
> net.core.rmem_max = 262144
>
> net.core.wmem_default = 262144
>
> net.core.wmem_max = 262144

> postgresql.conf file settings (if not listed then I used the
defaults):
>
> max_connections = 300

How many connections do you expect typically/peak? It doesn't cost much
to have max_connections set high but your workload is the most important

thing missing from your question.

> shared_buffers = 10240MB

For 7.x that's probably way too big, but 8.x organises its buffers
better. I'd still be tempted to start a 1 or 2GB and work up - see where

it stops buying you an improvement.

> work_mem = 10MB

If you have large queries, doing big sorts I'd increase this. Don't
forget it's per-sort, so if you have got about 300 connections live at
any one time that could be 300*10MB*N if they're all doing something
complicated. If you only have one connection live, you can increase this

quite substantially.

> effective_cache_size = 512MB

This isn't setting PG's memory usage, it's telling PG how much data your

operating-system is caching. Check "free" and see what it says. For you,

I'd expect 10GB+.

> maintenance_work_mem = 100MB

This is for admin-related tasks, so you could probably increase it.

Workload workload workload - we need to know what you're doing with it.
Once connection summarising the entire database will want larger numbers

than 100 connections running many small queries.

HTH
--
Richard Huxton
Archonet Ltd

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Richard Huxton 2007-02-23 17:19:00 Re: Recommended Initial Settings
Previous Message Merlin Moncure 2007-02-23 16:35:42 Re: R: Very slow bytea data extraction