11.13. Messa a Punto dei Limiti del Kernel

11.13.1. Limiti dei File/Processi

11.13.1.1. kern.maxfiles

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.

Nota:

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.

11.13.1.2. kern.ipc.somaxconn

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).

11.13.2. Limiti di Rete

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.

Importante:

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.

11.13.2.1. net.inet.ip.portrange.*

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.

11.13.2.2. Prodotto del Ritardo di Banda TCP

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.

11.13.3. Memoria Virtuale

11.13.3.1. kern.maxvnodes

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>.