From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bgwriter strategies |
Date: | 2007-07-11 10:01:21 |
Message-ID: | 4694AA71.7040701@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
In the last couple of days, I've been running a lot of DBT-2 tests and
smaller microbenchmarks with different bgwriter settings and
experimental patches, but I have not been able to produce a repeatable
test case where any of the bgwriter configurations perform better than
not having bgwriter at all.
I encountered a strange phenomenon that I don't understand. I ran a
small test case with DELETEs in random order, using an index, on a table
~300MB table, with shared_buffers smaller than that. I expected that to
be dominated by the speed postgres can swap pages in and out of the
shared buffer cache, but surprisingly the test starts to block on the
write I/O, even though the table fits completely in OS cache. I was able
to reproduce the phenomenon with a simple C program that writes 8k
blocks in random order to a fixed size file. I've attached it along with
output of running it on my test server. The output shows how the writes
start to periodically block after a while. I was able to reproduce the
problem on my laptop as well. Can anyone explain what's going on?
Anyone out there have a repeatable test case where bgwriter helps?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
writetest.c | text/x-csrc | 1.0 KB |
writetest-out | text/plain | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2007-07-11 11:51:37 | Re: Bgwriter strategies |
Previous Message | tomas | 2007-07-11 08:15:53 | Re: 2PC-induced lockup |