9.6. Disk Storage

La direttiva cache_dir contenuta nel file di configurazione squid.conf, definisce una tipologia di Disk Storage che non ha nulla a che vedere con il tipo di file system fisicamente utilizzato dal Sistema Operativo. Il Disk Storage di Squid definisce unicamente il metodo di accesso e di implementazione utilizzati internamente dal processo Squid per la gestione del Disk I/O. Attualmente vengono implementati ben 5 differenti sistemi di Disk Storage

la scelta del tipo di Disk Storage da attivare, viene effettuata nel momento della configurazione dei parametri di compilazione di Squid

% ./configure --enable-storeio="elenco disk storage"
  

dove l'elenco dei Disk Storage da attivare contiene i nomi (case sensitive) delle cartelle che sono incluse nel source tree di Squid e che ne contengono i sorgenti. Il Disk Storage che viene compilato come default é ufs

% ./configure --enable-storeio="ufs aufs diskd null"
  

nell'esempio precedente abbiamo selezionato i Disk Storage ufs, aufs, diskd e null. Selezionando uno qualunque di questi sistemi di Disk Storage, viene automaticamente impostato e compilato anche il Disk Storage ufs in quanto necessario al corretto funzionamento di tutti i tipi di Disk Storage selezionati. La selezione del Disk Storage da utilizzare avviene tramite il TAG cache_dir di squid.conf, la sintassi generica è la seguente

cache_dir Type Directory-Name Fs-specific-data [options]
  

I valori di default sono

cache_dir ufs /usr/local/squid/var/cache 100 16 256
  

le options sono comuni a tutti i tipi di Disk Storage e si suddividono in

read-only
max-size=n
  

read-only indica che questa cache_dir é di sola lettura mentre max_size identifica la dimensione massima di oggetto che questa cache_dir può immagazzinare. É possibile specificare in squid.conf più di una definizione di cache_dir, anche se la stessa utilizza un differente tipo di Disk Storage, infatti a partire dalla versione 2 di Squid, è possibile aggiungere nuove cache_dir in qualsiasi momento e renderle attive senza ricavarne alcun effetto collaterale.

9.6.1. ufs storage

È il Disk Storage system originario e nativo di Squid, si basa su una struttura di directory a 2 livelli dove i valori di default prevedono ben 16 directory per il primo livello (L1) e 256 per il secondo (L2). Tutti gli oggetti presenti nella cache di Squid sono immagazzinati come file all'interno del secondo livello, tutte le operazioni di I/O sono gestite in modalità sincrona direttamente dal Sistema Operativo e possono bloccare il funzionamento del processo principale di Squid sino al loro completamento. La sintassi del TAG cache_dir per il Disk Storage ufs é

cache_dir ufs Directory-Name MBytes L1 L2 [options]
   

dove Directory-Name identifica la top-level directory nella quale i files saranno immagazzinati, L1 è il numero di directory di primo livello, L2 è il numero di directory di secondo livello ed il numero massimo di oggetti per directory, infine MBytes indica la dimensione massima in MBytes di questo Disk Storage, ecco un esempio

cache_dir ufs /usr/local/squid/var/cache 4096 16 256
   

9.6.2. aufs storage

Utilizza il medesimo formato di storage su disco di ufs, tutte le operazioni di I/O sono gestite in modalità asincrona utilizzando il modello POSIX-threads, aufs utilizza quindi dei processi di tipo thread che gli consentono di eseguire le operazioni di disk I/O. Questo modello di storage consente di evitare il blocco del processo principale di Squid durante tutte le operazioni di disk I/O in quanto le stesse vengono inoltrate ad un processo thread differente. Questo tipo di Disk Storage viene spesso indicato anche come async-io e non può essere utilizzato efficacemente sui Sistemi che implementano il modello dello user-threads, il codice aufs richiede la presenza della libreria pthreads. Questo tipo di Disk Storage non é disponibile sulle piattaforme Windows e funziona unicamente sulle piattaforme Linux, FreeBSD e Solaris. La sintassi del TAG cache_dir per il Disk Storage aufs é

cache_dir aufs Directory-Name MBytes L1 L2 [options]
   

