On Tue, Apr 20, 2010 at 04:26:52PM -0400, Greg Smith wrote: - 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. that's actually what I'm doing, performance testing this environment. everything's on the table for me at this point. - 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. Ok that's good to know. I didn't think it would have any impact, and was surprised when it appeared to. I just finished running the test on another machine and wasn't able to reproduce the problem, so that's good news in some ways. But now i'm back to the drawing board. I don't think it's anything in the Db that's causing it. ( drop and re-create the db between tests) I actually suspect a hardware issue somewhere. Dave -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
