Re: Configuration Issue ?

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Mark Lonsdale <mark(dot)lonsdale(at)wysdm(dot)com>
Cc: Richard Huxton <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Configuration Issue ?
Date: 2006-10-25 21:42:25
Message-ID: 453FDA41.8030605@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Mark Lonsdale wrote:
>
> Thanks guys, I think we'll certainly look to get the app certified with
> 7.4 and 8.x but that may take a little while. In the interim, Im
> thinking of making the following changes then:-
>
> Change Shared_buffers from 393216 to 80,000 ( ~15% of 4GB of RAM.
> Server is 8GB but I want to leave space for App as well )

You likely run into issues with anything over 16384. I have never seen a
benefit from shared_buffers over 12k or so with 7.3.

>
> Set my effective_cache_size to 125,000 ( ~25% of 4GB of RAM )
>
> Set my sort_mem to 8192

:)

Sincerely,

Joshua D. Drake

>
> Do those numbers look a bit better? Will probably see if we can make
> these changes asap as the server is struggling a bit now, which doesn't
> really make sense given how much memory is in it.
>
> Really appreciate your help and fast turnaround on this
>
> Mark
>
> -----Original Message-----
> From: Joshua D. Drake [mailto:jd(at)commandprompt(dot)com]
> Sent: 25 October 2006 22:17
> To: Richard Huxton
> Cc: Mark Lonsdale; pgsql-performance(at)postgresql(dot)org
> Subject: Re: [PERFORM] Configuration Issue ?
>
> Richard Huxton wrote:
>> Mark Lonsdale wrote:
>>> Hi Josh
>>>
>>> Thanks for the feedback, that is most usefull. When you said one of
> the
>>> settings was likely killing us, was it all of the settings for
>>> max_fsm_relations, max_fsm_pages, and sort_mem or just the setting
> for
>>> sort_mem ?
>>>
>>> Can you explain why the setting would be killing me :-)
>> The sort_mem is crucial. It's memory *per sort*, which means one query
>> can use several times that amount.
>
> Worse then that it is:
>
> ((sort memory) * (number of sorts)) * (number of connections) = amount
> of ram possible to use.
>
> Now... take the following query:
>
> SELECT * FROM foo
> JOIN bar on (bar.id = foo.id)
> JOIN baz on (baz.id = foo_baz.id)
> ORDER BY baz.name, foo.salary;
>
> Over 5 million rows... How much ram you think you just used?
>
>>> The long and short is you need to upgrade to at least 7.4,
> preferrably
>>> 8.1.
>> Joshua means this too. Upgrade to 7.3.16 within the next few days,
> then
>> test out something more recent. You should see some useful performance
>> gains from 8.1.
>
> Right. The reason I suggested 7.4 is that he gets VACUUM VERBOSE in a
> reasonable fashion but of course 8.1 is better.
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
>

--

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Marlowe 2006-10-25 22:04:52 Re: commit so slow program looks frozen
Previous Message Mark Lonsdale 2006-10-25 21:31:29 Re: Configuration Issue ?