What Patrick said. For large sites that offer services in multiple data centers
on multiple IPs that can individually fail at any time, 300 seconds is actually
a bit on the long end.
-C
On Aug 18, 2012, at 3:43 PM, Patrick W. Gilmore patr...@ianai.net wrote:
On Aug 18, 2012, at 8:44, Jimmy
In message ddf607b5-415b-41e8-9222-eb549d3db...@semihuman.com, Chris Woodfiel
d writes:
What Patrick said. For large sites that offer services in multiple data =
centers on multiple IPs that can individually fail at any time, 300 =
seconds is actually a bit on the long end.
-C
Which is why
OK. I think we have something going at http://bgplay.routeviews.org/ again.
Thought I would change things up a bit since we were having problems
with some of
the route-views2 collector data. So the setup now defaults to the data
from the
collectors: route-views.paix.routeviews.org,
On Sun, Aug 19, 2012 at 5:37 PM, Mark Andrews ma...@isc.org wrote:
As for the original problem. LRU replacement will keep hot items in
the cache unless it is seriously undersized.
Maybe. This discussion is reminiscent of the Linux swappiness debate.
Early in the 2.x series Linux kernels, the
On 8/19/12, Mark Andrews ma...@isc.org wrote:
As for the original problem. LRU replacement will keep hot items in
the cache unless it is seriously undersized.
[snip]
Well, that's the problem. Items that are not relatively hot will
be purged, even though they may be very popular RRs. Cache
Re: LRU badness
One approach is called adaptive replacement cache (ARC) which is
used by Oracle/Sun in ZFS, and was used in PostgreSQL for a time
(and slightly modified to (as I recall) to be more like 2Q due to
concerns over the IBM patent on the algorithm). Unfortunately,
we do not have any
6 matches
Mail list logo
