Zpomalování proxy v čase: zkontrolujte conntrack a limity prostředků

Proxy po restartu reaguje. O několik hodin později se nová spojení zaseknou. Další restart koupí další klidné období. Tento vzorec naznačuje hromadící se stav, ale neříká, který stav je za to odpovědný.

Na linuxové cestě se sledováním spojení je jedním kandidátem tabulka conntrack. Zkontrolujte tyto stávající hodnoty na stroji a v síťovém jmenném prostoru, který provoz zpracovává:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

První hlásí přidělené položky toků; druhý je omezuje. Nejsou to počty uživatelů Squidu ani HTTP požadavků. Stav toku v jádře může přežít aktivní práci aplikace.

Hledejte vztah, ne jen velké číslo

Porovnejte obsazenost v čase s nástupem poruch nových spojení a s příslušnými zprávami jádra. Vysoký počet bez odpovídajících důkazů poruchy se liší od tabulky, která opakovaně dosahuje limitu právě ve chvíli, kdy požadavky začínají končit časovým limitem.

Tabulka může sloužit víc než proxy. Přispět mohou i další místní služby, přeposílaný provoz nebo jiná vytížená síťová cesta. To, že restart proxy změní symptom, nedokazuje, že příčinou byla objektová cache Squidu.

Mějte na zřeteli konkurenční vysvětlení: deskriptory souborů, fronty autentizačních pomocníků, zpoždění DNS, tlak na paměť a plný souborový systém se také mohou v čase zhoršovat. Zaznamenejte, který prostředek roste a které operace přestanou fungovat jako první. To, že dlouhověká spojení přežívají, zatímco nová selhávají, je užitečný důkaz, ale samo o sobě to není diagnóza.

Zvýšení limitu má cenu v paměti. Než ho změníte, zjistěte zátěž, jmenný prostor a dostupnou kapacitu. Bezhlavé zkracování časových limitů může rozbít užitečné nečinné relace; smazání celého stavu spojení může narušit nesouvisející provoz.

Užitečným výsledkem je vysvětlení hromadění a změna kapacity nebo životního cyklu, která k němu pasuje. Bezpečné ke zvýšení není vlastnost, kterou sdílí každý proxy server.