kern.maxfiles
può essere aumentato o
abbassato a seconda dei requisiti del tuo sistema. Questa variabile
indica il numero massimo di descrittori di file sul tuo sistema.
Quando la tabella dei descrittori di file è piena,
apparirà ripetutamente la scritta file: table is
full nel buffer dei messaggi di sistema, che può
essere visualizzato con il comando dmesg
.
Ogni file, socket, o fifo aperta usa un descrittore di file. Un server di produzione di larga scala può richiedere facilmente molte migliaia di descrittori di file, in relazione al tipo e al numero di servizi in esecuzione insieme.
Nelle vecchie release di FreeBSD, il valore predefinito
di kern.maxfile
viene
dettato dall'opzione maxusers
nel file di
configurazione del kernel. kern.maxfiles
cresce
proporzionalmente al valore di maxusers
. Quando si
compila un kernel personalizzato, è una buona idea impostare
questa opzione di configurazione del kernel in base agli usi del
proprio sistema. Da questo numero, dipendono molti dei limiti
predefiniti del kernel. Anche se una macchina in produzione potrebbe
non avere effettivamente 256 utenti connessi contemporaneamente, le
risorse necessarie potrebbero essere simili a quelle di un server web
su larga scala.
A partire da FreeBSD 4.5, kern.maxusers
è automaticamente dimensionato sulla base della memoria
disponibile nel sistema, e può essere determinato a run-time
leggendo il valore del sysctl read-only kern.maxusers
.
Alcuni siti richiedono valori minori o maggiori di kern.maxusers
e questo può essere impostato come un parametro modificabile
dal loader; valori di 64, 128 o 256 non sono fuori dal comune.
Non raccomandiamo di andare oltre i 256 a meno che non si necessiti
di un numero esagerato di file descriptor; molti dei valori modificati
nel loro default da kern.maxusers
possono essere
singolarmente sovrascritti a boot-time o a run-time in
/boot/loader.conf
(leggi la pagina di manuale
loader.conf(5) o il file /boot/defaults/loader.conf
per alcuni suggerimenti) o come descritto altrove in questo documento.
Sistemi precedenti a FreeBSD 4.4 devono invece impostare questo valore
attraverso l'opzione di config(8) maxusers
.
Nelle release precedenti, il sistema setterà
in modo automatico maxusers
se lo imposti a
0
[5].
Quando usi quest'opzione, impostalo
almeno a 4, specialmente se stai usando il sistema a finestre X o se
compili software. Questo è dovuto al fatto che la tabella
più importante settata da maxusers
è
quella relativa al numero massimo di processi, risultato di
20 + 16 * maxusers
, e quindi se setti
maxusers
a 1, puoi avere solo 36 processi in modo
simultaneo, inclusi i 18 o più di avvio del sistema e i 15
o più che verranno creati all'avvio del sistema a finestre X.
Perfino una semplice attività come la lettura di una pagina
man avvia fino a 9 processi per filtrare, decomprimere, e visualizzare
la pagina. Settando maxusers
a 64 avrai fino a
1044 processi simultanei, che dovrebbero essere sufficienti per quasi
tutti gli utenti. Ad ogni modo, se vedi il temuto errore
proc table full quando tenti di avviare
un programma, o se stai usando un server con molti utenti simultanei
(come ftp.FreeBSD.org
), puoi sempre
incrementare il numero e ricompilare.
maxusers
non
limita il numero degli utenti che possono loggarsi sulla tua
macchina. Semplicemente setta la dimensione di alcune tabelle
a un valore ragionevole considerando il numero massimo di
utenti che probabilmente avrai sul tuo sistema e quanti
processi ognuno di loro avranno in esecuzione. Un'opzione
che limita il numero di login remoti simultanei e di terminali
windows è pseudo-device pty
16
. Con FreeBSD 5.X, non ti devi
preoccupare di questo numero poichè il driver
pty(4) è «auto-cloning»; semplicemente
usa la linea device pty
nel tuo file di
configurazione.
La variabile sysctl kern.ipc.somaxconn
limita la dimensione della coda in ascolto per le connessioni TCP.
Il valore predefinito è di 128
,
generalmente troppo basso per una gestione robusta di nuove
connessioni in ambienti come i web server molto carichi. Per tali
ambienti, è consigliato aumentare questo valore a
1024
o maggiore. Il demone di servizio può
a sua volta limitare la dimensione della coda (e.g. sendmail(8),
o Apache) ma spesso avrà una
direttiva nel proprio file di configurazione per correggere la
dimensione della coda. Grosse code di ascolto aiutano anche ad
evitare attacchi di tipo Denial of Service
(DoS).
L'opzione di configurazione del kernel NMBCLUSTERS
decide la quantità di Mbuf di rete disponibili al sistema.
Un server molto trafficato con un numero basso di Mbuf
ostacolerebbe le possibilità di FreeBSD. Ogni cluster
rappresenta approssimativamente 2 K di memoria, dunque un valore di
1024 rappresenta 2 megabyte di memoria del kernel riservata per i
buffer di rete.
Può essere effettuato un semplice calcolo per capire
quanti ne siano necessari. Se hai un web server che arriva al massimo
a 1000 connessioni simultanee, ed ogni connessione consuma un buffer di
16 K in ricezione e un altro di 16 K in trasmissione, avrai
bisogno approssimativamente di 32 MB di buffer di rete per coprire
il web server.
Una buona regola generale è di moltiplicare per 2, dunque
2x32 MB / 2 KB =
64 MB / 2 KB = 32768.
Consigliamo valori compresi tra
4096 e 32768 per macchine con grandi quantità di memoria.
In nessun caso dovreste specificare un valore alto arbitrario
per questo parametro, poichè potrebbe portare ad un crash
all'avvio. L'opzione -m
di
netstat(1) può essere usata per osservare l'uso della
rete.
L'opzione del loader
kern.ipc.nmbclusters
può essere usata per
impostare questi valori all'avvio. Solo versioni vecchie di FreeBSD
richiedono l'uso dell'opzione NMBCLUSTERS
come
configurazione del kernel (config(8)).
Per server sotto carico che fanno un uso massiccio della chiamata
di sistema sendfile(2), potrebbe essere necessario
aumentare il numero di buffer sendfile(2) tramite l'opzione di
configurazione del kernel NSFBUFS
o impostando il suo
valore in /boot/loader.conf
(vedere loader(8) per maggiori dettagli). Un indicatore comune
che questo parametro deve essere corretto è la comparsa di
processi nello stato sfbufa. La variabile sysctl
kern.ipc.nsfbufs
è solo un riferimento
read-only alla variabile configurata nel kernel. Questo parametro
aumenta nominalmente con kern.maxusers
,
in ogni caso potrebbe essere necessario effettuare piccole correzioni
per farli concordare.
Anche se un socket è stato segnalato come non-bloccante,
richiamando sendfile(2) su di esso si potrebbe avere un blocco
della chiamata sendfile(2) fino a quando non sono disponibili
delle struct sf_buf
.
La variabili sysctl net.inet.ip.portrange.*
controllano i numeri di porta automaticamente assegnate a socket TCP
ed UDP. Ci sono tre intervalli: uno basso, uno predefinito,
ed uno alto. La maggior parte dei programmi usa l'intervallo
predefinito che è controllato da
net.inet.ip.portrange.first
e
net.inet.ip.portrange.last
, che hanno valori
predefiniti di 1024 e 5000. Questi intervalli sono usati per le
connessioni in uscita, ed è possibile che il sistema esaurisca
le porte in alcune circostanze. Ciò accade per lo più
quando avete un web proxy molto carico. L'intervallo di porte
non è un problema quando si usano server che abbiano
per lo più connessioni in ingresso, come i normali
web server, o un numero limitato di connessioni in
uscita, come i relay di posta. Per situazioni
nelle quali potreste terminare le porte, è consigliato
aumentare leggermente net.inet.ip.portrange.last
.
Un valore di 10000
, 20000
o
30000
può essere ragionevole.
Dovreste anche considerare gli effetti relativi ad un firewall
nel cambiare il range di porte. Alcuni
firewall potrebbero bloccare grandi intervalli di porte (tipicamente
le porte basse) ed aspettarsi che i sistemi usino porte più
alte per le connessioni in uscita - per questa ragione si
consiglia di non abbassare il valore di
net.inet.ip.portrange.first
.
Il limite del Prodotto del Ritardo di Banda TCP è simile a
TCP/Vegas in NetBSD. Può
essere abilitato impostando la variabile sysctl
net.inet.tcp.inflight_enable
ad 1
. Il sistema tenterà di
calcolare il prodotto del ritardo di banda per ogni connessione
e limiterà l'ammontare di dati accodati per la trasmissione su
rete al livello migliore per garantire il massimo throughput.
Questa funzionalità è utile quando si inviano dati
su modem multipli, su Ethernet Gigabit, o su collegamenti WAN ad alta
velocità (o qualsiasi altro collegamento con un alto prodotto
a banda di ritardo), in particolar modo se state usando anche il
window scaling o se avete configurato una finestra TCP molto ampia.
Se abilitate questa opzione, dovreste anche assicurarvi di impostare
a 0
net.inet.tcp.inflight_debug
(per disabilitare il debugging), e per un uso di produzione
può essere utile impostare
net.inet.tcp.inflight_min
ad almeno
6144
. Notate comunque che
impostando dei livelli minimi alti può in pratica disabilitare
la limitazione di banda, su alcuni tipi di collegamento.
La funzionalità di limitazione della banda riduce la
quantità di dati creati in rotte intermedie
e fa circolare le code di pacchetti così come riduce la
quantità di dati creati nella coda di interfaccia dell'host
locale. Con meno pacchetti accodati, le connessioni interattive,
specialmente sopra modem lenti, opereranno con lenti
Round Trip Times (tempi di andata e ritorno).
Comunque, nota che questa feature ha effetto solo sulla trasmissione
dati (uploading / lato server). Non ha effetto sulla ricezione
(downloading).
Modificare net.inet.tcp.inflight.stab
non
è raccomandato.
Questo parametro è di default a 20, rappresentando
2 pacchetti massimi aggiunti al ritardo del prodotto della banda
della finestra. La finestra addizionale è richiesta per
stabilizzare l'algoritmo e migliorare la risposta alle condizioni che
cambiano ma può risultare in tempi lunghi sui ping
sopra link lenti (anche se molto più lento di quello che
otterresti senza l'algoritmo di inflight). In questi casi, puoi voler
ridurre questo parametro a 15, 10 o 5; e puoi anche ridurre
net.inet.tcp.inflight.min
(per esempio, a 3500)
per ottenere l'effetto desiderato. Ridurre questi parametri
dovrebbe essere fatto solo come ultima spiaggia.
Un vnode è la rappresentazione di un file o una directory. Aumentare il numero di vnodi disponibili sul sistema operativo aumenterà l'I/O di disco. Normalmente questo viene gestito dal sistema operativo e non deve essere cambiato. In pochi casi dove l'I/O di disco è un collo di bottiglia ed il sistema sta finendo i suoi vnodi, questo parametro sarà aumentato. L'aumento di RAM libera ed inattiva sarà tenuto in conto.
Per vedere il numero corrente di vnodi in uso:
#
sysctl vfs.numvnodes
vfs.numvnodes: 91349
Per vedere il numero massimo di vnodi:
#
sysctl kern.maxvnodes
kern.maxvnodes: 100000
Se l'uso del nodo corrente è vicino alla fine,
aumentare kern.maxvnodes
di un valore di 1.000
è probabilmente una buona idea. Tenete un occhio sul numero
di vfs.numvnodes
. Se scala al massimo,
kern.maxvnodes
dovrà essere incrementato
ancora. Dovrebbe essere visibile con top(1)
uno spostamento nell'uso della memoria. Molta memoria dovrebbe essere
attiva.
[5] L'algoritmo di impostazione automatica setta
maxusers
pari alla quantità della
memoria del sistema, con un minimo di 32, fino a un massimo
di 384.
Questo, ed altri documenti, possono essere scaricati da ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Per domande su FreeBSD, leggi la
documentazione prima di contattare
<questions@FreeBSD.org>.
Per domande su questa documentazione, invia una e-mail a
<doc@FreeBSD.org>.