Dove Directory-Name identifica la top-level directory ove i files verranno immagazzinati, L1 è il numero di directory di primo livello, L2 è il numero di directory di secondo livello ed il numero massimo di oggetti per directory ed infine MBytes è la dimensione massima espressa in MBytes per questo Disk Storage. Ecco un esempio

cache_dir aufs /usr/local/squid/var/cache 8192 16 256
   

Il numero di thread in uso viene calcolato dinamicamente in funzione del numero delle cache_dir definite, la seguente tabella mostra il numero di thread predefiniti sino a 6 cache_dir

cache_dir

threads

1

16

2

26

3

32

4

36

5

40

6

44



in alternativa è possibile forzare il numero di thread al momento della compilazione di Squid ricorrendo all'opzione --with-aio-threads=N di ./configure

% ./configure --with-aio-threads=32
   

utilizzando il cache manager è possibile visualizzare le statistiche relative a aufs

% squidclient mgr:squidaio_counts
HTTP/1.0 200 OK
Server: squid/2.5.STABLE5
Mime-Version: 1.0
Date: Tue, 06 Apr 2004 19:08:27 GMT
Content-Type: text/plain
Expires: Tue, 06 Apr 2004 19:08:27 GMT
Last-Modified: Tue, 06 Apr 2004 19:08:27 GMT
X-Cache: MISS from portatilo.miodominio.net
Proxy-Connection: close
ASYNC IO Counters:
Operation       # Requests
open    93
close   93
cancel  93
write   0
read    108
stat    0
unlink  5
check_callback  9312
queue   0
   

9.6.3. awin32 storage

Si tratta del port nativo di aufs per la piattaforma Windows. Anche in questo caso, tutte le operazioni di I/O sono gestite in modalità asincrona utilizzando i Win32 native threads, questo tipo di approccio serve per evitare il blocco del processo principale di Squid durante le operazioni di disk I/O. La sintassi del TAG cache_dir per il Disk Storage awin32 é

cache_dir awin32 Directory-Name MBytes L1 L2 [options]
   

dove Directory-Name identifica la top-level directory dove i files saranno salvati, L1 è il numero di directory di primo livello, L2 è il numero di directory di secondo livello ed il numero massimo di oggetti per directory, infine MBytes indica la dimensione massima espressa in MBytes di questo Disk Storage. Di seguito ecco un esempio

cache_dir awin32 c:/squid/var/cache 4096 16 256
   

9.6.4. diskd storage

Diskd è l'acronimo di disk daemons ed utilizza il medesimo formato di storage di ufs, concettualmente è molto simile ad aufs, l'unica differenza che distingue diskd da aufs risiede nel fatto che tutte le operazioni di I/O vengono gestite in modalità asincrona ricorrendo ad un programma esterno per ogni cache_dir. Questo sistema consente di evitare il blocco del processo principale di Squid durante le operazioni di disk I/O, diskd dunque non utilizza i threads e le funzioni IPC[1] vengono implementate ricorrendo alla memoria condivisa (shared memory) e alla coda dei messaggi (message queue) del Sistema Operativo. La coda dei messaggi è implementata per la prima volta dalla AT&T con il rilascio dello UNIX® System V, Release 1. Diskd viene particolarmente indicato sui sistemi che implementano il modello dello user-threads come FreeBSD ed OpenBSD; funziona anche con Linux, Solaris e Digital Unix® mentre non è disponibile sulle piattaforme Windows. La sintassi del TAG cache_dir per il Disk Storage diskd é

cache_dir diskd Directory-Name MBytes L1 L2 [options] [Q1=n] [Q2=n]
   

dove Directory-Name identifica la top-level directory in cui i file verranno immagazzinati, L1 è il numero di directory di primo livello, L2 è il numero di directory di secondo livello nonchè il numero massimo di oggetti per directory, infine MBytes rappresenta la dimensione massima espressa in MBytes per questo Disk Storage. I Parametri Q1 e Q2 indicano rispettivamente la lunghezza massima della coda di I/O per il blocco dell'apertura di nuovi files e la lunghezza massima della coda di I/O per l'inizio del funzionamento in modalità blocking. I valori predefiniti sono 72 e 64. È inoltre necessario specificare il percorso dell'eseguibile del programma diskd. Questa funzionalità viene attivata solo se abbiamo compilato Squid con il supporto a diskd, il TAG da indicare nel file squid.conf è

