Vraag Wat beperkt het maximale aantal verbindingen op een Linux-server?


Welke kernelparameters of andere instellingen regelen het maximale aantal TCP-sockets dat open kan zijn op een Linux-server? Wat zijn de afwegingen om meer verbindingen toe te staan?

Ik zag tijdens het testen van de belasting een Apache-server met ab dat het vrij eenvoudig is om de open verbindingen op de server maximaal te benutten. Als je ab's -k-optie laat staan, waardoor hergebruik van verbindingen mogelijk is, en het meer dan ongeveer 10.000 verzoeken stuurt, dan dient Apache de eerste 11.000 verzoeken en stopt dan gedurende 60 seconden. Een blik op de netstat-uitvoer toont 11.000 verbindingen in de TIME_WAIT-status. Blijkbaar is dit normaal. Verbindingen worden standaard 60 seconden open gehouden, zelfs nadat de client klaar is met ze TCP-betrouwbaarheidsredenen.

Het lijkt erop dat dit een gemakkelijke manier is om een ​​server te doen en ik vraag me af wat de gebruikelijke afstemmingen en voorzorgsmaatregelen zijn.

Dit is mijn testoutput:

# 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

Dit is de netstat-opdracht die ik tijdens de test uitvoer:

 # 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

85
2018-05-21 16:18


oorsprong




antwoorden:


Ik heb eindelijk de instelling gevonden die het aantal verbindingen echt beperkte: net.ipv4.netfilter.ip_conntrack_max. Dit was ingesteld op 11.776 en wat ik ook heb ingesteld is het aantal verzoeken dat ik in mijn test kan indienen voordat ik moet wachten tcp_fin_timeout seconden voordat er meer verbindingen beschikbaar komen. De conntrack tabel is wat de kernel gebruikt om de status van verbindingen te volgen, dus zodra deze vol is, begint de kernel pakketten te laten vallen en deze in het logboek af te drukken:

Jun  2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.

De volgende stap was om de kernel al die verbindingen in de kernel te laten recyclen TIME_WAIT staat in plaats van pakketten te laten vallen. Ik zou dat kunnen laten gebeuren door aan te zetten tcp_tw_recycle of toenemen ip_conntrack_max groter zijn dan het aantal lokale poorten dat beschikbaar is voor verbindingen via ip_local_port_range. Ik vermoed dat als de kernel eenmaal uit de lokale poorten is, het verbindingen begint te recyclen. Dit gebruikt meer geheugenspoorverbindingen, maar het lijkt de betere oplossing dan aan te zetten tcp_tw_recycle omdat de documenten impliceren dat dat gevaarlijk is.

Met deze configuratie kan ik de hele dag een ab uitvoeren en nooit zonder verbindingen:

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

De tcp_max_orphans instelling had geen effect op mijn tests en ik weet niet waarom. Ik zou denken dat het de verbindingen zou sluiten TIME_WAIT staat dat er 8192 waren, maar dat doet het niet voor mij.


62
2018-06-03 16:02



Waar configureren we deze params? - Codevalley
@Codevalley Dat kan systeemafhankelijk zijn maar op Ubuntu Server gaan ze in /etc/sysctl.conf - Ben Williams


Je wilt echt kijken naar wat het / proc-bestandssysteem je in dit opzicht te bieden heeft.

Op die laatste pagina vindt u mogelijk het volgende interessant voor u:

  • / Proc / sys / net / ipv4 / tcp_max_orphans, dat het maximale aantal sockets controleert dat door het systeem wordt vastgehouden niet aan iets gehecht. Het verhogen hiervan kan maar liefst 64 kbyte aan niet-verwisselbaar geheugen verbruiken per weesdoos.
  • / Proc / sys / net / ipv4 / tcp_orphan_retries, die de hoeveelheid pogingen regelt voordat een socket verweesd en gesloten is. Er staat een specifieke opmerking op die pagina over webservers die voor u van direct belang zijn ...

23
2018-05-21 18:15



