Re: Very high effective_cache_size == worse performance?

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: David Kerr <dmk(at)mr-paradox(dot)net>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, Nikolas Everett <nik9000(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Very high effective_cache_size == worse performance?
Date: 2010-04-20 20:26:52
Message-ID: 4BCE0E0C.1020903@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

David Kerr wrote:
> the db, xlog and logs are all on separate areas of the SAN.
> separate I/O controllers, etc on the SAN. it's setup well, I wouldn't expect
> contention there.
>

Just because you don't expect it doesn't mean it's not there.
Particularly something as complicated as a SAN setup, presuming anything
without actually benchmarking it is a recipe for fuzzy diagnostics when
problems pop up. If you took anyone's word that your SAN has good
performance without confirming it yourself, that's a path that's lead
many to trouble.

Anyway, as Robert already stated, effective_cache_size only impacts how
some very specific types of queries are executed; that's it. If there's
some sort of query behavior involved in your load, maybe that has
something to do with your slowdown, but it doesn't explain general slow
performance. Other possibilities include that something else changed
when you reloaded the server as part of that, or it's a complete
coincidence--perhaps autoanalyze happened to finish at around the same
time and it lead to new plans.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message David Kerr 2010-04-20 20:39:19 Re: Very high effective_cache_size == worse performance?
Previous Message Kevin Grittner 2010-04-20 20:22:33 Re: SOLVED ... Re: Getting rid of a cursor from JDBC .... Re: [PERFORM] Re: HELP: How to tame the 8.3.x JDBC driver with a biq guery result set