Matthew Lunnon wrote:
> Hi Sven,
> Does this mean that one option I have is to use a multi core Intel based
> server instead of an AMD based server?
Wow... hold on.
>> I remember that I also an issue with AMD Opterons before Pg 8.1
>> There is a specific Opteron behaviour on shared memory locks which adds
>> a extra "penalty" during the execution time for Pg code before 8.1.
I would like to see some proof of this.
>> I can you provide my patch for Pg 8.0 which should be adaptable for Pg
>> 7.4 if you can compile PostgreSQL.
The real answer here is to upgrade to 8.1.10 or 8.2.5. 64bit if you can.
>>> I have a 4 * dual core 64bit AMD OPTERON server with 16G of RAM, running
>>> postgres 7.4.3. This has been recompiled on the server for 64 stored
>>> procedure parameters, (I assume this makes postgres 64 bit but are not
This type of machine, assuming you have decent IO available will
generally be very fast with anything >= 8.1.
>>> changes to postgresql.sql:
>>> max_connections = 500
>>> shared_buffers = 96000
Way to high for 7.4. Way to low for 8.1 or above (based on what you
mention your work load is)
>>> sort_mem = 10240
Based on your specs this actually may be fine but I would suggest
reviewing it after you upgrade.
>>> effective_cache_size = 1000000
Again, too low for 8.1 or above.
Joshua D. Drake
The PostgreSQL Company: http://www.commandprompt.com/
In response to
pgsql-performance by date
|Next:||From: Piotr Gasidło||Date: 2007-12-13 11:41:40|
|Subject: Re: Index on VARCHAR with text_pattern_ops inside PL/PGSQL procedure.|
|Previous:||From: Joshua D. Drake||Date: 2007-12-12 15:38:20|
|Subject: Re: Limited performance on multi core server|