La prokurilo respondas post restartigo. Kelkajn horojn poste novaj konektoj haltas. Plia restartigo aĉetas alian trankvilan intervalon. Tiu ŝablono sugestas akumuliĝantan staton, sed ĝi ne identigas, kiu stato respondecas.

Sur Linuksa vojo uzanta konektan spuradon, unu kandidato estas la tabelo conntrack. Kontrolu ĉi tiujn ekzistantajn valorojn sur la maŝino kaj en la reta nomspaco, kiu traktas la trafikon:

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

La unua raportas atribuitajn fluajn enskribojn; la dua limigas ilin. Ili ne estas nombroj de Squid-uzantoj aŭ HTTP-petoj. La kernfluo-stato povas postvivi la aktivan laboron de la aplikaĵo.

Serĉu rilaton, ne nur grandan nombron

Komparu la okupadon laŭlonge de la tempo kun la komenco de paneoj de novaj konektoj kaj kun la koncernaj kernaj mesaĝoj. Alta nombro sen konvena pruvo de paneo malsamas de tabelo, kiu ripete atingas sian limon ĝuste kiam petoj komencas tempolimigi.

La tabelo povas servi pli ol la prokurilon. Aliaj lokaj servoj, plusendita trafiko aŭ alia okupata retvojo povas kontribui. Tio, ke restartigo de la prokurilo ŝanĝas la simptomon, ne pruvas, ke la objektkaŝmemoro de Squid kaŭzis ĝin.

Tenu la konkurencajn klarigojn en vido: dosierpriskribiloj, atendovicoj de aŭtentigaj helpiloj, DNS-malfruoj, mempremo kaj plena dosiersistemo ankaŭ povas malboniĝi laŭ la tempo. Notu, kiu rimedo kreskas kaj kiuj operacioj unue ĉesas funkcii. Tio, ke longdaŭraj konektoj postvivas dum novaj malsukcesas, estas utila pruvo, ne diagnozo per si mem.

Pliigi limon havas memorkoston. Antaŭ ol ŝanĝi ĝin, difinu la laborŝarĝon, la nomspacon kaj la disponeblan kapaciton. Senkrite mallongigi tempolimojn povas rompi utilajn senokupajn sesiojn; forigi la tutan konektostaton povas perturbi nerilatan trafikon.

La utila rezulto estas klarigo pri la amasiĝo kaj ŝanĝo de kapacito aŭ vivociklo, kiu konvenas al ĝi. Sekure pliigebla ne estas eco, kiun ĉiu prokurila servilo kunhavas.

Rilataj artikoloj