On Sat, 2005-01-22 at 00:18 -0600, Jim C. Nasby wrote:
> 1) I'm in favor of autotuning anything possible.
> 2) In addition to turning group_commit on and off, what about also
> adjusting the commit delay, based on statistics of recent commits? It
> might require a slightly larger sample set (maybe the last 100 commits),
> but it seems it would provide more flexibility (hence more usefulness)
> to the autotuning.
>
> I belive you'd want to first calculate the elapsed time between each
> commit in the sample set, then look for groupings of elapsed time. If
> you have a set that looks like this:
>
> Time (ms) Number
> 2 *
> 4 *
> 6
> 8 **
> 10 *
> 12 ******
> 14 ****
> 16 **
> 18
> 20 *
>
> then you'd want a delay of 16ms. I think this calculation could be done
> fairly quickly by grouping the commits into buckets of different elapsed
> times, then look for the largest elapsed time that has a number of
> commits greater than the mean number of commits for all the buckets. But
> I'm not a statistician, hopefully someone here is. :)
Yes, I considered that, but since we're talking about a frequently
executed piece of code, I was hoping to keep it short and sweet.
What do others think?
The other issue is the likely time granularity for many OS will be 10ms
anyway, so you have a choice of 0, 10, 20, 30ms... Overall, group commit
isn't much use until the log disk is getting very busy. Delays don't
really need to be more than a disk rotation, so even a laptop can manage
11ms between sequential writes.
I'd suggest hardcoding commit_delay at 10ms, but we still need an on/off
switch, so it seems sensible to keep it. We may be in a better position
to use fine grained settings in the future.
--
Best Regards, Simon Riggs