|
No doubt, the connections were really being closed by the proxy
itself, LIKE it was finished sending the request. It was like a
loop, so it was infinite connections one right after another, but
not in parallel.. the fin-packets and everything else were "in
order" judgjing by their SEQ values too. There were other refresh_patterns but none matching it. I didn't enable debug options but I can try to reproduce it.. anyway the .conf was like that for years and this was the first time a "loop" like this occurred. I upgraded from 3.5.27 to 3.5.28 but I think nothing about this was modified recently, right..? I know most refresh_pattern options were being ignored/wrong, that's why I've disabled it altogether, and right after it, the proxy replied to the client with a TCP_REFRESH_MODIFIED instead of a TCP_HIT and the loop was gone. The remaining options are: refresh_pattern . 0 80% 1440 reload_into_ims off quick_abort_min 0 KB quick_abort_max 0 KB quick_abort_pct 95 with no range_offset_limits look how tiny (427 bytes) all the responses were.. and a HIT for a range request is almost a miracle here.. lol (RockStore) 1542994021.243 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.326 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.399 2 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.514 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.614 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.718 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.824 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994021.966 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994022.124 1 10.15.3.137 TCP_HIT/206 427 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_NONE/- application/x-gzip 1542994036.811 14390 10.15.3.137 TCP_REFRESH_MODIFIED/206 26733678 GET http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_20181120.1.orig.tar.gz - HIER_DIRECT/91.189.92.150 application/x-gzip -- Atenciosamente, Heiler Bensimon Bemerguy - CINBESA Analista de Redes, Wi-Fi, Virtualização e Serviços Internet (55) 91 98151-4894 Em 24/11/2018 03:33, Amos Jeffries
escreveu:
On 24/11/18 6:28 am, Heiler Bemerguy wrote:Hum, disabling that refresh_pattern and -k reconfigure seems to have fixed it.. but.. why?Something else is going on which is not visible in the details you have shown. - is the TCP connection containing a message pipeline? if so the data and FIN may be related to a previous response message in that pipeline. - are other refresh patterns being used (probably yes) ? - what are they? (before and after the change) - what did your cache.log have to say at the time of the connection termination? (may need debug level 2 or 5 enabled) Also, you were using override-* and ignore-* settings in that refresh_pattern that are not necessary for the Debian/Ubuntu servers. At best they will be doing nothing to these responses (ie ignore-no-store, ignore-private do nothing to Debian/Ubuntu responses). Some will be causing *worse* caching service from the proxy. override-lastmod with your small [84 day] expiry vastly reduces the _years_ these objects can actually be cached for, and prevents IMS revalidation being used to determine changes properly and store un-changed things longer. NP: Debian/Ubuntu official repositories do fully support IMS revalidation. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users |
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
