Re: strange performance regression between 7.4 and 8.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/1/07, Jeff Frost <jeff@xxxxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 1 Mar 2007, Alex Deucher wrote:

>> Vacuum? Analayze? default_statistics_target? How many shared_buffers?
>> effective_cache_size? work_mem?
>>
>
> I'm running the autovacuum process on the 8.1 server.  vacuuming on
> the old server was done manually.
>
> default_statistics_target and effective_cache_size are set to the the
> defaults on both.
>
> postgres 7.4 server:
> # - Memory -
> shared_buffers = 82000 # 1000            min 16, at least
> max_connections*2, 8KB each
> sort_mem = 8000        # 1024            min 64, size in KB
> vacuum_mem = 32000     # 8192            min 1024, size in KB
> # - Free Space Map -
> #max_fsm_pages = 20000          # min max_fsm_relations*16, 6 bytes each
> #max_fsm_relations = 1000       # min 100, ~50 bytes each
> # - Kernel Resource Usage -
> #max_files_per_process = 1000   # min 25
>
> postgres 8.1 server:
> # - Memory -
> shared_buffers = 100000                 # min 16 or max_connections*2, 8KB
> each
> temp_buffers = 2000 #1000                       # min 100, 8KB each
> max_prepared_transactions = 100 #5              # can be 0 or more
> # note: increasing max_prepared_transactions costs ~600 bytes of shared
> memory
> # per transaction slot, plus lock space (see max_locks_per_transaction).
> work_mem = 10000        #1024           # min 64, size in KB
> maintenance_work_mem = 524288 #16384            # min 1024, size in KB
> #max_stack_depth = 2048                 # min 100, size in KB
>
> I've also tried using the same settings from the old server on the new
> one; same performance issues.
>

If this is a linux system, could you give us the output of the 'free' command?

            total       used       free     shared    buffers     cached
Mem:       8059852    8042868      16984          0        228    7888648
-/+ buffers/cache:     153992    7905860
Swap:     15631224       2164   15629060


Postgresql might be choosing a bad plan because your effective_cache_size is
way off (it's the default now right?).  Also, what was the block read/write

yes it's set to the default.

speed of the SAN from your bonnie tests?  Probably want to tune
random_page_cost as well if it's also at the default.


	            ------Sequential Output------ --Sequential Input- --Random-
                   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
luna12-san   16000M 58896  91 62931   9 35870   5 54869  82 145504 13  397.7  0

effective_cache_size is the default.

Alex


[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux