En augmentant le nombre maximum de connexions tcp/ip sous linux

Nombre Maximum de connexions sont touchés par certaines limites sur les deux client & serveur côtés, mais un peu différemment.

Sur le côté client:
Augmentation de la ephermal plage de ports, et de diminuer la tcp_fin_timeout

Pour trouver les valeurs par défaut:

sysctl net.ipv4.ip_local_port_range
sysctl net.ipv4.tcp_fin_timeout

La ephermal plage de port définit le nombre maximal de sortants sockets un hôte peut créer à partir d'une I. P. de l'adresse. Le fin_timeout définit le temps minimum ces prises resteront dans TIME_WAIT état (inutilisable après avoir utilisé une fois).
D'habitude les valeurs par défaut sont:

• net.ipv4.ip_local_port_range = 32768 61000
• net.ipv4.tcp_fin_timeout = 60

Cela signifie essentiellement que votre système ne peut pas systématiquement garantie de plus de (61000 - 32768) /60 = 470 sockets par seconde. Si vous n'êtes pas heureux avec cela, vous pouvez commencer avec l'augmentation de la port_range. Le réglage de la portée de 15000 61000 est assez fréquent de nos jours. Vous pourraient encore augmenter la disponibilité par la diminution de la fin_timeout. Supposons que vous faites les deux, vous devriez voir plus de 1500 connexions sortantes par seconde, plus facilement.

Pour modifier les valeurs:

sysctl net.ipv4.ip_local_port_range="15000 61000"
sysctl net.ipv4.tcp_fin_timeout=30

Le ci-dessus ne doivent pas être interprétés comme des facteurs influant sur la capacité de système pour faire les connexions sortantes par seconde. Mais plutôt ces facteurs influent sur la capacité du système à gérer connexions simultanées d'une manière durable pour les grandes périodes de "activité".

Par défaut Sysctl valeurs typiquement sur une Linux box pour tcp_tw_recycle & tcp_tw_reuse serait

net.ipv4.tcp_tw_recycle=0
net.ipv4.tcp_tw_reuse=0

Elles ne permettent pas une connexion à partir d'un "utilisé" socket (en attente) et la force de la sockets pour tenir toute la time_wait cycle. Je vous recommande de créer:

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

Cela permet rapidement de cyclisme de sockets dans time_wait de l'état et de réutilisation. Mais avant de faire ce changement, assurez-vous que ce n'est pas en conflit avec les protocoles que vous utilisez pour l'application qui a besoin de ces supports. Assurez-vous de lire le post "Face à la TCP TEMPS d'ATTENTE" de Vincent Bernat de comprendre les implications. Le net.ipv4.tcp_tw_recycle option est tout à fait problématique pour le public face serveurs comme elle ne gère pas les connexions à partir de deux ordinateurs différents, derrière le même périphérique NAT, qui est un problème difficile à détecter et à l'attente de vous mordre. Notez que net.ipv4.tcp_tw_recycle a été supprimé de Linux 4.12.

Sur le Côté Serveur:
Le net.core.somaxconn valeur a un rôle important. Il limite le nombre maximum de demandes en attente pour un socket d'écoute. Si vous êtes sûr de votre serveur de l'application de la capacité, de l'augmenter jusqu'par défaut de 128 à quelque chose comme de 128 à 1024. Maintenant, vous pouvez profiter de cette augmentation par la modification de l'écoute de l'arriéré de la variable dans votre application écouter appel, à un égal ou supérieur entier.

sysctl net.core.somaxconn=1024

txqueuelen paramètre de votre carte ethernet ont également un rôle à jouer. Les valeurs par défaut sont de 1000, afin de remonter jusqu'à 5000 ou même plus si votre système le permet.

ifconfig eth0 txqueuelen 5000
echo "/sbin/ifconfig eth0 txqueuelen 5000" >> /etc/rc.local

De même remonter les valeurs pour net.core.netdev_max_backlog et net.ipv4.tcp_max_syn_backlog. Leurs valeurs par défaut sont 1000 et 1 024 respectivement.

sysctl net.core.netdev_max_backlog=2000
sysctl net.ipv4.tcp_max_syn_backlog=2048

Maintenant, n'oubliez pas de commencer à la fois de votre côté client et serveur d'applications par l'augmentation de la FD ulimts, dans la coquille.

Outre l'un des plus populaires de la technique utilisée par les programmeurs est de réduire le nombre de tcp écrire appels. Ma préférence est d'utiliser un tampon dans lequel j'ai pousser les données que j'ai à envoyer au client, puis à des moments appropriés, j'écris sur les données mises en mémoire tampon dans le socket. Cette technique me permet d'utiliser de grands paquets de données, la réduction de la fragmentation réduit mon utilisation de l'UC à la fois dans l'espace utilisateur et au niveau du noyau.

Pour améliorer la réponse donnée par derobert,

Vous pouvez déterminer ce que votre OS limite de connexion est par cat nf_conntrack_max.

Par exemple:
cat /proc/sys/net/netfilter/nf_conntrack_max

Vous pouvez utiliser le script suivant pour compter le nombre de connexions tcp à une plage de ports tcp. Par défaut 1 et 65535.

Cela permettra de confirmer si oui ou non vous êtes plafonnait votre système d'exploitation limite de connexion.

Voici le script.

#!/bin/bash
OS=$(uname)

case "$OS" in
    'SunOS')
            AWK=/usr/bin/nawk
            ;;
    'Linux')
            AWK=/bin/awk
            ;;
    'AIX')
            AWK=/usr/bin/awk
            ;;
esac

netstat -an | $AWK -v start=1 -v end=65535 ' $NF ~ /TIME_WAIT|ESTABLISHED/&& $4 !~ /127\.0\.0\.1/{
    if ($1 ~ /\./)
            {sip=$1}
    else {sip=$4}

    if ( sip ~ /:/)
            {d=2}
    else {d=5}

    split( sip, a, /:|\./)

    if ( a[d] >= start && a[d] <= end ) {
            ++connections;
            }
    }
    END {print connections}'