> On Wed, Apr 1, 2009 at 11:03 PM, Brian J. Murrell <brian@xxxxxxxxxxxxxxx> > 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
