Rob Austein wrote: > At Tue, 11 Nov 2008 19:48:04 -0500, Kevin Darcy wrote: > >> Obviously I'm not making myself very clear. >> >> I'm talking about a box with plenty of memory available, where a lot of >> the commonly-accessed data persists in cache, and the goal is to make >> the turnaround time for queries of this cached data to be >> _consistently_short_. A time-sensitive app might be negatively impacted >> if named decides to kick off a cleaning operation while the app is >> trying to resolve a bunch of names. >> >> One option is to turn off cache-cleaning altogether. But eventually, I >> would think, the memory structures would accumulate junk to the point >> that performance would be impacted anyway. There should be a "sweet >> spot" -- enough cleaning to keep cache fetches efficient, but not so >> much as to give inconsistent query turnaround times because of >> cache-cleaning overhead. Being able to schedule cleaning for times of >> the day/week/month that are known to be low-volume or low-impact (which >> aren't necessarily the same thing), would be ideal. >> > > See the LRU cache cleaner that shipped in 9.5.0. It was a substantial > rewrite of the cache cleaning mechanism, intended to address > essentially this problem, but in a different way than you suggested. > > OK, I'll check it out. Thanks.
- Kevin
