Skip site navigation (1) Skip section navigation (2)

Re: Experimental ARC implementation

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Experimental ARC implementation
Date: 2003-11-03 21:56:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jan Wieck wrote:

> I will follow up shortly with an approach that integrates Tom's delay 
> mechanism plus my first READ_BY_VACUUM hack into one combined experiement.


the attached patch contains the 3 already discussed and one additional 
change. I also made a few changes.

1) ARC policy. Has no configurable options as it is fully self tuning.

2) vacuum_page_delay. I changed the algorithm not to do a usleep() per 
page. The milliseconds usleep() now is done every vacuum_page_groupsize 
pages. This makes especially sense if one can only tune in 10ms intervals.

3) Pages faulted in by VACUUM are placed onto the T1 head (LRU position) 
in the ARC strategy. Thereby vacuum is even more conservative about 
cache pollution than a sequential scan now.

4) A new config option lazy_checkpoint_time causes automatic timeout 
controlled checkpoints (the background ones done by postmaster - and 
only those) to spread out the BufferSync() over the specified amount of 
seconds. This activity does not include the smgrsync() which will 
actually cause the kernel to force the stuff out to disk. But it gives 
the kernel time to do something already, and thereby possibly shortening 
the IO burst caused by smgrsync.

I started with

     vacuum_page_delay = 100
     vacuum_page_groupsize = 25
     checkpoint_timeout = 600
     lazy_checkpoint_time = 300

and the system runs a lot smoother than before. The only not addressed 
performance drop occurs now after flushing all buffers and finally 
syncing during the checkpoints. And I don't have any idea how to tackle 
that one.



# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

Attachment: all_performance.74.diff.gz
Description: application/x-gzip (13.4 KB)

In response to


pgsql-hackers by date

Next:From: Neil ConwayDate: 2003-11-03 22:12:19
Subject: Re: equal() perf tweak
Previous:From: Tom LaneDate: 2003-11-03 21:39:33
Subject: Re: equal() perf tweak

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group