diskd_program diskd-path
   

di seguito un esempio

cache_dir diskd /usr/local/squid/var/cache 8192 16 256 Q1=72 Q2=64
diskd_program /usr/local/squid/libexec/diskd
   

utilizzando il Cache Manager è possibile visualizzare le prestazioni del diskd

% squidclient mgr:diskd
HTTP/1.0 200 OK
Server: squid/2.5.STABLE5
Mime-Version: 1.0
Date: Tue, 06 Apr 2004 19:56:57 GMT
Content-Type: text/plain
Expires: Tue, 06 Apr 2004 19:56:57 GMT
Last-Modified: Tue, 06 Apr 2004 19:56:57 GMT
X-Cache: MISS from proxy.miodominio.net
Proxy-Connection: close
sent_count: 132233
recv_count: 132233
max_away: 26
max_shmuse: 25
open_fail_queue_len: 0
block_queue_len: 0
             OPS SUCCESS    FAIL
   open   21674   21663      11
 create    5478    5478       0
  close   27141   27141       0
 unlink   21294    5873   15421
   read   36111   36100       0
  write   20535   20535       0
   

9.6.4.1. Tuning dei parametri Q1 e Q2

Abbiamo già parlato in precedenza dei valori Q1 e Q2, nel codice sorgente di Squid vengono chiamati magic1 e magic2 e si riferiscono al numero di richieste di I/O che vengono contenute nella coda dei messaggi che rimangono in attesa di un acknowledge da parte di diskd. Questi valori vengono specificati nel TAG cache_dir, dopo aver impostato le directory di livello L1 e L2, il formato del TAG è

cache_dir diskd Directory-Name MBytes L1 L2 [options] [Q1=n] [Q2=n]
    

quando la lunghezza della coda dei messaggi raggiunge il valore Q1, Squid intenzionalmente fallisce l'apertura dei files sul disco per quello che concerne le operazioni di lettura e scrittura. Si tratta di un efficente meccanismo di load-shedding, letteralmente tradotto come spargimento delle richieste. Se la cache è veramente occupata e non è possibile accedere al disco, Squid sorpassa il disco stesso prima che il numero delle richieste vada nuovamente giù. Se la lunghezza della coda raggiunge il valore Q2, allora il processo principale di Squid si pone in I/O blocking mode per piccole frazioni di tempo, sino a quando il processo di diskd riprende a fornire dei risultati. Se vogliamo che Squid si ponga in I/O blocking mode prima di iniziare la fase di rifiuto dell'apertura dei files, il valore di Q1 deve essere decisamente più grande del valore Q2. Nel nostro esempio, nel file di configurazione di Squid abbiamo impostato dei valori che possono essere considerati come ragionevoli per Q1 e Q2, tali valori saranno appunto rispettivamente come già consigliato 72 e 64

cache_dir diskd /usr/local/squid/cache 7500 16 256 Q1=72 Q2=64
    

9.6.4.2. Configurare la coda dei messaggi (message queues)

Molti sistemi operativi UNIX® hanno il supporto per la gestione della coda dei messaggi abilitato come default. Una metodo per verificare questa impostazione è controllare se si dispone del comando ipcs(1), ipcs è una facility del sistema operativo che esegue dei report sullo stato delle comunicazioni intraprocesso. È comunque necessario aumentare la grandezza della coda dei messaggi per far lavorare correttamente Squid, le implementazioni della coda dei messaggi rispondono ai seguenti parametri

  • MSGMNB - numero massimo di byte per message queue

  • MSGMNI - numero massimo di identificativi message queue (system wide)

  • MSGSEG - numero massimo di segmenti dei messaggi per la coda (queue)

  • MSGSSZ - grandezza del segmento dei messaggi

  • MSGTQL - numero massimo dei messaggi (system wide)

  • MSGMAX - grandezza massima di un whole message. In molti sistemi è necessario aumentare questo limite, in altri sistemi non è possibile modificare questo valore