tcp_max_orphans is interessant, maar het lijkt erop dat het niet werkt. Als ik tijdens mijn test weesmonden probeer te meten, zie ik 11.651 terwijl tcp_max_orfans 8.092 is. # netstat --inet -p | grep "localhost: www" | sed -e's / \ + / / g '| cut -d '' -f 1-4,6-7 | sorteren | uniq -c 11651 tcp 0 0 localhost: www TIME_WAIT - - Ben Williams
Kijk naar de instelling tcp_orphan_retries - het idee is dat de sockets sneller worden "geruimd" ... - Avery Payne
De suggestie van @Jauder Ho + tcp_orphan_retries klinken als potentiële winst voor uw situatie. - Avery Payne


Ik denk niet dat er een afstembaar is om dat direct in te stellen. Dit valt onder de categorie TCP / IP-afstemming. Om uit te vinden wat je kunt afstemmen, probeer 'man 7 tcp'. De sysctl ('man 8 sysctl') wordt gebruikt om deze in te stellen. 'sysctl -a | grep tcp 'laat je het meeste zien van wat je kunt afstemmen, maar ik weet niet zeker of het allemaal zal worden weergegeven. Ook, tenzij dit is veranderd, lijken TCP / IP-sockets open als bestandsdescriptors. Zo deze en het volgende gedeelte in die link kan zijn wat u zoekt.


3
2018-05-21 17:31





Probeer ook het volgende in te stellen en stel tcp_fin_timeout in. Dit zou TIME_WAIT sneller moeten sluiten.

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

2
2018-05-21 19:38



Voorzichtig hier! Ervaren op de harde manier. "Dit kan leiden tot verloren frames met load-balancing en NAT's, dit alleen gebruiken voor een server die alleen communiceert via uw lokale netwerk." - wiki.archlinux.org/index.php/Sysctl - Henk
@Henk Ik denk dat het dat is tcp_tw_recycle dat is potentieel gevaarlijk. tcp_tw_reuse is veiliger en ik zie geen reden om ze tegelijkertijd te gebruiken. - Vladislav Rastrusny


De voorraadapache (1) kwam vroeger voorgedefinieerd om slechts 250 gelijktijdige verbindingen te ondersteunen - als u meer wilde, was er één headerbestand dat moest worden gewijzigd om meer gelijktijdige sessies toe te staan. Ik weet niet of dit nog steeds waar is met Apache 2.

Je moet ook een optie toevoegen om veel meer open bestandsbeschrijvingen toe te staan ​​voor het account dat Apache uitvoert - iets dat de vorige opmerkingen niet aangeven.

Let op de instellingen van je werknemers en wat voor soort keepalive time-outs je hebt in Apache zelf, hoeveel reserve-servers je tegelijkertijd hebt, en hoe snel deze extra processen worden gedood.


2
2018-05-21 21:21





U kunt de tijd in de TIME_WAIT-status verkorten (Set net.ipv4.tcp_fin_timeout). Je zou Apache kunnen vervangen door YAWS of nginx of iets dergelijks.

Inruil van meer verbindingen heeft meestal betrekking op geheugengebruik en als je een vals proces hebt, zijn er veel onderliggende processen die je CPU overspoelen.


1
2018-05-21 16:26



tcp_fin_timeout is niet bedoeld voor het instellen van de TIME-WAIT-expiratie, die niet kan worden gewijzigd buiten het opnieuw opbouwen van de kernel, maar voor FIN, zoals de naam aangeeft. - Alexandr Kurilin


Het absolute aantal sockets dat open kan zijn op een enkel IP-adres is 2 ^ 16 en wordt gedefinieerd door TCP / UDP, niet door de kernel.


0
2018-05-30 16:42



Nee dat is het niet. U kunt meer openen omdat de lokale poort niet uniek hoeft te zijn zolang de externe adressen verschillend zijn. Bovendien zei het OP per server, en je kunt> 1 adres per server hebben. - MarkR