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.
Okay,
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 = 300and 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.
Comments/Feedback?
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
all_performance.74.diff.gz
Description: GNU Zip compressed data
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