i messaggi tra Squid e diskd sono di 32 bytes per le CPUs a 32-bit mentre sono di 40 bytes per le architetture che prevedono CPUs a 64-bit. Sulla base di queste informazioni, MSGSSZ deve avere un valore di 32 oppure essere più grande, è indicato settare un valore più grande per avere maggiore sicurezza. Ci sono due code per ogni cache_dir, una per ogni direzione, così il valore richiesto per MSGMNI deve essere almeno due volte il numero delle cache_dir. Sono stati rilevati in media 75 messaggi per coda ed è proprio questo il limite che consente di ottenere delle performance decenti con diskd. Se ogni messaggio diskd consiste di un segmento (questo dipende dal valore che abbiamo assegnato a MSGSSZ), allora MSGSEG dovrà essere più grande di 75. MSGMNB e MSGTQL dipendono da quanti messaggi possono essere contenuti dalla coda nello stesso momento. I messaggi diskd non devono essere più grandi di 40 bytes e si utilizzano 64 bytes per essere più sicuri. MSGMNB dovrà essere almeno 64*75, si raccomanda di impostare un numero non lontano dal doppio di questo valore oppure un valore di 8192. MSGTQL deve essere almeno 75 volte il numero dei TAG cache_dir che abbiamo configurato.

9.6.4.3. Coda dei messaggi con BSD

Il Kernel deve prevedere le seguenti impostazioni

options         SYSVMSG
    

altri parametri da impostare prima di ricompilare il Kernel vengono riportati da questo esempio, assicuriamoci di impostare i valori appropriati per il nostro sistema

options         MSGMNB=16384    # max # of bytes in a queue
options         MSGMNI=41       # number of message queue identifiers
options         MSGSEG=2049     # number of message segments per queue
options         MSGSSZ=64       # size of a message segment
options         MSGTQL=512      # max messages in system
    

9.6.4.4. Coda dei messaggi con Linux

Per configurare la coda dei messaggi con Linux è necessario editare il file /etc/sysctl.conf

    kernel.msgmnb=8192
    kernel.msgmni=40
    kernel.msgmax=8192
    

9.6.4.5. Coda dei messaggi con Solaris

Aggiungere le seguenti linee nel file /etc/system

set msgsys:msginfo_msgmax=2048
set msgsys:msginfo_msgmnb=8192
set msgsys:msginfo_msgmni=40
set msgsys:msginfo_msgssz=64
set msgsys:msginfo_msgtql=2048
    

naturalmente è necessario eseguire un riavvio del Sistema dopo aver modificato il file /etc/system

9.6.4.6. Configurare la memoria condivisa (shared memory)

La Shared Memory utilizza un insieme di parametri simili a quelli utilizzati per la gestione della coda dei messaggi (message queues). L'implementazione del diskd di Squid utilizza un'area di memoria condivisa per ogni cache_dir. Qualsiasi area di Shared Memory è almeno di 800 kilobytes per tipo, per un corretto funzionamento di Squid con diskd è quindi richiesto modificare i seguenti parametri della Shared Memory

  • SHMSEG - numero massimo di segmenti di shared memory per processo

  • SHMMNI - numero massimo di segmenti di shared memory per il segments per l'intero sistema

  • SHMMAX - segmento più grande di shared memory segment autorizzato

  • SHMALL - ammontare totale della shared memory che può essere utilizzata

per Squid e diskd, SHMMNI e SHMMNI devono essere più grandi o uguali al numero di cache_dir configurate sul sistema di webcache. SHMMAX deve essere almeno di 800 kilobytes, SHMALL deve essere almeno il valore di SHMMAX 800 kilobytes moltiplicato per il numero delle cache_dir.

9.6.4.7. Memoria condivisa con BSD

Il Kernel deve prevedere le seguenti impostazioni

options         SYSVSHM
    

altri parametri da impostare prima di ricompilare il Kernel vengono riportati da questo esempio, assicuriamoci di impostare i valori appropriati per il nostro sistema

options         SHMSEG=16       # max shared mem id's per process
options         SHMMNI=32       # max shared mem id's per system
options         SHMMAX=2097152  # max shared memory segment size (bytes)
options         SHMALL=4096     # max amount of shared memory (pages)
    

9.6.4.8. Memoria condivisa con Linux

Per configurare la memoria condivisa con Linux è necessario editare il file /etc/sysctl.conf

kernel.shmall=2097152
kernel.shmmni=32
kernel.shmmax=16777216
    

9.6.4.9. Memoria condivisa con Solaris

Aggiungere le seguenti linee nel file /etc/system

set shmsys:shminfo_shmmax=2097152
set shmsys:shminfo_shmmni=32
set shmsys:shminfo_shmseg=16
    

naturalmente è necessario eseguire un riavvio del Sistema dopo aver modificato il file /etc/system

9.6.5. null storage

Null è uno schema di Disk Storage fittizio, viene utilizzato nei casi in cui si desidera che Squid effettui il caching nella sola memoria, in questo caso non verrà salvata alcuna copia degli oggetti su disco. Viene anche utilizzato per eseguire dei test prestazionali, utilizzare uno schema di Disk Storage come null consente di aumentare le prestazioni in maniera drastica. La sintassi del TAG cache_dir per il Disk Storage null é

cache_dir null Directory-Name [options]
   

Dove Directory-Name identifica una top-level directory fittizia, ecco un esempio

cache_dir null /tmp
   

9.6.6. coss storage

Coss è l'acronimo di Cyclic Object Storage System Scheme, questo modello di Storage utilizza un singolo file per memorizzare tutti gli oggetti e quando il file raggiunge le sue dimensioni massime, Squid si occupa di ripartire dall'inizio del file stesso riscivendo tutti i dati presenti nel file. Il file potrebbe anche essere rappresentato con un raw disk device. Sfortunatamente si tratta di uno schema di storage system ancora a livello sperimentale ed il suo sviluppo procede piuttosto lentamente. Tutte le operazioni di disk I/O vengono gestite in modalità asincrona ricorrendo al modello POSIX AIO, in particolare utilizza le chiamate di sistema aio_read() e aio_write(). La gestione asincrona, come abbiamo visto, consente di evitare il blocco del processo principale di Squid durante le operazioni di disk I/O, coss è al momento disponibile per FreeBSD, Solaris e Linux e non é invece disponibile sulle piattaforme Windows. La sintassi del TAG cache_dir per il Disk Storage coss é

cache_dir coss File-Name MBytes max-size=n [options] [block-size=b]
   

dove File-Name identifica il file contenente il Disk Storage, l'opzione comune max-size deve essere sempre specificata, block-size é la dimensione del blocco di allocazione utilizzato da coss, ed infine MBytes è la dimensione massima espressa in MBytes di questo Disk Storage. Ecco alcuni esempi

cache_dir coss /usr/local/squid/var/cache/CossFile01 2048 max-size=65536 block-size=2048
cache_dir coss /usr/local/squid/var/cache/CossFile02 6744 max-side=1000000 block-size=2048
   

coss per il momento è in grado di supportare il solo algoritmo LRU a riguardo del Memory e Cache Replacement Policy

9.6.7. Scelta del Disk storage più adatto

Quale schema di Storage scegliere? il mio sistema supporta aufs? con il sistema Operativo che utilizzo aufs è più veloce di diskd o viceversa? Gli interrogativi sono molti così come sono molti i fattori che concorrono a pieno titolo alla scelta del modello di Disk Storage più adatto per il nostro Sistema, tra i vari fattori citiamo

La seguente tabella riassume alcune linee guida da seguire per effettuare tale scelta

I/O sincrono

I/O asincrono

I/O fittizio

ufs

-

-

  • singola cache

  • poche transazioni/sec

-

aufs

-

  • cache multiple

  • molte transazioni/sec

  • sistema operativo con supporto POSIX-threads

-

awin32

-

  • cache multiple

  • molte transazioni/sec

  • sistema operativo Windows

-

diskd

-

  • cache multiple

  • molte transazioni/sec

  • sistema operativo con supporto USER-threads

-

-

null

  • modalità solo proxy

  • reverse proxy



Un altro fattore che può influire significativamente sul buon funzionamento del sistema di Disk Storage é il tipo di File System fisico sul quale viene ad appoggiarsi Squid. Uno spunto molto interessante a riguardo può essere fornito da uno studio di Duane Wessels che è liberamente disponibile in internet alla URLs http://conferences.oreillynet.com/presentations/os2002/wessels_duane.ppt.

9.6.8. Esempi di configurazione

Vista la complessità e l'importanza dell'argomento trattato, in questo paragrafo ci occuperemo di mostrare al lettore alcuni esempi di configurazione di un sistema di Disk Storage efficente con Squid, tratteremo anche le eventuali ottimizzazioni che sono relative al Sistema Operativo ospitante.

9.6.8.1. Configurare diskd con FreeBSD

In questo caso di studio aumenteremo le performance della disk I/O configurando un sistema di webcache con 3*7500 MB di cache_dir (L1=16, L2=256) utilizzando il diskd come sistema di Disk Storage, questa configurazione per consentire di ottenere le performance sperate, richiede la compilazione del Kernel di FreeBSD, il file da editare che contiene tutte le direttive per compilare il Kernel è

/usr/src/sys/i386/conf/MIOKERNEL
    

dove MIOKERNEL è il file che include tutte le impostazioni del Kernel, per compilare correttamente il Kernel di FreeBSD consultare sempre il FreeBSD Handbook oppure, le istruzioni in lingua italiana contenute nel mio libro Note su FreeBSD.

Nel file di configurazione del Kernel, relativamente alla corretta configurazione della Shared Memory (SYSVSHM), devono essere contenute le seguenti linee (Squid FAQ alla URLs http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.7)

options SYSVSHM           # SYSV-style shared memory
                          # Squid Shared Memory DiskD Tuning
options SHMSEG=16         # max shared mem id's per process
options SHMMNI=32         # max shared mem id's per system
options SHMMAX=2097152    # max shared memory segment size (bytes)
options SHMALL=4096       # max amount of shared memory (pages)
    

definiamo il numero massimo di file descriptors ed il numero massimo di cluster mbuf per le connessioni di rete

options MAXFILES=8192
options NMBCLUSTERS=32768
    

utilizzando l'implementazione reale della system calls aio_* possiamo ottenere una maggiore stabilità e sicurezza del sistema da possibili attacchi che possono essere portati da utenti locali

options VFS_AIO
    

nel file di configurazione del Kernel, relativamente alla configurazione della Message Queues (SYSVMSG), devono essere contenute le seguenti linee (Cfr. Squid FAQ alla URLs http://www.squid-cache.org/Doc/FAQ/FAQ-22.html#ss22.6)

options SYSVMSG           # SYSV-style message queues
                          # Squid Message Queues DiskD Tuning
options MSGMNB=16384      # max of bytes in a queue
options MSGMNI=41         # number of message queue identifiers
options MSGSEG=2049       # number of message segments per queue
options MSGSSZ=64         # size of a message segment
options MSGTQL=512        # max messages in system
    

Dopo aver inserito queste entry nel file di configurazione del Kernel di FreeBSD, si procederà con la compilazione vera e propria del nuovo Kernel a questo punto ottimizzato per eseguire Squid

% cd /usr/src
% make buildkernel KERNCONF=MIOKERNEL
% make installkernel KERNCONF=MIOKERNEL
% reboot
    

al successivo avviamento la nostra macchina FreeBSD sarà finalmente pronta per la compilazione e l'installazione di Squid Proxy Server. Ritornando nuovamente alla configurazione di Squid, per utilizzare diskd come sistema di Disk Storage è necessario compilare Squid utilizzando le seguenti opzioni di ./configure

% ./configure --enable-storeio=diskd,ufs 
    

il port di FreeBSD prevede l'abilitazione di questo tipo di opzione come default e comunque, se si vuole selezionare alcune delle opzioni esotiche di ./configure, è necessario digitare i seguenti comandi

% cd /usr/ports/www/squid
% make config
% make 
% make install clean
    

9.6.8.2. Configurare ufs (multipiattaforma)

A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf

cache_dir ufs /usr/local/squid/var/cache 6744 16 256
    

si tratta dello schema di storage di default di Squid e può essere utilizzato per qualsiasi tipo di configurazione

9.6.8.3. Configurare aufs con Linux

A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf

cache_dir aufs /usr/local/squid/var/cache 6744 16 256
    

trattandosi dello stesso schema di storage di ufs sarà sufficente rileggere la configurazione di Squid (squid -k reconfigure)

9.6.8.4. Configurare awin32 con Windows

A riguardo la configurazione è piuttosto semplice in quanto si limita alla sola modifica del file squid.conf

cache_dir awin32 c:/squid/var/cache 6744 16 256
    

trattandosi dello stesso schema di storage di ufs sarà sufficente rileggere la configurazione di Squid (squid -k reconfigure)

Note

[1]

Interprocess Communication Resources