"Takayuki Tsunakawa" <tsunakawa.takay@jp.fujitsu.com> wrote:
> I have to report a sad result. Your patch didn't work. Let's
> consider the solution together. What you are addressing is very
> important for the system designers in the real world -- smoothing
> response time.
You were running the test on the very memory-depend machine.
> shared_buffers = 4GB / The scaling factor is 50, 800MB of data.
Thet would be why the patch did not work. I tested it with DBT-2, 10GB of
data and 2GB of memory. Storage is always the main part of performace here,
even not in checkpoints.
If you use Linux, it has very unpleased behavior in fsync(); It locks all
metadata of the file being fsync-ed. We have to wait for the completion of
fsync when we do read(), write(), and even lseek().
Almost of your data is in the accounts table and it was stored in a single
file. All of transactions must wait for fsync to the single largest file,
so you saw the bottleneck was in the fsync.
> [Conclusion]
> I believe that the problem cannot be solved in a real sense by
> avoiding fsync/fdatasync().
I think so, too. However, I assume we can resolve a part of the
checkpoint spikes with smoothing of write() alone.
BTW, can we use the same way to fsync? We call fsync()s to all modified
files without rest in mdsync(), but it's not difficult at all to insert
sleeps between fsync()s. Do you think it helps us? One of issues is that
we have to sleep in file unit, which is maybe rough granularity.
Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center