From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: Fix overflow of bgwriter's request queue |
Date: | 2006-03-03 00:07:23 |
Message-ID: | 16035.1141344443@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I suspect it'd probably be sufficient to absorb requests every few times
>> through the fsync loop, too, if you want to experiment with that.
> In the above test, smgrsync took 50 sec for syncing 32 files. This means
> absorb are requested every 1.5 sec, which is less frequent than absorbs by
> normal activity of bgwriter (bgwriter_delay=200ms).
That seems awfully high to me --- 1.5 sec to fsync a segment file that
is never larger than 1Gb, and probably usually has much less than 1Gb
of dirty data? I think you must have been testing an atypical case.
I've applied the attached modified version of your patch. In this
coding, absorbs are done after every 1000 buffer writes in BufferSync
and after every 10 fsyncs in mdsync. We may need to twiddle these
numbers but it seems at least in the right ballpark. If you have time
to repeat your original test and see how this does, it'd be much
appreciated.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
absorb.patch | application/octet-stream | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2006-03-03 00:42:44 | Re: New pg_dump options: exclude tables/schemas, multiple |
Previous Message | Neil Conway | 2006-03-02 23:45:38 | Re: INS/UPD/DEL RETURNING for 8.2 |