From: | Arjen van der Meijden <acmmailing(at)tweakers(dot)net> |
---|---|
To: | Jignesh Shah <J(dot)K(dot)Shah(at)Sun(dot)COM> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL scalability on Sun UltraSparc T1 |
Date: | 2006-07-31 07:59:51 |
Message-ID: | 44CDB877.3070709@tweakers.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi Jignesh,
It was a cvs-checkout of 8.2 devel, compiled using:
CPPFLAGS="-fast -xtarget=ultraT1 -xnolibmopt" CC=/opt/SUNWspro/bin/cc
./configure --without-readline
We'd gotten a specially adjusted Solaris version from Sun Holland for
the T2000. It was a dvd with a Solaris flar archive from 11 april 2006
and patches from 25 april 2006. It also had the preferred Solaris System
settings already applied. If you need more details about that dvd, I
think your best option is to contact Hans Nijbacker or Bart Muijzer,
since we're no Solaris-experts :)
Appart from that, we did no extra tuning of the OS, nor did Hans for the
MySQL-optimizations (afaik, but then again, he knows best).
Best regards,
Arjen van der Meijden
Jignesh Shah wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2006-07-31 09:20:41 | Re: sub select performance due to seq scans |
Previous Message | Jignesh Shah | 2006-07-31 07:07:07 | Re: PostgreSQL scalability on Sun UltraSparc T1 |