Hello babajaga,
Thanks a lot your help!
I understand from what you said that squid does not know in which cache_dir a requested object may be located in (it does not search for that object in all the cache_dir's) and that may result in the same object stored in all cache-dir's resulting in lower hit ratio, did I get it right?
Best regards,
Firas
----- Original Message -----
From: babajaga <augustus_meyer@yahoo.de>
To: squid-users@squid-cache.org
Cc:
Sent: Friday, August 9, 2013 4:30 PM
Subject: [squid-users] Re: Extremely Low Request Hit Ratio!
My suspicion is some problem here:
store_dir_select_algorithm least-load
# cache_dir aufs /mnt/cachedrive1 1342177 128 512
cache_dir aufs /mnt/cachedrive2 1426227 128 512
cache_dir aufs /mnt/cachedrive3 1426227 128 512
cache_dir aufs /mnt/cachedrive4 1426227 128 512
cache_dir aufs /mnt/cachedrive5 427008 128 256
Not knowing internal processing within squid in this scenario, but
theoritically there MIGHT be the risk, having the same object cached up to 4
times, because all cache_dir have equal storage properties. Which reduces
overall sum of cachable objects significantly. And MIGHT lead to unnecessary
purge of cached objects, in case a cache_dir almost full.
So I would either use just one large cache_dir (which might then run into
the limit regarding max. number
of cachable objects in one dir 2**24)
or (better solution)
set disjunct limits on the size of cachable objects for the various
cache_dir,
using
cache_dir aufs /mnt/cachedrive2 1426227 128 512 min-size=xxxx max-size=xxxx
And move these lines
minimum_object_size 16 KB
maximum_object_size 512 MB
on top of this one:
maximum_object_size_in_memory 300 KB
--
View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Extremely-Low-Request-Hit-Ratio-tp4661495p4661504.html
Sent from the Squid - Users mailing list archive at Nabble.com.
Received on Sat Aug 10 2013 - 00:24:37 MDT
This archive was generated by hypermail 2.2.0 : Sat Aug 10 2013 - 12:00:08 MDT