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@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@proxy:/etc/squid3# service squid3 stop
squid3 stop/waiting
root@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@proxy:/etc/squid3# service squid3 start
squid3 start/running, process 11687
and now...
root@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@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.
