Re: [squid-users] Re: Splitting objects by size into different cache_dir not working for me

On 02/01/2013 04:04 PM, Alex Rousskov wrote:
> On 02/01/2013 09:42 AM, Luciano Ruete wrote:
>> I've tested with
>>
>> maximum_object_size_in_memory 64 KB
>>
>> And now I have both cache_dir AUFS and rock caching objects and growing
>> at the same time, so thanks for that.
>>
>> But I don't understand the logic behind this, because from the docs
>> about maximum_object_size_in_memory
>> you read:
>>
>> "This should be set high enough to keep objects
>> accessed frequently in memory to improve performance whilst low
>> enough to keep larger objects from hoarding cache_mem."
>>
>> So, i don't see how this can interfere with saving large cache objects
>> into a cache_dir, when the idea of this directive is just preventing
>> larger object to hoarding cache_mem... can you elavorate on this?
> Do HTTP responses that you want to cache have a Content-Length header?

Yes, it is.

> If there is no Content-Length header, then, AFAIK, Squid will only cache
> them to disk if Squid can cache them in memory (or if the whole response
> has been received when the decision to cache on disk has to be made).
>
> [ Why? I have not researched the motivation behind this, but it is how
> caching code have been written long time ago. It is possible to relax
> this restriction by rewriting the relevant code and possibly adding more
> configuration options to control this behavior. ]
>
> If there is a Content-Length header, then there is probably some other
> bug or dependency. Tracking it down would require studying detailed
> debugging logs -- not something you can easily do on your own,
> unfortunately. Consider filing a bug report.

I've already have done that, and now have updated it with further
information, the bug url is:
http://bugs.squid-cache.org/show_bug.cgi?id=3752

>
>> Another thing that happens is that rock cache_dir always start from 0
>> every time squid is restarted, is that the expected behavior?
> No, it is not. Rock, just like ufs, should preserve cached content
> across restarts (and does in my tests). How do you know that "cache_dir
> always start from 0"? Please make sure you do not look at cache
> statistics that is printed by Squid workers. Look at mgr:storedir stats
> returned by diskers. Workers do not load rock store indexes, diskers do.
> Someday, we will find a way to render these stats in a less misleading way.
>

My test is more simple:

root_at_proxy:/etc/squid3# ls -lsh /mnt/cache/squid3/rock/rock
104M -rw------- 1 proxy proxy 1000M feb 1 17:20 /mnt/cache/squid3/rock/rock

104M of rock store used.

root_at_proxy:/etc/squid3# service squid3 stop
squid3 stop/waiting
root_at_proxy:/etc/squid3# ls -lsh /mnt/cache/squid3/rock/rock
104M -rw------- 1 proxy proxy 1000M feb 1 17:20 /mnt/cache/squid3/rock/rock

After stop, the 104M are still there

Then,

root_at_proxy:/etc/squid3# service squid3 start
squid3 start/running, process 11687

and now...

root_at_proxy:/etc/squid3# ls -lsh /mnt/cache/squid3/rock/rock
1016K -rw------- 1 proxy proxy 1000M feb 1 17:21
/mnt/cache/squid3/rock/rock
root_at_proxy:/etc/squid3#

Back to zero point, the 1016K is the size of the rock storage as if I
re-created it with squid -z.

> HTH,
>
> Alex.
>
Received on Fri Feb 01 2013 - 20:28:59 MST