On Thu, Jan 17, 2002 at 05:38:02PM +0100, Fulvio wrote: > > > Subject: Re: OT Squid > Date: Thu, 17 Jan 2002 17:30:24 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 8bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 6.00.2600.0000 > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 > Resent-Message-ID: <[EMAIL PROTECTED]> > Resent-From: debian-italian@lists.debian.org > X-Mailing-List: <debian-italian@lists.debian.org> archive/latest/12111 > X-Loop: debian-italian@lists.debian.org > Precedence: list > Resent-Sender: [EMAIL PROTECTED] > Resent-Bcc: > Resent-Date: Thu, 17 Jan 2002 10:31:29 -0600 > > > Intanto 16M se li ciula squid e lascia paginati su swap space 3 di quei > MB. > > Il resto della memoria come va? Specifica anche un po' di cosette come > > la versione di kernel e di squid. > > > kernel 2.4.9 e squid 2.4.STABLE3 > > Ora che str monitorando con top ho notato una cosa, e cioh che la > percentuale > di memoria che utilizza squid aumenta lentamente e non diminuisce mai, > quindi tra > un pr deduco che squid si schianter` ....... >
Estratto da un documento garr: Esiste in configurazione un parametro (cache_mem) per dimensionare parte della memoria utilizzata dal processo, ma il valore da configurare dipende molto dalla macchina di cui disponete e dal fatto che essa non sia dedicata o meno al servizio di caching (cosa per altro sempre consigliata, data la natura I/O intensiva del servizio). Inoltre tale dimensionamento h in stretta relazione con la dimensione del file system dedicato al caching. Tenete sempre presente che lo Squid h un processo che che "consuma" memoria, molto di piy di quella che dichiarerete qui, proprio perchh mantiene in RAM sia l'indice degli oggetti memorizzati su disco, per velocizzare la ricerca, sia gli oggetti in transito, oltre che un certo numero di cosiddetti "Hot object", i piy frequentemente acceduti. Premesso questo se il vostro server dispone di xMbyte di RAM la quantit` massima da specificare nel parametro "cache_mem" h bene che sia inferiore al 30% della stessa. Tale dimensione serve in pratica solo a limitare la quantit` dedicata agli oggetti in transito e soprattuto gli Hot Objects, ma non limita MAI la dimensione totale del processo squid, che pur crescere molto di piy, soprattutto in relazione allo spazio disco che viene dedicato al caching (parametro cache_swap). Le considerazioni da fare a proposito del valore di cache_swap sono molto importanti per mantenere elevata efficienza nel sistema. Infatti piy spazio disco si dedica alla cache, piy RAM h richiesta per mantenere il servizio ad un buon livello. Quello che va evitato infatti h il fenomeno della crescita eccessiva del processo, legata al crescere del file degli indici, che viene mantenuto in RAM e pur portare la macchina a paginare, il che farebbe degradare le performance in maniera drammatica. Questo avviene di solito se si eccede nel concedere troppa area disco, a cui poi non corrisponde una adeguata capacit` in RAM. Lo squid infatti tende ad occupare in pochi giorni tutta l'area disco che ha a disposizione (quanto velocemente dipende dal numero di utenti proxy), con la conseguenza di aumentare in modo spropositato il numero di oggetti in essa contenuti, e della relativa tabella degli indici. Nel calcolo tenete presente che ogni oggetto in cache occupa circa 100byte di RAM. Inoltre un'area di circa 8G dedicata al caching arriva a contenere tra i 500K e 600K oggetti. Da qui si deduce che ad un'area da 8G corrisponde una dimensione del processo stimata di 60M solo per la parte di indicizzazione, cui va aggiunta l'area dichiarata come cache_mem (supponiamo altri 50M), per un totale di circa 110M. E' evidente quindi che per una tale configurazione una RAM da 128M appare appena sufficiente, per cui conviene prevederne almeno 256M, per essere sicuri di non incorrere in drammatici problemi di performance. Nel caso in cui non fosse possibile aumentare la RAM, si dovr` necessariamente ridurre l'area cache_mem e piy ancora l'area disco. -- Francesco P. Lovergine
