On 12/06/2014 9:21 a.m., babajaga wrote:
>>
>> What is your
>> "maximum_object_size_in_memory"
>
> The default value: 512 kB
>
>
> Increase above 82 MB. Usually squid 2.7 keeps only in-transit objects in
> memory, then in memory_cache, until swapped out later on. So this might
> inhibit the swap-out to disk, because not being cached before in memory.
It should have a disk file opened for it and filled as it arrives.
I am thinking the described behavioru matches what Squid older than 3.5
do if asked to download multiple copies of a file before the first copy
has been cached and made available for transfer...
Each time Squid is required to download a file it begins to do so. If a
second request arrives before the first is finished it is also a MISS
and new download started.
When the first request finishes its response becomes available for
future request to HIT on.
When the second (MISS) request finishes download it *replaces* the first
one. This is where things can get a litte strange...
1) if the second request is a full object to store, then it just takes
over as source copy for future HITs.
2) if the second request was a range (not cacheable) then it also gets
released because range responses are not cacheable by Squid yet.
#2 may occur on Range request replies, or an download aborted situations
(incompete object "range") which is what is being described by Karl.
It is correct for Squid to drop the cached file as the original copy is
now known to have been updated/reaplced by a copy which it cannot cache.
As to solving, I suggest you try setting:
range_offset_limit 100 MB
quick_abort_min -1
Also, "collapsed_forwarding on" may help reduce the duplicate tansfers
being made in the first place.
Amos
Received on Thu Jun 12 2014 - 10:34:38 MDT
This archive was generated by hypermail 2.2.0 : Thu Jun 12 2014 - 12:00:05 MDT