Re: strange performance regression between 7.4 and 8.1

On 3/1/07, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> Alex Deucher wrote:
> > Hello,
> >
> > I have noticed a strange performance regression and I'm at a loss as
> > to what's happening. We have a fairly large database (~16 GB). The
> > original postgres 7.4 was running on a sun v880 with 4 CPUs and 8 GB
> > of ram running Solaris on local scsi discs. The new server is a sun
> > Opteron box with 4 cores, 8 GB of ram running postgres 8.1.4 on Linux
> > (AMD64) on a 4 Gbps FC SAN volume. When we created the new database
> > it was created from scratch rather than copying over the old one,
> > however the table structure is almost identical (UTF8 on the new one
> > vs. C on the old). The problem is queries are ~10x slower on the new
> > hardware. I read several places that the SAN might be to blame, but
> > testing with bonnie and dd indicates that the SAN is actually almost
> > twice as fast as the scsi discs in the old sun server. I've tried
> > adjusting just about every option in the postgres config file, but
> > performance remains the same. Any ideas?
>
> 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.

Thanks,

Alex

> Sincerely,
>
> Joshua D. Drake
>
>
> >
> > Thanks,
> >
> > Alex
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 3: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/docs/faq
> >
>
>
> --
>
> === 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
> PostgreSQL Replication: http://www.commandprompt.com/products/
>
>