Thread: Solaris and effective_cache_size
Hi,
There has been some recent discussion on the list about performance
trouble on Solaris. We have a test environment which includes two
2-way Sun E250s with 2 Gigs of RAM each. We have experienced some
trouble similar to what others have mentioned, although it has not
been as bad.
I've been investigating some troubles we've been having on one of
those test machines. When the database gets sort of large, or has
been running for a while, we start to have trouble with performance.
I had a feeling that this might be related to disk caches.
Solaris is _much_ more aggressive about disk caching than Linux is,
it seems. I suspected that adjusting the effective_cache_size
setting might therefore help.
Using pgbench, I discovered a performance advantage of almost 10% by
increasing the setting from the default 1000 to 1500. I am not sure
whether this figure will hold up, but it was consistent over multiple
tests.
Has anyone else had any results (similar or different) when playing
with that setting?
Also, does anyone have a good way of testing the random_page_cost?
I've tried to find ways to test this in the past, and I've never had
any luck, because I haven't been able to be sure (in my test) that
the pages are really spread out in a way that the random_page_cost
setting would be tested.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
Andrew Sullivan <andrew@libertyrms.info> writes:
> Solaris is _much_ more aggressive about disk caching than Linux is,
> it seems. I suspected that adjusting the effective_cache_size
> setting might therefore help.
> Using pgbench, I discovered a performance advantage of almost 10% by
> increasing the setting from the default 1000 to 1500. I am not sure
> whether this figure will hold up, but it was consistent over multiple
> tests.
Actually, the default 1000 setting is probably very much on the low side
--- that's only equivalent to 8 meg of disk cache space after all, and
on any reasonably modern box there's probably lots more RAM than that
being used for disk cache.
However, I'm quite surprised to hear that tweaking effective_cache_size
affects pgbench results at all. I'd have thought that all the queries
used by pgbench would be indexscans anyway...
regards, tom lane
On Fri, Feb 15, 2002 at 11:17:42AM -0500, Tom Lane wrote:
> Actually, the default 1000 setting is probably very much on the low side
> --- that's only equivalent to 8 meg of disk cache space after all, and
> on any reasonably modern box there's probably lots more RAM than that
> being used for disk cache.
Yes, that's why I started playing with it. But performance degrades
again if you raise it too much. I've had similar results with our
own application.
> However, I'm quite surprised to hear that tweaking effective_cache_size
> affects pgbench results at all. I'd have thought that all the queries
> used by pgbench would be indexscans anyway...
I was sort of surprised by that, too. But the effect is totally
consistent over dozens of tests.
A
--
----
Andrew Sullivan 87 Mowat Avenue
Liberty RMS Toronto, Ontario Canada
<andrew@libertyrms.info> M6K 3E3
+1 416 646 3304 x110
Andrew Sullivan wrote: > On Fri, Feb 15, 2002 at 11:17:42AM -0500, Tom Lane wrote: > >>However, I'm quite surprised to hear that tweaking effective_cache_size >>affects pgbench results at all. I'd have thought that all the queries >>used by pgbench would be indexscans anyway... >> > > I was sort of surprised by that, too. But the effect is totally > consistent over dozens of tests. pgbench does a bunch of updates, which generate WAL activity. At some point it goes to disk. I keep increasing the number of transactions in pgbench, eventually it'll go to disk. -- P. J. "Josh" Rovero Sonalysts, Inc. Email: rovero@sonalysts.com www.sonalysts.com 215 Parkway North Work: (860)326-3671 or 442-4355 Waterford CT 06385 ***********************************************************************