On 02/09/2018 06:42 PM, Ivan Larionov wrote:
> Hello!
>
> Is it possible to get a metric similar to "LRU reference age" (or "LRU
> expiration") when using heap LRU/LFUDA and aufs/rock?
>
> What we need to do is to figure out the age of the oldest least accessed
> object in the cache. Or the age of the last replaced object.
>
> If my description is somehow unclear – we need to answer the question
> "How many days ago the oldest object which is not being accessed anymore
> has been put in the cache."
>
> With aufs/lru we had "LRU reference age" or something like this in
> mgr:info report, but with currently used heap lru/lfuda and rock/aufs I
> don't see it there. SNMP metric also shows:
>
>> SQUID-MIB::cacheCurrentLRUExpiration.0 = Timeticks: (0) 0:00:00.00
I cannot answer your question for aufs, but please note that rock
cache_dirs do not support/have/use a configurable replacement policy:
Each incoming object is assigned a slot based on its key hash. With
modern rock code, it is possible to remove that limitation IIRC, but
nobody have done that.
> If you're wondering why would we need to know that – it's related to
> GDPR and removing data of closed customer's accounts. We need to make
> sure that we don't have any "not being accessed anymore" objects older
> than "data retention period" days.
If it is important to get this right, then I would not trust replacement
policy metadata with this: The corresponding code interfaces look
unreliable to me, and access counts/timestamps for a ufs-based cache_dir
are not updated across Squid restarts when the swap log is lost (at least).
I would instead configure Squid to prohibit serving hits that are too
old. That solution does not match your problem exactly, but it may be
good enough and should work a lot more reliably across all cache_dirs.
If there is no "age" ACL to use with the send_hit directive, then you
may need to add one.
http://www.squid-cache.org/Doc/config/send_hit/
You may also be able to accomplish the same using refresh_pattern, but I
am a little worroed about various exceptional/special conditions
implemented on top of that directive. Others on this list may offer
better guidance in this area.
HTH,
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
