DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=CpVcJ9reUuqPyqKBsq+92zmVbXGZkNh7VR9HjumXz8yLunZVVSyr7CZwaMIslZFQNt
	YQZJjW9MtA01EqqzkC9EQ69NYuE/MzeIVkn2DXW728dCJOPo5cwBqfUXWsQOEsUVX/CH
	1CJ5R+1Kon5B85/V0YudtAh40QM3L3WVJJXP4=
MIME-Version: 1.0
In-Reply-To: <C5D40605.2F56%scott@richrelevance.com>
References: <13904207.99291236170787203.JavaMail.root@mail.4linux.com.br>
	<C5D40605.2F56%scott@richrelevance.com>
Date: Wed, 4 Mar 2009 14:49:29 -0700
Message-ID: <dcc563d10903041349x36e4d082wddc6ffdac89505ab@mail.gmail.com>
Subject: Re: work_mem in high transaction rate database
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Flavio Henrique Araque Gurgel <flavio@4linux.com.br>,
	pgsql-performance <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 4, 2009 at 11:18 AM, Scott Carey <scott@richrelevance.com> wrot=
e:
> You may have decreased performance in your batch jobs with the lower
> work_mem setting.

That would be why I recommended benchmarking queries that need more
memory and setting work_mem for those queries alone.

> Additionally, the fact that you haven=92t had swap storm issues so far me=
ans
> that although there is certain risk of an issue, its probably a lot lower
> than what has been talked about here so far.

No, it means you and the OP are guessing at what's a good number
without any actual proof of it.  Guessing it not a particularly good
method for setting work_mem, especially on a server with 2000+
connections.

> Without a change in client behavior (new queries or large change in data)=
 a
> change in load alone is very unlikely to cause a problem.

That is demonstrably incorrect.  If the average number of live queries
out of the 2000 connections is currently 10, and an increase in load
makes it 500, there is a very REAL chance of running the server out of
memory.

>=A0So take your time
> to do it right.

I believe I made mention of benchmarking queries above and in my first
post.  But doing it right does NOT mean setting work_mem to 2G then
whittling it down as your server crashes under load.

> =A0I disagree with the knee-jerk =93change it now!=94 response.
> =A0The very fact you have gotten this far means it is not as risky as the=
 bare
> settings indicate.

Sorry, but I disagree back at you, and it's not a knee jerk reaction,
it's a reaction honed from years of watching supposedly stable
postgresql servers crash and burn under slashdot effect type loads.

> Definitely plan on improving and testing out work_mem variants soon, but =
a
> hasty change to a small value might cause your batch jobs to take much
> longer =97 what is your risk if they take too long or don=92t complete in=
 time?
> =A0That risk is yours to assess =97 if its not much of a risk, then by al=
l means
> lower work_mem soon. =A0But if it is business critical for those batch jo=
bs to
> complete within some time frame, be careful.

Sorry, but that's backwards.  Unless the batch jobs are the only
important thing on this server, running it with work_mem=3D2G is asking
for trouble under any real kind of load.  It's sacrificing stability
for some unknown and quite probably minimal performance improvement.

It seems a lot of your post is based on either hoping for the best, or
assuming access patterns won't change much over time.  Do you test at
higher and higher parallel loads until failure occurs and then figure
out how to limit that type of failure?  I do, because I can't afford
to have my db servers crash and burn midday under peak load.  And you
never know when some app is gonna start suddenly spewing things like
unconstrained joins due to some bug, and if you've got work_mem set to
1G your server IS gonna have problems.