Received: from magus.postgresql.org ([87.238.57.229])
	by malur.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <itparanoia@gmail.com>) id 1TLM5z-00015G-2I
	for pgsql-performance@postgresql.org; Mon, 08 Oct 2012 22:46:43 +0000
Received: from mail-lb0-f174.google.com ([209.85.217.174])
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <itparanoia@gmail.com>) id 1TLM5x-0002Tf-FD
	for pgsql-performance@postgresql.org; Mon, 08 Oct 2012 22:46:42 +0000
Received: by mail-lb0-f174.google.com with SMTP id n3so3310710lbo.19
	for <pgsql-performance@postgresql.org>;
	Mon, 08 Oct 2012 15:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=content-type:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to:x-mailer;
	bh=w5TZtENdcqvpevLLzKwwu5HEjAUIss7Qcg2jcNmuHss=;
	b=zKuYsEZN31wzP/ygLeXpGtExmnizBrFOr4YFIYxwmhAPt24R3MrHJ5UffigIdgnQMz
	RsE+iNYSr+LaDdTFatmcqdL1H3FVWjSHLvt1W3fGaBbWN//Nt4vq7q/S9R5qNr55JJcV
	PDRUTR1g5638+4Z8RKHJSzXDPY26ZWu2ZoXK1Rk3i2L7hHHedYQiIlbe5D5MQ+nTFKgH
	twD40S2assb3iHdrpJlZQteV9c/8Bk9f1hqrmu/KM5iikDSslzgrW6Gs3rvAQO7WI1LA
	WtBLU8lhoWMhKXTBsyG1W0MuU6OpAogVgfBz4DEml/FrKv61lxokiWFkUPBqZVftZCvC
	NdGA==
Received: by 10.152.148.8 with SMTP id to8mr6772471lab.2.1349736400768;
	Mon, 08 Oct 2012 15:46:40 -0700 (PDT)
Received: from [192.168.20.2] (128-69-108-68.broadband.corbina.ru.
	[128.69.108.68])
	by mx.google.com with ESMTPS id h8sm5821818lbi.13.2012.10.08.15.46.39
	(version=TLSv1/SSLv3 cipher=OTHER);
	Mon, 08 Oct 2012 15:46:40 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
Subject: Re: Two identical systems, radically different performance
From: Evgeny Shishkin <itparanoia@gmail.com>
In-Reply-To: 
 <CAGTBQpbFSWPR1Z9NiN_B6amhONjyt9PvoT13Z=SdPN8GoKZi2Q@mail.gmail.com>
Date: Tue, 9 Oct 2012 02:46:38 +0400
Cc: Craig James <cjames@emolecules.com>,
 pgsql-performance@postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A62086F6-67AE-441F-85A5-9C26EF59EBC4@gmail.com>
References: 
 <CAFwQ8rcvw4mSoJ9q+ouONCeB9dg1T9gAUV5J27MpVZrehRHayQ@mail.gmail.com>
	<4CB0E3B6-CF1E-4B54-9900-E8356744F0AA@gmail.com>
	<CAFwQ8rd1TTLh-BfMf-Uc2Vv_8GuP2uQqWAa6-FrtmJUhy3LVxQ@mail.gmail.com>
	<CAGTBQpZnkU7n4iAhiNzN3rsMW2WT+H6YpN7c7bkNbfj+3hr6NA@mail.gmail.com>
	<CAFwQ8rfVgRXQLaHULbvpD65+7jYsAt9ANqujOwnksFLGYHkZew@mail.gmail.com>
	<CAGTBQpbFSWPR1Z9NiN_B6amhONjyt9PvoT13Z=SdPN8GoKZi2Q@mail.gmail.com>
To: Claudio Freire <klaussfreire@gmail.com>
X-Mailer: Apple Mail (2.1498)
X-Pg-Spam-Score: -2.7 (--)
X-Archive-Number: 201210/70
X-Sequence-Number: 48029


On Oct 9, 2012, at 2:44 AM, Claudio Freire <klaussfreire@gmail.com> =
wrote:

> On Mon, Oct 8, 2012 at 7:25 PM, Craig James <cjames@emolecules.com> =
wrote:
>>>> But why? What have I overlooked?
>>>=20
>>> Do you have readahead properly set up on the new one?
>>=20
>>=20
>> # blockdev --getra /dev/sdb1
>> 256
>=20
>=20
> It's probably this. 256 is way too low to saturate your I/O system.
> Pump it up. I've found 8192 works nice for a system I have, 32000 I
> guess could work too.

This, i also suggest to rebenchmark with increased wal_buffers. May be =
that downscale comes from wal mutex contention.=