Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M244196=pgsql-hackers-arkari@postgresql.org>)
 id 1WBx0M-00055i-B5
 for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Feb 2014 01:46:50 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-hackers-owner+M244196=pgsql-hackers-arkari@postgresql.org>)
 id 1WBx0L-0000IT-Hy
 for pgsql-hackers@arkaria.postgresql.org; Sat, 08 Feb 2014 01:46:49 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <jason@citusdata.com>) id 1WBx0K-0000IH-75
 for pgsql-hackers@postgresql.org; Sat, 08 Feb 2014 01:46:48 +0000
Received: from mail-ie0-x22e.google.com ([2607:f8b0:4001:c03::22e])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <jason@citusdata.com>) id 1WBx0H-0000dr-2E
 for pgsql-hackers@postgresql.org; Sat, 08 Feb 2014 01:46:47 +0000
Received: by mail-ie0-f174.google.com with SMTP id tp5so2108331ieb.5
 for <pgsql-hackers@postgresql.org>; Fri, 07 Feb 2014 17:46:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=citusdata.com; s=google;
 h=content-type:mime-version:subject:from:in-reply-to:date:cc
 :content-transfer-encoding:message-id:references:to;
 bh=hxWEKJvMkIE1cs4DbyGxxaIrELi/sCk6hkNqsgEMC0M=;
 b=cfnMIJamdNbnlofgXxdA99IyTbh2DXdiCKY/w/w8yeeG4jgHyBrS2kcU87w9w4Nbu0
 mpvExK12PCHoaVuc77WKDb88NGF7WDJ1MITvGcKxVexLLRJS/XDwLrzeAsqRg5mMTcMy
 48ufo56ITGDUOjGsjznf6Hozbm1Gy2lEXVmks=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:content-type:mime-version:subject:from
 :in-reply-to:date:cc:content-transfer-encoding:message-id:references
 :to; bh=hxWEKJvMkIE1cs4DbyGxxaIrELi/sCk6hkNqsgEMC0M=;
 b=IpNbhY7WoiYke/6zwmMN36ed20JB3ZHZdnUn2EWJwqMW984AgIiYNMlV2h7mXvoaBb
 IjlXpRQoEzqI2agGd5rKxmF476ouzqpIetB5ag50D4IrpCFdf+SqoFFgZkyznchqPpew
 f0ZL3efaJGqfvD+TfmuBrdOS7ah5xSwHLR0Zmb3SW/3kGTtUCyEcJTBbe71UXzqnOBkR
 cZ++iQjhGLgZ7KB8YVYrjm2REP8uynfvtPJ5vtfJ51U0Wpn+TW683s49SV3+EOCWLUhk
 KI8JpflBLDmjxoMxRf8Uu9uHPuXgFRwRIW8fXEffCM1BpMSoCxGxhadeN8bJDmMkQwQ1
 izeA==
X-Gm-Message-State: 
 ALoCoQlacgb7mvpEj5TTSdzP20vqV6OKZc67fYBDZ2ipw92+W5qK5nogfEfPZ39IzYtZRoI6LXiI
X-Received: by 10.50.61.171 with SMTP id q11mr2971427igr.19.1391824003592;
 Fri, 07 Feb 2014 17:46:43 -0800 (PST)
Received: from [10.0.0.148] (c-24-9-96-76.hsd1.co.comcast.net. [24.9.96.76])
 by mx.google.com with ESMTPSA id j7sm15725605igx.4.2014.02.07.17.46.42
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 07 Feb 2014 17:46:43 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: Move unused buffers to freelist
From: Jason Petersen <jason@citusdata.com>
In-Reply-To: 
 <52f58b89.83da0e0a.28de.ffff86bbSMTPIN_ADDED_BROKEN@mx.google.com>
Date: Fri, 7 Feb 2014 18:46:45 -0700
Cc: Robert Haas <robertmhaas@gmail.com>,
 Andres Freund <andres@2ndquadrant.com>, Greg Smith <greg@2ndquadrant.com>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <484F79DA-4885-4013-AD06-F276A8C3416A@citusdata.com>
References: <51928CDA.7030009@2ndQuadrant.com>
	<5194eb32.85d60e0a.1c17.2253SMTPIN_ADDED_BROKEN@mx.google.com>
	<CA+TgmobBckMYLvqjrsWBfc0KGBp5_eD2sPA_g3KZFN2P8p2JUA@mail.gmail.com>
	<519b1d5f.9025b40a.2d07.ffffed08SMTPIN_ADDED_BROKEN@mx.google.com>
	<CA+TgmobawHrzH0tMCgjC=_zmcJxYUo7ttawm4P2jf_tNi6dhLg@mail.gmail.com>
	<519f060c.cade440a.493f.ffffb080SMTPIN_ADDED_BROKEN@mx.google.com>
	<CA+TgmoYhfcANR4ci01Gtd8YFzca=VTW9dVn9TY4RM+OdYqCPPw@mail.gmail.com>
	<51b033cf.25dc420a.1edd.ffff8fd9SMTPIN_ADDED_BROKEN@mx.google.com>
	<CA+TgmoZVPtSWHRWtgV_TwQE1Su3dT9sJeU+KYq+-XObxjxLbaw@mail.gmail.com>
	<51cada34.c31b0f0a.2927.7bfbSMTPIN_ADDED_BROKEN@mx.google.com>
	<CA+TgmobJm0GHk58nUPRQHCGwY25n1DCkU4ku9aQeczZEjiz9mQ@mail.gmail.com>
	<51cd16b6.a2d8420a.2b95.ffffb090SMTPIN_ADDED_BROKEN@mx.google.com>
 <CA+TgmoaETz+Oh-bZcM2DVW6Z3h_bQ7MD0tXbpEbOspJ2AVTzUw@mail.gmail.com>
 <52f58b89.83da0e0a.28de.ffff86bbSMTPIN_ADDED_BROKEN@mx.google.com>
