Re: [squid-users] Re: why RELEASE?

> On Wed, Apr 1, 2009 at 11:03 PM, Brian J. Murrell <brian_at_interlinx.bc.ca>
> wrote:
>> On Wed, 01 Apr 2009 05:37:04 -0400, Brian J. Murrell wrote:
>>
>> On Wed, 2009-04-01 at 05:37 -0400, Brian J. Murrell wrote:
>>>
>>> Why would such a static object be removed from the cache when there is
>>> so much space available.
>>
>> Here's an even more interesting example:
>>
>> 1238597521.686 RELEASE 00 000142CA 0F06582B61087E2A5C6BE02A200A9AA2
>> Â 200 1238597521 1238558186 Â Â Â Â -1 text/plain 428970/9796 GET
>> http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.9-4ubuntu5/changelog
>> 1238597523.126 RELEASE 00 000142CB C261BFF5E1FAF1F044E6342EDB0C1215
>> Â 200 1238597522 1238558186 Â Â Â Â -1 text/plain 428970/9796 GET
>> http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.9-4ubuntu5/changelog
>> 1238597532.285 RELEASE 00 000142CC FF533EA8A884F5E1270245CF1A270A73
>> Â 200 1238597532 1238558186 Â Â Â Â -1 text/plain 428970/8348 GET
>> http://changelogs.ubuntu.com/changelogs/pool/main/g/glibc/glibc_2.9-4ubuntu5/changelog
>>
>> The same URL was fetched 3 times within 11 seconds and each time
>> RELEASEd.
>
> It would be interesting to know whether the object had any explicit
> cacheeability information. Maybe it came with a very short Expires
> timeout, or each time it generates a different ETag.
>
> This trace would seem to indicate that squid decided that the object
> could be cached at access-time, but that it was stale when it tried to
> use it again.
>

IIRC, non-cachable objects larger than max_object_size_in_memory get a
disk object saved for the transition buffer then released when completed
whether they need it or not. One of the inefficiencies we are working
towards killing.

Amos
Received on Wed Apr 01 2009 - 22:35:16 MDT