Soluzione 1:
Finalmente ho trovato l'impostazione che limitava davvero il numero di connessioni:net.ipv4.netfilter.ip_conntrack_max . Questo è stato impostato su 11.776 e qualunque cosa io abbia impostato è il numero di richieste che posso servire nel mio test prima di dover attendere tcp_fin_timeout secondi per rendere disponibili più connessioni. Il conntrack table è ciò che il kernel utilizza per tenere traccia dello stato delle connessioni, quindi una volta che è pieno, il kernel inizia a eliminare i pacchetti e a stamparlo nel registro:
Jun 2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.
Il passo successivo è stato far sì che il kernel riciclasse tutte quelle connessioni nel TIME_WAIT stato piuttosto che eliminare i pacchetti. Potrei farlo accadere attivando tcp_tw_recycle o aumentando ip_conntrack_max essere maggiore del numero di porte locali rese disponibili per le connessioni da ip_local_port_range . Immagino che una volta che il kernel è uscito dalle porte locali, inizi a riciclare le connessioni. Questo utilizza più connessioni di tracciamento della memoria, ma sembra la soluzione migliore rispetto all'attivazione di tcp_tw_recycle poiché i documenti implicano che ciò è pericoloso.
Con questa configurazione posso lavorare tutto il giorno senza mai rimanere senza connessioni:
net.ipv4.netfilter.ip_conntrack_max = 32768
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_orphan_retries = 1
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_max_orphans = 8192
net.ipv4.ip_local_port_range = 32768 61000
L'tcp_max_orphans impostazione non ha avuto alcun effetto sui miei test e non so perché. Penso che chiuderebbe le connessioni in TIME_WAIT afferma che una volta ce n'erano 8192, ma non lo fa per me.
Soluzione 2:
Vuoi davvero vedere cosa ha da offrirti il filesystem /proc a questo proposito.
- TCP Tuning Guide presso il Dipartimento dell'Energia degli Stati Uniti
- Parametri di ottimizzazione TCP per diversi OS:es
- "Amministra Linux al volo" di IBM
- Documentazione su LinuxInsight.com vis-a-vis /proc/sys/net/ipv4
In quest'ultima pagina, potresti trovare interessante quanto segue:
- /proc/sys/net/ipv4/tcp_max_orphans, che controlla il numero massimo di socket detenuti dal sistema non attaccato a qualcosa. L'aumento di questo può consumare fino a 64 kbyte di memoria non scambiabile per socket orfano .
- /proc/sys/net/ipv4/tcp_orphan_retries, che controlla la quantità di tentativi prima che un socket venga reso orfano e chiuso. In quella pagina c'è una nota specifica sui server web che ti interessa direttamente...
Soluzione 3:
Non credo che ci sia un sintonizzabile per impostarlo direttamente. Questo rientra nella categoria dell'ottimizzazione TCP/IP. Per scoprire cosa puoi regolare, prova 'man 7 tcp'. Il sysctl ( 'man 8 sysctl' ) viene utilizzato per impostarli. 'sysctl -a | grep tcp' ti mostrerà la maggior parte di ciò che puoi sintonizzare, ma non sono sicuro che li mostrerà tutti. Inoltre, a meno che questo non sia cambiato, i socket TCP/IP aperti sembrano descrittori di file. Quindi questa e la prossima sezione in quel link potrebbero essere ciò che stai cercando.
Soluzione 4:
Prova a impostare anche quanto segue impostando tcp_fin_timeout. Questo dovrebbe chiudere TIME_WAIT più rapidamente.
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Soluzione 5:
Lo stock apache (1) veniva predefinito per supportare solo 250 connessioni simultanee:se ne volevi di più, c'era un file di intestazione da modificare per consentire più sessioni simultanee. Non so se questo è ancora vero con Apache 2.
Inoltre, è necessario aggiungere un'opzione per consentire un sacco di descrittori di file più aperti per l'account che esegue Apache, cosa che i commenti precedenti non hanno sottolineato.
Presta attenzione alle tue impostazioni di lavoro e al tipo di timeout keepalive che hai all'interno di Apache stesso, quanti server di riserva hai in esecuzione contemporaneamente e quanto velocemente questi processi extra vengono interrotti.