Proxy odgovara nakon ponovnog pokretanja. Nekoliko sati kasnije nove veze zapinju. Još jedno pokretanje kupuje novi mirni interval. Taj obrazac upućuje na stanje koje se gomila, ali ne pokazuje koje je stanje odgovorno.

Na Linux putu koji koristi praćenje veza jedan je kandidat conntrack tabela. Provjerite ove postojeće vrijednosti na mašini i u mrežnom imenskom prostoru koji obrađuje promet:

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

Prva prijavljuje dodijeljene unose tokova; druga ih ograničava. To nisu brojevi Squid korisnika ni HTTP zahtjeva. Stanje toka u kernelu može nadživjeti aktivni rad aplikacije.

Tražite vezu, ne samo veliki broj

Uporedite zauzetost kroz vrijeme s početkom kvarova novih veza i s relevantnim porukama kernela. Visok broj bez odgovarajućih dokaza o kvaru razlikuje se od tabele koja više puta dosegne granicu upravo kad zahtjevi počnu isticati.

Tabela može služiti više od proxyja. Druge lokalne usluge, proslijeđeni promet ili drugi zauzet mrežni put mogu doprinijeti. To što ponovno pokretanje proxyja mijenja simptom ne dokazuje da je Squidov keš objekata bio uzrok.

Držite konkurentska objašnjenja na vidiku: datotečni deskriptori, redovi pomoćnika za autentifikaciju, kašnjenja DNS-a, pritisak na memoriju i pun datotečni sistem također se mogu pogoršavati s vremenom. Zabilježite koji resurs raste i koje operacije prve prestaju raditi. To što dugotrajne veze preživljavaju dok nove ne uspijevaju koristan je dokaz, ali ne i dijagnoza sama po sebi.

Podizanje ograničenja ima cijenu u memoriji. Prije promjene utvrdite radno opterećenje, imenski prostor i raspoloživi kapacitet. Nasumično skraćivanje vremenskih ograničenja može pokvariti korisne neaktivne sesije; brisanje cijelog stanja veza može poremetiti nepovezani promet.

Koristan rezultat je objašnjenje nagomilavanja i promjena kapaciteta ili životnog ciklusa koja mu odgovara. Sigurno za povećanje nije svojstvo koje dijeli svaki proxy server.

Povezani članci