Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WvLlw-00039X-2w for pgsql-performance@arkaria.postgresql.org; Fri, 13 Jun 2014 07:19:36 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WvLlv-0002DW-EM for pgsql-performance@arkaria.postgresql.org; Fri, 13 Jun 2014 07:19:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1WvLlu-0002DQ-H1 for pgsql-performance@postgresql.org; Fri, 13 Jun 2014 07:19:34 +0000 Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]) by makus.postgresql.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WvLlr-0002Hx-5S for pgsql-performance@postgresql.org; Fri, 13 Jun 2014 07:19:32 +0000 Received: by mail-wi0-f177.google.com with SMTP id r20so335160wiv.10 for ; Fri, 13 Jun 2014 00:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version:content-type; bh=pMmY2AD6LKx1LwZa6jZEp4WfNmkO2XheRJZiHNN5jAs=; b=YPn7H0SsUMWYIRUTCDqjtd4tdGYRx/1pw31Af3WDm1gCAVJ6FgfKmrDwuzDGP/vGVx JVBEC9NVBcWY/V2AWCkl9hh3yrN3iv+LYx4529qqtEP29F382KY/Xwbla5BHIVyoizfK vLOMckB5KQoraLRGYdLcboI0f+YOEBQLgpCjxZ3hVWwLzXM+S0ZO2S24ySWFs6MQ9AJv L0TroaPFSLYsTsM1T7E2ouCUbibsYwEeCtfDFTX6nFm1nRjxUKdLaJlZ48WiSiMtnxqK xU52lewj98m+THFLQjEEdapvKt2sgVhXsMsKkKFSNVex8CvY1rM/ennxz/ziTNcmtwjH IGUg== X-Received: by 10.194.120.68 with SMTP id la4mr1542509wjb.40.1402643969396; Fri, 13 Jun 2014 00:19:29 -0700 (PDT) Received: from [192.168.0.13] (cpc14-dals19-2-0-cust193.20-2.cable.virginm.net. [62.31.88.194]) by mx.google.com with ESMTPSA id a1sm835722wiy.15.2014.06.13.00.19.23 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 13 Jun 2014 00:19:28 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.1.140326 Date: Fri, 13 Jun 2014 08:19:19 +0100 Subject: Re: postgres files in use not staying in linux file cache From: Tim Kane To: Shaun Thomas , Brio , Message-ID: Thread-Topic: [PERFORM] postgres files in use not staying in linux file cache References: <53977376.3040406@optionshouse.com> In-Reply-To: <53977376.3040406@optionshouse.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3485492367_119388238" X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3485492367_119388238 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable >=20 > From: Shaun Thomas > Date: Tuesday, 10 June 2014 22:07 > So here's the thing. The Linux page reclamation code is *extremely > broken* in everything before 3.11. Take a look at this, then realize > that this is *only one patch* from several that target the memory > manager weightings: >=20 > >=20 > Since you're using Ubuntu 12.04, I strongly suggest upgrading your core > to 12.04.4 and apply the linux-generic-lts-saucy pseudo-package to at > least get onto the 3.11 instead. The 3.2 kernel is pants-on-head > retarded; we've had a lot more luck with 3.8 and above. >=20 Without trying to hijack this thread, is there any documentation around recommended or known-good kernels for Postgres/DB type workloads? I can see there has been a lot of discussion around recent kernel developments being detrimental (or potentially detrimental) - http://www.postgresql.org/message-id/20140115141408.GJ4963@suse.de - , but there doesn=E2=80=99t seem to be a definitive resource to know which kernels to avoid. I ask because I=E2=80=99ve just read your statement above about 3.2 being pants-on-head, and having had more luck with 3.8 and above =E2=80=93 despite most installations being on much older (2.6.19) kernels (as per the thread). I=E2=80=99d be interested to see how much benefit we=E2=80=99d get from moving off 3.2,= but I=E2=80=99d like to be aware of the risks of more recent kernel version=E2=80=99s also. Cheers, TIm --B_3485492367_119388238 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable


From: Shaun Thomas <sthomas@optionshouse.com>
Date: Tuesday, 10 June 2014 22:07
So here's the= thing. The Linux page reclamation code is *extremely
broken* in = everything before 3.11. Take a look at this, then realize
that th= is is *only one patch* from several that target the memory
manage= r weightings:

<snipped>

Since you= 're using Ubuntu 12.04, I strongly suggest upgrading your core
to= 12.04.4 and apply the linux-generic-lts-saucy pseudo-package to at
least get onto the 3.11 instead. The 3.2 kernel is pants-on-head
retarded; we've had a lot more luck with 3.8 and above.


<= /div>
Without trying to hijack this thre= ad, is there any documentation around recommended or known-good kernels for = Postgres/DB type workloads?
I can = see there has been a lot of discussion around recent kernel developments bei= ng detrimental (or potentially detrimental) -  http://www.postgresql.o= rg/message-id/20140115141408.GJ4963@suse.de - , but there does= n’t seem to be a definitive resource to know which kernels to avoid.

I ask because I’ve just read your state= ment above about 3.2 being pants-on-head, and having had more luck with 3.8 = and above – despite most installations being on much older (2.6.19) ke= rnels (as per the thread).
I’d be interested to see how much= benefit we’d get from moving off 3.2, but I’d like to be aware = of the risks of more recent kernel version’s also.

Cheers,

TIm



--B_3485492367_119388238--