To: Amit Kapila <amit.kapila@huawei.com>
X-Mailer: Apple Mail (2.1827)
X-Pg-Spam-Score: -1.8 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Bump.

I=92m interested in many of the issues that were discussed in this thread. =
Was this patch ever wrapped up (I can=92t find it in any CF), or did this t=
hread die off?

=97Jason

On Aug 6, 2013, at 12:18 AM, Amit Kapila <amit.kapila@huawei.com> wrote:

> On Friday, June 28, 2013 6:20 PM Robert Haas wrote:
>> On Fri, Jun 28, 2013 at 12:52 AM, Amit Kapila <amit.kapila@huawei.com>
>> wrote:
>>> Currently it wakes up based on bgwriterdelay config parameter which
>> is by
>>> default 200ms, so you means we should
>>> think of waking up bgwriter based on allocations and number of
>> elements left
>>> in freelist?
>>=20
>> I think that's what Andres and I are proposing, yes.
>>=20
>>> As per my understanding Summarization of points raised by you and
>> Andres
>>> which this patch should address to have a bigger win:
>>>=20
>>> 1. Bgwriter needs to be improved so that it can help in reducing
>> usage count
>>> and finding next victim buffer
>>>   (run the clock sweep and add buffers to the free list).
>>=20
>> Check.
>     I think one way to handle it is that while moving buffers to freelist,
> if we find
>     that there are not enough buffers (>=3D high watermark) which have ze=
ro
> usage count,=20=20
>     then move through buffer list and reduce usage count. Now here I think
> it is important
>     how do we find that how many times we should circulate the buffer list
> to reduce usage count.
>     Currently I have kept it proportional to number of times it failed to
> move enough buffers to freelist.
>=20
>>> 2. SetLatch for bgwriter (wakeup bgwriter) when elements in freelist
>> are
>>> less.
>>=20
>> Check. The way to do this is to keep a variable in shared memory in
>> the same cache line as the spinlock protecting the freelist, and
>> update it when you update the free list.
>=20
>=20
>  Added a new variable freelistLatch in BufferStrategyControl
>=20
>>> 3. Split the workdone globallock (Buffreelist) in StrategyGetBuffer
>>>   (a spinlock for the freelist, and an lwlock for the clock sweep).
>>=20
>> Check.
>=20
> Added a new variable freelist_lck in BufferStrategyControl which will be
> used to protect freelist.
> Still Buffreelist will be used to protect clock sweep part of
> StrategyGetBuffer.
>=20
>=20
>=20
>>> 4. Separate processes for writing dirty buffers and moving buffers to
>>> freelist
>>=20
>> I think this part might be best pushed to a separate patch, although I
>> agree we probably need it.
>>=20
>>> 5. Bgwriter needs to be more aggressive, logic based on which it
>> calculates
>>> how many buffers it needs to process needs to be improved.
>>=20
>> This is basically overlapping with points already made.  I suspect we
>> could just get rid of bgwriter_delay, bgwriter_lru_maxpages, and
>> bgwriter_lru_multiplier altogether.  The background writer would just
>> have a high and a low watermark.  When the number of buffers on the
>> freelist drops below the low watermark, the allocating backend sets
>> the latch and bgwriter wakes up and begins adding buffers to the
>> freelist.  When the number of buffers on the free list reaches the
>> high watermark, the background writer goes back to sleep.  Some
>> experimentation might be needed to figure out what values are
>> appropriate for those watermarks.  In theory this could be a
>> configuration knob, but I suspect it's better to just make the system
>> tune it right automatically.
>=20
> Currently in Patch I have used low watermark as 1/6 and high watermark as
> 1/3 of NBuffers.
> Values are hardcoded for now, but I will change to guc's or hash defines.
> As far as I can think there is no way to find number of buffers on freeli=
st,
> so I had added one more variable to maintain it.
> Initially I thought that I could use existing variables firstfreebuffer a=
nd
> lastfreebuffer to calculate it, but it may not be accurate as
> once the buffers are moved to freelist, these don't give exact count.
>=20
> The main doubt here is what if after traversing all buffers, it didn't fi=
nd
> enough buffers to meet=20
> high watermark?
>=20
> Currently I just move out of loop to move buffers and just try to reduce
> usage count as explained in point-1
>=20
>>> 6. There can be contention around buffer mapping locks, but we can
>> focus on
>>> it later
>>> 7. cacheline bouncing around the buffer header spinlocks, is there
>> anything
>>> we can do to reduce this?
>>=20
>> I think these are points that we should leave for the future.
>=20
> This is just a WIP patch. I have kept older code in comments. I need to
> further refine it and collect performance data.
> I had prepared one script (perf_buff_mgmt.sh) to collect performance data
> for different shared buffers/scalefactor/number_of_clients
>=20
> Top level points which still needs to be taken care:
> 1. Choose Optimistically used buffer in StrategyGetBuffer(). Refer Simon's
> Patch:
>   https://commitfest.postgresql.org/action/patch_view?id=3D743
> 2. Don't bump the usage count on every time buffer is pinned. This idea I
> got when reading archives about=20
>   improvements in this area.
>=20
> With Regards,
> Amit Kapila.
> <changed_freelist_mgmt.patch><perf_buff_mgmt.sh>



--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers