DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk;
	h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type;
	b=vH7UQmVvNAS4ilkbZZa1dncPhG1c2QfDjVp8KJWCZdQt9uNmu3vP5q3hnttHV9gsLSKKjc7yEbTcFOq919e1cHs8s9a0oN5xNQox/RU9ncFnTf4BK36TIkTc/zJDmVZQkB8E9+xatSvPosPrsTYvz2JTRcDevjKCG4rataZAArU=;
References: 
 <CAMAsR=4acKwYjow-VWQ0xH0+WjXEtVJWxP0A0y4vx=oyr5fhpQ@mail.gmail.com>
	<920BB532-C321-45A3-851E-8B688A5963F7@yahoo.com>
	<CAMAsR=7g5PXU45+Z3aBW+ur-kPQKiW2MG=NJ3TOqNn6iqaVCVw@mail.gmail.com>
	<4F7AF966.20809@fuzzy.cz>
	<CAMAsR=637=zAtOSxGF=JH9apfOtU7FaUXR27+J2syzE_c-rdYw@mail.gmail.com>
	<4F7B3AEC.4000204@fuzzy.cz>
	<CAMAsR=7onjeWr--PtgHgfZv=yYSB8FVxf1BsYSwu2752YY0Q8w@mail.gmail.com>
	<CAHyXU0yAy6C__0xbfBH1t_UNai=VVSP9i5p-KKgDAYp3pxAM-Q@mail.gmail.com>
	<CAMAsR=7Xkzcr-G_NO-Jn2yTa+BSayuMMK7Gv7diXDNcC3WNVUw@mail.gmail.com>
	<4F7CA614.8060008@fuzzy.cz>
Message-ID: <1333631401.49335.YahooMailNeo@web171401.mail.ir2.yahoo.com>
Date: Thu, 5 Apr 2012 14:10:01 +0100 (BST)
From: Glyn Astill <glynastill@yahoo.co.uk>
Reply-To: Glyn Astill <glynastill@yahoo.co.uk>
Subject: Re: H800 + md1200 Performance problem
To: Tomas Vondra <tv@fuzzy.cz>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
In-Reply-To: <4F7CA614.8060008@fuzzy.cz>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="-491639913-201178445-1333631401=:49335"

---491639913-201178445-1333631401=:49335
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

> From: Tomas Vondra <tv@fuzzy.cz>=0A=0A> But the fluctuation, that surely =
is strange. What are the page cache=0A> dirty limits, i.e.=0A> =0A> cat /pr=
oc/sys/vm/dirty_background_ratio=0A> cat /proc/sys/vm/dirty_ratio=0A> =0A> =
That's probably #1 source I've seen responsible for such issues (on=0A> mac=
hines with a lot of RAM).=0A> =0A=0A+1 on that.=0A=0AWe're running similar =
32 core dell servers with H700s and 128Gb RAM.=0A=0AWith those at the defau=
lts (I don't recall if it's 5 and 10 respectively) you're looking at 3.2Gb =
of dirty pages before pdflush flushes them and 6.4Gb before the process is =
forced to flush its self.=0A
---491639913-201178445-1333631401=:49335
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:Co=
urier New, courier, monaco, monospace, sans-serif;font-size:12pt">&gt; From=
: Tomas Vondra &lt;tv@fuzzy.cz&gt;<br><div><div> &gt; But the fluctuation, =
that surely is strange. What are the page cache<br>&gt; dirty limits, i.e.<=
br>&gt; <br>&gt; cat /proc/sys/vm/dirty_background_ratio<br>&gt; cat /proc/=
sys/vm/dirty_ratio<br>&gt; <br>&gt; That's probably #1 source I've seen res=
ponsible for such issues (on<br>&gt; machines with a lot of RAM).<br>&gt; <=
br><br>+1 on that.<br><br>We're running similar 32 core dell servers with H=
700s and 128Gb RAM.<br><br>With those at the defaults (I don't recall if it=
's 5 and 10 respectively) you're looking at 3.2Gb of dirty pages before pdf=
lush flushes them and 6.4Gb before the process is forced to flush its self.=
<br></div> </div> </div></body></html>
---491639913-201178445-1333631401=:49335--