pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jignesh Shah <J.K.Shah@Sun.COM>
To: Arjen van der Meijden <acmmailing@tweakers.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: PostgreSQL scalability on Sun UltraSparc T1
Date: Mon, 31 Jul 2006 08:07:07 +0100
Message-ID: <44CDAC1B.4050109@sun.com> (raw)
In-Reply-To: <44CB9D52.8040409@tweakers.net>
References: <44CB7896.8030501@oli.tudelft.nl>
	<44CB8235.9070903@commandprompt.com>
	<44CB8DC1.4040105@tweakers.net>
	<44CB9472.9060206@commandprompt.com>
	<44CB9D52.8040409@tweakers.net>

Hi Arjen,

I am curious about your Sun Studio compiler options also.
Can you send that too ?

Any other tweakings that you did on Solaris?

Thanks.

Regards,
Jignesh


Arjen van der Meijden wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>               http://www.postgresql.org/docs/faq



view thread (14+ messages)  latest in thread

Message-ID: <44CDAC1B.4050109@sun.com>
Permalink:  ../44CDAC1B.4050109@sun.com/
Also on:    postgresql.org/message-id/44CDAC1B.4050109@sun.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: J.K.Shah@Sun.COM, acmmailing@tweakers.net
  Subject: Re: PostgreSQL scalability on Sun UltraSparc T1
  In-Reply-To: <44CDAC1B.4050109@sun.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