Message-ID: <4533815E.3050301@boreham.org>
Date: Mon, 16 Oct 2006 06:55:58 -0600
From: David Boreham <david_list@boreham.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Harald Armin Massa <haraldarminmassa@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: measuring shared memory usage on Windows
References: <7be3f35d0610160215v21edbe48vc144200a83f41dd0@mail.gmail.com>
In-Reply-To: <7be3f35d0610160215v21edbe48vc144200a83f41dd0@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


> I learned the hard way that just rising it can lead to a hard
> performance loss :)

I looked back in the list archives to try to find your post on the
underlying problem, but could only find this rather terse sentence.
If you have more detailed information please post or point me at it.

But...my first thought is that you have configured the shared memory
region so large that the system as a whole can not fit all the working set
sizes for all running processes in to physical memory. This is a common
pitfall for databases with caches implemented as mapped shared
user space regions (which is basically all databases).

For example, if you have 1G of RAM on the box, you can't
configure a cache of 900 meg and expect things to work well.
This is because the OS and associated other stuff running on
the box will use ~300megs. The system will page as a result.

The only sure fire way I know of to find the absolute maximum
cache size that can be safely configured is to experiment with
larger and larger sizes until paging occurs, then back off a bit.