[squid-users] 3.5.27 to 4.4: a worker is dead

Alex Rousskov rousskov at measurement-factory.com
Thu Nov 8 06:07:36 UTC 2018


On 11/7/18 8:32 PM, Amos Jeffries wrote:

>> 2018/11/07 07:17:03 kid4| WARNING: disk-cache maximum object size is too
>> large for mem-cache: 4194304.00 KB > 2048.00 KB

> It is part of rock design that the cache contents have to be able to be
> stored in memory.

FTR, the above statement is incorrect: There is no such requirement in
rock design. Needless to say, on-disk objects larger than maximum
in-memory object size cannot be cached in memory, but that is true for
any Squid configurations, not just those using rock cache_dirs.


> rock was designed for caches in the MB ranges

The above statement is also incorrect: Rock was designed for GBs and
even TBs worth of cached content. There are still many things that can
be done in rock to support large caches better, of course, but
optimizing MBs-sized caches specifically was never a design objective.


> Keep in mind that rock was designed and optimized for caches of several
> hundred *MB* with millions of small 0-32KB sized objects.

Optimized? Probably -- most cached objects in most deployment
environments are indeed small.

Designed? No. One of the LargeRock project explicit goals was support
for cached objects that are several GBs in size:
https://wiki.squid-cache.org/Features/LargeRockStore


> Squid caching is intended for the two types to work together for best
> performance at all object size ranges.

Not really: Rock cache_dirs should not be used together with UFS-based
disk caches, especially in SMP environments where UFS-based disk caches
should not be used at all.


I realize that the above corrections may not help resolve the problem OP
is facing. I just did not want those misstatements to be archived
unaddressed.

Alex.


More information about the squid-users mailing list