From: Merlin Moncure <mmoncure@gmail.com>
To: Joshua Fielek <jfielek@centriccrm.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Making the most of memory?
Date: Thu, 24 Jan 2008 13:01:33 -0500
Message-ID: <b42b73150801241001o2bc7df3dwab55085c744e3cf0@mail.gmail.com> (raw)
In-Reply-To: <4796BE84.9030803@centriccrm.com>
References: <4796BE84.9030803@centriccrm.com>
On Jan 22, 2008 11:11 PM, Joshua Fielek <jfielek@centriccrm.com> wrote:
> The database itself is not that large -- a db_dump of the sql file as
> text is only about 110MB. I haven't checked the exact size of the actual
> data base, but the entire data directory is smaller than the available
> memory at about 385MB including logs and config files. This is a single
> database with a relatively small number of client connections (50 or so)
> making a fair number of smaller queries. This is not a massive data
> effort by any means at this time, but it will be growing.
>
> We have available currently ~4GB (8GB total) for Postgres. We will be
> moving to a server that will have about 24GB (32GB total) available for
> the database, with the current server becoming a hot backup, probably
> with slony or something similar to keep the databases in sync.
The database is cached in RAM. As soon as the database files are read
for the first time, they will stay cached in the o/s basically forever
(in either o/s file cache or postgresql buffer cache) as long as there
are no other demands on memory...not likely in your case. This also
means extra ram is not likely to help performance much if at all.
I'll give you a little hint about postgresql.conf...tuning shared
buffers rarely has a huge impact on performance...the o/s will
possible issues you might be having:
*) sync issues: asking drives to sync more often they can handle.
possible solutions...faster/more drives or ask database to sync less
(fsync off, or better transaction management)
*) cpu bound issues: poorly designed queries, or poorly designed
tables, bad/no indexes, etc
*) unrealistic expectations of database performance
*) not maintaining database properly, vacuum, etc
*) mvcc issues
maybe post your transaction load, and/or some slow queries you are dealing with.
merlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mmoncure@gmail.com, jfielek@centriccrm.com
Subject: Re: Making the most of memory?
In-Reply-To: <b42b73150801241001o2bc7df3dwab55085c744e3cf0@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox