From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ang Chin Han <angch(at)bytecraft(dot)com(dot)my>, Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Experimental patch for inter-page delay in VACUUM |
Date: | 2003-11-10 15:18:38 |
Message-ID: | 3FAFAC4E.2060907@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> Jan Wieck wrote:
>> Bruce Momjian wrote:
>> > I would be interested to know if you have the background write process
>> > writing old dirty buffers to kernel buffers continually if the sync()
>> > load is diminished. What this does is to push more dirty buffers into
>> > the kernel cache in hopes the OS will write those buffers on its own
>> > before the checkpoint does its write/sync work. This might allow us to
>> > reduce sync() load while preventing the need for O_SYNC/fsync().
>>
>> I tried that first. Linux 2.4 does not, as long as you don't tell it by
>> reducing the dirty data block aging time with update(8). So you have to
>> force it to utilize the write bandwidth in the meantime. For that you
>> have to call sync() or fsync() on something.
>>
>> Maybe O_SYNC is not as bad an option as it seems. In my patch, the
>> checkpointer flushes the buffers in LRU order, meaning it flushes the
>> least recently used ones first. This has the side effect that buffers
>> returned for replacement (on a cache miss, when the backend needs to
>> read the block) are most likely to be flushed/clean. So it reduces the
>> write load of backends and thus the probability that a backend is ever
>> blocked waiting on an O_SYNC'd write().
>>
>> I will add some counters and gather some statistics how often the
>> backend in comparision to the checkpointer calls write().
>
> OK, new idea. How about if you write() the buffers, mark them as clean
> and unlock them, then issue fsync(). The advantage here is that we can
Not really new, I think in my first mail I wrote that I simplified this
new mdfsyncrecent() function by calling sync() instead ... other than
that the code I posted worked exactly that way.
Jan
--
#======================================================================#
# 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 #
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-11-10 15:31:10 | Re: Experimental patch for inter-page delay in VACUUM |
Previous Message | Jan Wieck | 2003-11-10 15:05:04 | Re: Experimental patch for inter-page delay in VACUUM |