[squid-users] Sudden but sustained high bandwidth usage

[Amos Jeffries]

On 10/03/2016 2:17 a.m., Heiler Bemerguy wrote:
> 
> Hi Amos,
> 
> Now you can help me on tracking it down.. lol... can you? I don't know
> what debug_options (apart of 88,3) I should enable.

88,9 to see what else is happening in and around that. I took a quick
look and saw that 88,5 has details about what the followup action was.

But there is something earlier which lead to that "0 bytes" situation. I
am not familar what code paths are operation, so cant point straight at
anything sorry. The 20,9 or 79,9 debug details might display it, but
thats just a guess.


> I just know that disabling range_offset will eliminate this issue,
> because it won't even try to cache range requests. Also, it didn't
> happen when I was using AUFS.
> 
> Another examples:
> 2016/03/09 00:27:54.016 kid2| 88,3| client_side_reply.cc(463) cacheHit:
> clientCacheHit: http://au.download.windowsupdate.com/c/msdownload/upda
> te/software/secu/2016/02/ie11-windows6.1-kb3139929-x64_55bffa59079eb8da45400d6b0432262f96adb3b0.psf,
> 0 bytes
> 2016/03/09 00:27:54.016 kid2| 88,3| client_side_reply.cc(470) cacheHit:
> clientCacheHit: swapin failure for http://au.download.windowsupdate.co
> m/c/msdownload/update/software/secu/2016/02/ie11-windows6.1-kb3139929-x64_55bffa59079eb8da45400d6b0432262f96adb3b0.psf
> 

Nod. UFS/AUFS/diskd are designed for big objects.

> 
> There are some 0 bytes responses (giving a swapin failure) that won't
> give me much trouble because files are small, like this:
> 2016/03/09 09:57:25.107 kid2| 88,3| client_side_reply.cc(463) cacheHit:
> clientCacheHit:
> http://www.mte.gov.br/images/Imagens/Noticias/2016/BRICS31.JPG, 0 bytes
> 2016/03/09 09:57:25.107 kid2| 88,3| client_side_reply.cc(470) cacheHit:
> clientCacheHit: swapin failure for
> http://www.mte.gov.br/images/Imagens/Noticias/2016/BRICS31.JPG
> 
> Looking the source code:
>         debugs(88, 3, "HIT object being deleted. Ignore the HIT.");
>         return;
>     }
> 
>     StoreEntry *e = http->storeEntry();
> 
>     HttpRequest *r = http->request;
> 
>     debugs(88, 3, "clientCacheHit: " << http->uri << ", " <<
> result.length << " bytes");
> 
>     if (http->storeEntry() == NULL) {
>         debugs(88, 3, "clientCacheHit: request aborted");
> 
> I don't get this "deleted", so the object is not being deleted, and
> "request aborted" is not being show too..

The cache index entry that caused it to be a HIT is erased and any
on-disk portion gets a RELEASE. The server gets cotacted to produce a
correct copy, which might re-create those details if the object is
(still) cacheable.

Amos