pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: John A Meinel <john@arbash-meinel.com>
To: Jeremiah Jahn <jeremiah@cs.earlham.edu>
Cc: postgres performance <pgsql-performance@postgresql.org>
Subject: Re: extremly low memory usage
Date: Wed, 17 Aug 2005 21:21:04 -0500
Message-ID: <4303F090.40602@arbash-meinel.com> (raw)
In-Reply-To: <1124331108.27881.96.camel@bluejay.goodinassociates.com>
References: <1124331108.27881.96.camel@bluejay.goodinassociates.com>

Jeremiah Jahn wrote:
> I just put together a system with 6GB of ram on a 14 disk raid 10 array.
> When I run my usual big painful queries, I get very little to know
> memory usage. My production box (raid 5 4GB ram) hovers at 3.9GB used
> most of the time. the new devel box sits at around 250MB.
>
> I've switched to an 8.0 system on the new devel box, but the .conf
> really didn't change. Index usage is the same. Something seems wrong and
> I'm not sure why.
>

How big is your actual database on disk? And how much of it is actually
touched by your queries?

It seems that your tough queries might only be exercising a portion of
the database. If you really want to make memory usage increase try
something like:
find . -type f -print0 | xargs -0 cat >/dev/null
Which should read all the files. After doing that, does the memory usage
increase?

>
> any thoughts,
> -jj-
>
>
> shared_buffers = 32768          # min 16, at least max_connections*2, 8KB each
> work_mem = 2097151              # min 64, size in KB

This seems awfully high. 2GB Per sort? This might actually be flushing
some of your ram, since it would get allocated and filled, and then
freed when finished. Remember, depending on what you are doing, this
amount can get allocated more than once per query.

> maintenance_work_mem = 819200   # min 1024, size in KB
> max_fsm_pages = 80000           # min max_fsm_relations*16, 6 bytes each
> checkpoint_segments = 30        # in logfile segments, min 1, 16MB each
> effective_cache_size = 3600000   <-----this is a little out of control, but would it have any real effect?

It should just tell the planner that it is more likely to have buffers
in cache, so index scans are slightly cheaper than they would otherwise be.

> random_page_cost = 2            # units are one sequential page fetch cost
> log_min_duration_statement = 10000 # -1 is disabled, in milliseconds.
> lc_messages = 'C'               # locale for system error message strings
> lc_monetary = 'C'               # locale for monetary formatting
> lc_numeric = 'C'                # locale for number formatting
> lc_time = 'C'                   # locale for time formatting
>

John
=:->

Attachments:

  signature.asc (application/pgp-signature, 252B) download

view thread (39+ messages)  latest in thread

Message-ID: <4303F090.40602@arbash-meinel.com>
Permalink:  ../4303F090.40602@arbash-meinel.com/
Also on:    postgresql.org/message-id/4303F090.40602@arbash-meinel.com

 · 

reply

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: john@arbash-meinel.com, jeremiah@cs.earlham.edu
  Subject: Re: extremly low memory usage
  In-Reply-To: <4303F090.40602@arbash-meinel.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