Bruce Momjian <[EMAIL PROTECTED]> wrote: > > 566.973777 > > 327.158222 <- (1) write() > > 560.773868 <- (2) sleep > > 544.106645 <- (3) fsync() > > OK, so you are saying that performance dropped only during the write(), > and not during the fsync()? Interesting.
Almost yes, but there is a small drop in fsync. (560->540) > I would like to know the > results of a few tests just like you reported them above: > > 1a) write spread out over 30 seconds > 1b) write with no delay > > 2a) sleep(0) > 2b) sleep(30) > > 3) fsync > > I would like to know the performance at each stage for each combination, > e.g. when using 1b, 2a, 3, performance during the write() phase was X, > during the sleep it was Y, and during the fsync it was Z. (Of course, > sleep(0) has no stage timing.) I'm thinking about generalizing your idea; Adding three parameters (checkpoint_write, checkpoint_naptime and checkpoint_fsync) to control sleeps in each stage. 1) write() spread out over 'checkpoint_write' seconds. 2) sleep 'checkpoint_naptime' seconds between write() and fsync(). 3) fsync() spread out over 'checkpoint_fsync' seconds. If three parameter are all zero, checkpoints behave as the same as now. If checkpoint_write = checkpoint_timeout and other two are zero, it is just like my proposal before. As you might expect, I intend the above only for development purpose. Additinal three parameters are hard to use for users. If we can pull out some proper values from the tests, we'd better to set those values as default. I assume we can derive them from existing checkpoint_timeout. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
