11.13 Messa a Punto dei Limiti del Kernel

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[1]. 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.

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