Solution 1 :
J'ai enfin trouvé le paramètre qui limitait vraiment le nombre de connexions :net.ipv4.netfilter.ip_conntrack_max . Cela a été fixé à 11 776 et tout ce que je lui ai fixé est le nombre de requêtes que je peux traiter dans mon test avant de devoir attendre tcp_fin_timeout secondes pour que d'autres connexions soient disponibles. Le conntrack La table est ce que le noyau utilise pour suivre l'état des connexions, donc une fois qu'elle est pleine, le noyau commence à déposer des paquets et à imprimer ceci dans le journal :
Jun 2 20:39:14 XXXX-XXX kernel: ip_conntrack: table full, dropping packet.
L'étape suivante consistait à faire en sorte que le noyau recycle toutes ces connexions dans le TIME_WAIT état plutôt que de laisser tomber des paquets. Je pourrais faire en sorte que cela se produise soit en activant tcp_tw_recycle ou en augmentant ip_conntrack_max être supérieur au nombre de ports locaux rendus disponibles pour les connexions par ip_local_port_range . Je suppose qu'une fois que le noyau est hors des ports locaux, il commence à recycler les connexions. Cela utilise plus de connexions de suivi de la mémoire, mais cela semble être la meilleure solution que d'activer tcp_tw_recycle puisque les docs impliquent que c'est dangereux.
Avec cette configuration, je peux exécuter ab toute la journée et ne jamais manquer de connexions :
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
Le tcp_max_orphans le réglage n'a eu aucun effet sur mes tests et je ne sais pas pourquoi. Je pense que cela fermerait les connexions en TIME_WAIT déclarez une fois qu'il y en avait 8192, mais cela ne me convient pas.
Solution 2 :
Vous voulez vraiment regarder ce que le système de fichiers /proc a à vous offrir à cet égard.
- Guide de réglage TCP du département américain de l'énergie
- Paramètres de réglage TCP pour différents systèmes d'exploitation
- "Administrer Linux à la volée" d'IBM
- Documentation sur LinuxInsight.com vis-à-vis de /proc/sys/net/ipv4
Sur cette dernière page, vous pourriez trouver les éléments suivants susceptibles de vous intéresser :
- /proc/sys/net/ipv4/tcp_max_orphans, qui contrôle le nombre maximum de sockets détenus par le système pas attaché à quelque chose. Augmenter cela peut consommer jusqu'à 64 Ko de mémoire non échangeable par socket orphelin .
- /proc/sys/net/ipv4/tcp_orphan_retries, qui contrôle le nombre de tentatives avant qu'un socket ne soit orphelin et fermé. Il y a une note spécifique sur cette page concernant les serveurs Web qui vous intéresse directement...
Solution 3 :
Je ne pense pas qu'il y ait un accordable pour régler cela directement. Cela relève de la catégorie de réglage TCP/IP. Pour savoir ce que vous pouvez accorder, essayez 'man 7 tcp'. Le sysctl ( 'man 8 sysctl' ) est utilisé pour les définir. 'sysctl-a | grep tcp 'vous montrera la plupart de ce que vous pouvez régler, mais je ne suis pas sûr qu'il les montrera tous. De plus, à moins que cela n'ait changé, les sockets TCP/IP s'ouvrent comme des descripteurs de fichiers. Donc, cette section et la suivante de ce lien pourraient être ce que vous recherchez.
Solution 4 :
Essayez de définir ce qui suit également en définissant tcp_fin_timeout. Cela devrait se terminer TIME_WAIT plus rapidement.
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
Solution 5 :
Le stock apache (1) était prédéfini pour ne prendre en charge que 250 connexions simultanées - si vous en vouliez plus, il y avait un fichier d'en-tête à modifier pour permettre plus de sessions simultanées. Je ne sais pas si c'est toujours vrai avec Apache 2.
De plus, vous devez ajouter une option pour autoriser des tas de descripteurs de fichiers plus ouverts pour le compte qui exécute Apache - quelque chose que les commentaires précédents n'ont pas souligné.
Faites attention à vos paramètres de travail et au type de délais d'expiration de keepalive que vous avez à l'intérieur d'Apache lui-même, au nombre de serveurs de rechange que vous avez en cours d'exécution en même temps et à la vitesse à laquelle ces processus supplémentaires sont tués.