sviluppo-web-qa.it

Cosa limita il numero massimo di connessioni su un server Linux?

Quali parametri del kernel o altre impostazioni controllano il numero massimo di TCP che possono essere aperti su un server Linux? Quali sono gli svantaggi di consentire più connessioni?

Durante il test di caricamento di un server Apache ho notato ab che è abbastanza semplice massimizzare le connessioni aperte sul server. Se si interrompe l'opzione -k di ab, che consente il riutilizzo della connessione e si fa in modo che invii più di circa 10.000 richieste, Apache serve le prime circa 11.000 richieste e si interrompe per 60 secondi. Uno sguardo all'output di netstat mostra 11.000 connessioni nello stato TIME_WAIT. Apparentemente, questo è normale. Le connessioni vengono mantenute aperte per un valore predefinito di 60 secondi anche dopo che il client ha terminato di utilizzarle per motivi di affidabilità TCP .

Sembra che questo sarebbe un modo semplice per fare un server e mi chiedo quali siano le solite regolazioni e precauzioni per questo.

Ecco il mio risultato del test:

# ab -c 5 -n 50000 http://localhost/
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> Apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.Apache.org/

Benchmarking localhost (be patient)
Completed 5000 requests
Completed 10000 requests
apr_poll: The timeout specified has expired (70007)
Total of 11655 requests completed

Ecco il comando netstat che eseguo durante il test:

 # netstat --inet -p | grep "localhost:www" | sed -e 's/ \+/ /g' | cut -d' ' -f 1-4,6-7 | sort | uniq -c 
  11651 tcp 0 0 localhost:www TIME_WAIT -
      1 tcp 0 1 localhost:44423 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44424 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44425 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44426 SYN_SENT 7831/ab
      1 tcp 0 1 localhost:44428 SYN_SENT 7831/ab
91
Ben Williams

Ho finalmente trovato l'impostazione che stava davvero limitando il numero di connessioni: net.ipv4.netfilter.ip_conntrack_max. È stato impostato su 11.776 e qualunque cosa io abbia impostato è il numero di richieste che posso servire nel mio test prima di dover aspettare tcp_fin_timeout secondi per rendere disponibili più connessioni. La tabella conntrack è ciò che il kernel utilizza per tenere traccia dello stato delle connessioni, quindi una volta 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 state piuttosto che far cadere i pacchetti. Potrei farlo accadere accendendo tcp_tw_recycle o crescente ip_conntrack_max deve essere maggiore del numero di porte locali rese disponibili per le connessioni da ip_local_port_range. Immagino che quando il kernel esce dalle porte locali inizia 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 eseguire ab tutto il giorno e non finire mai le 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

Il tcp_max_orphans L'impostazione non ha avuto alcun effetto sui miei test e non so perché. Penso che chiuderebbe le connessioni in TIME_WAIT dichiarare che una volta ce n'erano 8192, ma per me non è così.

66
Ben Williams

Volete davvero vedere cosa offre il filesystem/proc a questo proposito.

In quest'ultima pagina, potresti trovare le seguenti cose di tuo interesse:

  • / proc/sys/net/ipv4/tcp_max_orphans , che controlla il numero massimo di socket detenuti dal sistema not collegato a qualcosa. Aumentare questo può consumare fino a 64 kbyte di memoria non scambiabile per socket Orphan.
  • / proc/sys/net/ipv4/tcp_Orphan_retries , che controlla la quantità di tentativi prima che un socket sia orfano e chiuso. In quella pagina c'è una nota specifica sui server web che ti interessa direttamente ...
24
Avery Payne

Non penso che ci sia un parametro sintonizzabile per impostarlo direttamente. Questo rientra nella categoria di ottimizzazione TCP/IP. Per scoprire cosa puoi sintonizzare, prova 'man 7 tcp'. Il sysctl ('man 8 sysctl') è usato 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 ciò non sia cambiato, i socket TCP/IP aperti sembrano descrittori di file. Quindi this e la sezione successiva in quel link potrebbe essere quello che stai cercando.

3
Kyle Brandt

Prova a impostare anche l'impostazione tcp_fin_timeout. Questo dovrebbe chiudere TIME_WAIT più rapidamente.

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
2
Jauder Ho

Lo stock Apache (1) usato in precedenza era predefinito per supportare solo 250 connessioni simultanee - se 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 impostazioni del tuo lavoratore 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 uccisi.

2
rasjani

È possibile ridurre il tempo trascorso nello stato TIME_WAIT (impostare net.ipv4.tcp_fin_timeout). È possibile sostituire Apache con YAWS o nginx o qualcosa di simile.

Gli svantaggi di più connessioni generalmente implicano l'utilizzo della memoria e, se si dispone di un processo di fork, molti processi figlio che sommergono la CPU.

1
Devdas

Lo strumento di benchmarking del server HTTP Apache, ab , nella versione 2.4 ha l'opzione - s timeout . Vedi anche ab (Apache Bench) errore: apr_poll: il timeout specificato è scaduto (70007) su Windows.

Questa opzione risolve il problema.

0
Dzwiedziu-nkg

Il numero assoluto di socket che possono essere aperti su un singolo indirizzo IP è 2 ^ 16 ed è definito da TCP/UDP, non dal kernel.

0
Jason Tan