Proxyen svarer etter en omstart. Noen timer senere stopper nye tilkoblinger. En ny omstart kjøper nok et rolig intervall. Mønsteret tyder på opphopet tilstand, men det sier ikke hvilken tilstand som er ansvarlig.

På en Linux-vei med tilkoblingssporing er conntrack-tabellen en kandidat. Kontroller disse eksisterende verdiene på maskinen og i nettverksnavnerommet som håndterer trafikken:

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

Den første rapporterer tildelte flytoppføringer; den andre begrenser dem. Det er ikke antall Squid-brukere eller HTTP-forespørsler. Kjerneflyttilstanden kan overleve applikasjonens aktive arbeid.

Se etter en sammenheng, ikke bare et stort tall

Sammenlign belegget over tid med starten på feil i nye tilkoblinger og med relevante kjernemeldinger. Et høyt tall uten tilsvarende feilbevis er noe annet enn en tabell som gang på gang når grensen sin nettopp når forespørsler begynner å gå ut på tid.

Tabellen kan tjene mer enn proxyen. Andre lokale tjenester, videresendt trafikk eller en annen travel nettverksvei kan bidra. At en omstart av proxyen endrer symptomet, beviser ikke at objektcachen til Squid var årsaken.

Hold de konkurrerende forklaringene i syne: fildeskriptorer, køer hos autentiseringshjelpere, DNS-forsinkelser, minnepress og et fullt filsystem kan også bli verre over tid. Noter hvilken ressurs som vokser og hvilke operasjoner som først slutter å virke. At langvarige tilkoblinger overlever mens nye feiler, er nyttig bevis, ikke en diagnose i seg selv.

Å heve en grense har en minnekostnad. Fastsett arbeidsmengden, navnerommet og tilgjengelig kapasitet før du endrer den. Å forkorte tidsavbrudd vilkårlig kan ødelegge nyttige inaktive økter; å tømme all tilkoblingstilstand kan forstyrre uvedkommende trafikk.

Det nyttige resultatet er en forklaring på opphopningen og en endring i kapasitet eller livssyklus som passer til den. Trygt å heve er ikke en egenskap alle proxyservere deler.

Relaterte artikler