We're seeing a bunch of the following pairs of RELEASE/SWAPOUT lines for the same URL in our store.log. Can anyone help me understand what's happening here? 1302893424.155 RELEASE 00 000830A0 6E5CACCDB20F6654643A090ACC1B995D 200 1302893423 -1 -1 application/json 2058/2058 GET http://foo.com/alpha 1302893424.155 SWAPOUT 00 000830A2 6E5CACCDB20F6654643A090ACC1B995D 200 1302893424 -1 -1 application/json 2058/2058 GET http://foo.com/alpha 1302893424.332 RELEASE 00 000830A4 28E57991079BA357DCD9AA6C8D435A57 200 1302893424 -1 -1 application/json 2057/2057 GET http://foo.com/beta 1302893424.333 SWAPOUT 00 000830A6 28E57991079BA357DCD9AA6C8D435A57 200 1302893424 -1 -1 application/json 2057/2057 GET http://foo.com/beta Our squid.conf should aggressively cache everything forever, since we're using squid as an application cache against remote web services: # Increased disk cache size to 5GB; currently consuming 2.8GB cache_dir ufs /var/spool/squid3 5000 16 256 ... # Cache everything, forever refresh_pattern . 525600 100% 525600 override-expire ignore-private ignore-n So I don't understand why there are RELEASEs happening at all - I assume that means . If I also interleave lines from access.log: 1302893423.974 SWAPOUT 00 000830A0 6E5CACCDB20F6654643A090ACC1B995D 200 1302893423 -1 -1 application/json 2058/2058 GET http://foo.com/alpha 1302893423.975 255 10.160.227.224 TCP_MISS/200 2372 GET http://foo.com/alpha - DIRECT/173.223.232.122 application/json ... 1302893424.155 RELEASE 00 000830A0 6E5CACCDB20F6654643A090ACC1B995D 200 1302893423 -1 -1 application/json 2058/2058 GET http://foo.com/alpha 1302893424.155 SWAPOUT 00 000830A2 6E5CACCDB20F6654643A090ACC1B995D 200 1302893424 -1 -1 application/json 2058/2058 GET http://foo.com/alpha 1302893424.183 466 10.160.227.224 TCP_MISS/200 2372 GET http://foo.com/alpha - DIRECT/173.223.232.122 application/json 1302894993.280 8 10.160.227.224 TCP_MEM_HIT/200 2381 GET http://foo.com/alpha - NONE/- application/json 1302894993.280 8 10.160.227.224 TCP_MEM_HIT/200 2381 GET http://foo.com/alpha - NONE/- application/json My interpretation is: - the first 2 lines (at time ...23) are for the initial fetch, which saved to disk then recorded as a miss in access.log. All good so far. - the next access of this URL (at time ...24) results in a...release and miss. This is what surprises me. - then subsequent accesses work (hits in memory) Just trying to gain some transparency into squid's decision-making here. Thanks. -- Yang Zhang http://yz.mit.edu/
