Greg Smith <[EMAIL PROTECTED]> wrote: > The first patch (buf-alloc-stats) takes the two most interesting pieces of > data the original patch collected, the number of buffers allocated > recently and the number that the clients wrote out, and ties all that into > the new stats structure.
> The second patch (limit-lru) adds on top of that a constraint of the LRU > writer so that it doesn't do any more work than it has to. Both patches look good. > Now we get to the controversial part. The original patch removed the > bgwriter_lru_maxpages parameter and updated the documentation accordingly. > I didn't do that here. The reason is that after playing around in this > area I'm not convinced yet I can satisfy all the tuning scenarios I'd like > to be able to handle that way. I describe this patch as enforcing a > constraint instead; it allows you to set the LRU parameters much higher > than was reasonable before without having to be as concerned about the LRU > writer wasting resources. I'm agreeable to the limiters of resource usage by bgwriter. BTW, your patch will cut LRU writes short, but will not encourage to do more works. So should set more aggressive values to bgwriter_lru_percent and bgwriter_lru_maxpages as defaults? My original motivation was to enlarge bgwriter_lru_maxpages automatically; the default bgwriter_lru_maxpages (=5) seemed to be too small. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
