pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Arjen van der Meijden <acmmailing@tweakers.net>
To: Joshua D. Drake <jd@commandprompt.com>
Cc: Jochem van Dieten <jochemd@oli.tudelft.nl>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL scalability on Sun UltraSparc T1
Date: Sat, 29 Jul 2006 19:39:30 +0200
Message-ID: <44CB9D52.8040409@tweakers.net> (raw)
In-Reply-To: <44CB9472.9060206@commandprompt.com>
References: <44CB7896.8030501@oli.tudelft.nl>
	<44CB8235.9070903@commandprompt.com>
	<44CB8DC1.4040105@tweakers.net>
	<44CB9472.9060206@commandprompt.com>

On 29-7-2006 19:01, Joshua D. Drake wrote:
> Well I would be curious about the postgresql.conf and how much ram 
> etc... it had.

It was the 8core version with 16GB memory... but actually that's just 
overkill, the active portions of the database easily fits in 8GB and a 
test on another machine with just 2GB didn't even show that much 
improvements when going to 7GB (6x1G, 2x 512M), it was mostly in the 
range of 10% improvement or less.

Anyway, the differences to the default postgresql.conf:
shared_buffers = 30000
Tests with 40k, 50k en 60k didn't really show improvements.

work_mem = 2048
This probably could've been set higher with the sheer amount of 
not-really-used memory.

maintenance_work_mem = 65535
Not really important of course

max_fsm_pages = 50000
Somehow it needed to be set quite high, probably because we only cleaned 
up after doing over 200k requests.

effective_cache_size = 350000
As said, the database fitted in 8GB of memory, so I didn't see a need to 
set this higher than for the 8GB machines (x4200 and another T2000 we had).

default_statistics_target = 200
For a few columns on the largest tables I manually raised it to 1000

log_min_duration_statement = 1000
I'm not sure if this has much overhead? Stats logging was turned/left on 
as well.
Turning that off improved it a few percent.

> I understand, I just have a feeling that we could do even better :) I do 
> appreciate all your efforts.

Well, I'll keep that in mind :)
What it makes even worse for MySQL is that it had (on another machine) 
about 8M hits on the query cache for 4M inserts, i.e. half of the 
queries weren't even executed on it.

Best regards,

Arjen



view thread (14+ messages)  latest in thread

Message-ID: <44CB9D52.8040409@tweakers.net>
Permalink:  ../44CB9D52.8040409@tweakers.net/
Also on:    postgresql.org/message-id/44CB9D52.8040409@tweakers.net

 · 

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: acmmailing@tweakers.net, jd@commandprompt.com, jochemd@oli.tudelft.nl
  Subject: Re: PostgreSQL scalability on Sun UltraSparc T1
  In-Reply-To: <44CB9D52.8040409@tweakers.net>

* 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