Nombre Max de prise sur Linux
Il semble que le serveur est limité à ~32720 les sockets...
J'ai essayé par tous les changement de variable pour faire lever cette limite.
Mais le serveur de séjour limité à 32720 ouvert socket, même si il y a encore 4Go de mémoire libre et 80% d'inactivité du processeur...
Voici la configuration
~# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63931
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 798621
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 2048
cpu time (seconds, -t) unlimited
max user processes (-u) 63931
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
net.netfilter.nf_conntrack_max = 999999
net.ipv4.netfilter.ip_conntrack_max = 999999
net.nf_conntrack_max = 999999
Toutes les pensées ?
De même il est dit: Si vous avez besoin de plus de 32000 sockets à la fois, vous avez de plus gros problèmes que juste ce nombre étant trop faible. Un serveur normal de ne pas jamais plus de quelques centaines de prises de courant (peut-être même un couple de mille, pour un serveur occupé) ouvert à la fois.
quelques centaines de sockets ? d'où as-tu trouvé ce numéro ?
avez-vous du cadre de sécurité chargé, qui limite le nombre de fd et/ou de connexions?
L'expérience. Même très occupé sites web servent rarement plus de quelques milliers de clients simultanés -- une fois qu'ils arrivent à ce point, ils sont en cluster ou autrement distribué à réduire la charge. Et le réseau IRC QuakeNet, le meilleur exemple que je pouvais penser de masse à long terme de client/serveur TCP choses, a peut-être 80k utilisateurs simultanés, réparties sur plus de 40 serveurs. C'est à propos de 2k par.
La limite est probablement pas due à des trucs de sécurité -- sécurité des coup de pied dans le CHEMIN avant de 32k sockets.
quelques centaines de sockets ? d'où as-tu trouvé ce numéro ?
avez-vous du cadre de sécurité chargé, qui limite le nombre de fd et/ou de connexions?
L'expérience. Même très occupé sites web servent rarement plus de quelques milliers de clients simultanés -- une fois qu'ils arrivent à ce point, ils sont en cluster ou autrement distribué à réduire la charge. Et le réseau IRC QuakeNet, le meilleur exemple que je pouvais penser de masse à long terme de client/serveur TCP choses, a peut-être 80k utilisateurs simultanés, réparties sur plus de 40 serveurs. C'est à propos de 2k par.
La limite est probablement pas due à des trucs de sécurité -- sécurité des coup de pied dans le CHEMIN avant de 32k sockets.
OriginalL'auteur TheSquad | 2010-08-07
Vous devez vous connecter pour publier un commentaire.
Si vous faites affaire avec openssl et fils, allez vérifier votre /proc/sys/vm/max_map_count et essayer de le soulever.
OriginalL'auteur fedj
Serveur qui parlez-vous ? Il pourrait être qu'il a un max codé en dur, ou s'exécute dans les autres limites (max threads/hors de l'espace d'adressage, etc.)
http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-1 a quelques réglages nécessaires pour atteindre un beaucoup de connexion, mais il n'aide pas si le serveur d'application des limites d'une certaine façon ou d'une autre.
Désolé avez obtenu ce que vous demandez au premier abord... Le serveur d'application est un logiciel que nous avons fait sans limitation
Un serveur personnalisé application ne permet pas d'obtenir 32k simultanée clients, sauf si elle est faite par un notable de la société ou fait quelque chose de louche. Dans le premier cas, vous n'auriez pas besoin de l'aide, quelqu'un qui n'a pas compris à des questions d'échelle n'aurait pas été embauchée.
Puis appeler des conneries, je n'ai pas à me justifier pour avoir une réponse de vous... Ce problème est connu pour être difficile, et je ne suis même pas sûr que quelqu'un comme une bonne réponse à cette question (Combien de socket un serveur peut gérer au max...). Le fait est que nous avons beaucoup plus de 32K de connexion de passe, seulement chaque serveurs sont limités à 32 ko. Maintenant, avec tous les serveurs en cluster, nous n'avons plus de 1 millions de connexion. Nous sommes à la recherche de solutions pour diminuer le nombre de serveurs. Ça y est !
Euh, ouais, vous avoir à te justifier pour obtenir une réponse de moi. AFIN de ne pas me payer, je suis ici parce que j'aime la résolution de problèmes. Cependant, je ne suis pas en aidant les gens à résoudre le mauvais problème -- et jusqu'à présent, le problème semble plus être cette prétendue obligation pour 32k+ simultanée longue durée de vie des connexions sur une zone, plutôt que d'un noyau et/ou de l'exécution de la limite que presque n'importe qui, mais le stress testeurs sais même existe. Donc, sauf si je vois que c'est nécessaire, je vais continuer à dire "utiliser moins de prises".
OriginalL'auteur nos
En IPV4, la couche TCP dispose de 16 bits pour le port de destination, et de 16 bits pour le port source.
voir http://en.wikipedia.org/wiki/Transmission_Control_Protocol
De voir que votre limite est de 32 ko je m'attends à ce que vous êtes en train de voir, à la limite de les connexions TCP sortantes que vous pouvez faire. Vous devriez être en mesure d'obtenir un max de 65K sockets (ce serait le protocole de limite). C'est la limite du nombre total de nommée connexions. Heureusement, la liaison d'un port pour les connexions entrantes utilise seulement 1. Mais si vous essayez de tester le nombre de connexions à partir de la même machine, vous ne pouvez avoir 65K total de connexions sortantes (pour TCP). Pour tester la quantité de connexions entrantes, vous aurez besoin de plusieurs ordinateurs.
Remarque: vous pouvez appeler socket(AF_INET,...) le nombre de descripteurs de fichiers disponibles, mais
vous ne pouvez pas lier sans augmenter le nombre de ports disponibles. Pour augmenter la plage, faire ceci:
echo "1024 à 65535" > /proc/sys/net/ipv4/ip_local_port_range
(chat, de voir ce que vous avez actuellement--la valeur par défaut est de 32768 à 61000)
Il est peut être temps pour une nouvelle connexion TCP comme protocole qui va permettre de 32 bits pour la source et la destination des ports? Mais combien d'applications vraiment besoin de plus de 65 mille connexions sortantes?
Le suivant va permettre à 100 000 connexions entrantes sur linux mint 16 (64 bits)
(vous devez l'exécuter en tant que root pour définir les limites)
OriginalL'auteur Kevin Johnson
Si vous envisagez une application où vous croyez que vous avez besoin pour ouvrir des milliers de douilles, vous aurez certainement envie de lire à propos de Le C10k Problème. Cette page décrit la plupart des problèmes que vous rencontrerez que vous évoluer votre nombre de connexions client à un serveur unique.
Vous aurez à prouver.
Ne pensez-vous pas que un sept ans le problème est toujours d'actualité aujourd'hui avec Core I7 8Go de RAM, et 2 réseau de 1Go chacun ? Comme je l'ai dit dans mon premier post, avec 32720 clients connectés, le cpu est toujours à moins de 10% de l'utilisation, et la mémoire libre est suffisant pour ouvrir plus de connexion (4Go). et voici quelques ifstat lignes eth0 KO/s en KO/s 89.22 145.37 126.97 136.15 104.11 158.18 84.17 123.62 90.64 106.47 93.17 125.98 97.21 130.69
aha, et la plupart des piles TCP ont été écrites il y a 30 ans. Gigas de RAM n'ont rien à voir avec cela, c'est le client plage de ports. Manifestement, vous n'avez aucune idée, donc, ne vous une faveur et d'écouter ce que les gens expérimentés ont à dire.
faites-vous une faveur et de lire ceci : metabrew.com/article/... connu un...
OriginalL'auteur Greg Hewgill
Sur Gnu+Linux, le maximum est ce que vous avez écrit. Ce nombre est (probablement) a déclaré quelque part dans les normes de mise en réseau. Je doute que vous avez vraiment besoin d'autant de prises de courant. Vous devez optimiser la façon dont vous êtes à l'aide de sockets au lieu de créer des dizaines de tous les temps.
Aucun, socket n'est une ressource limitée. Les Clients sont à l'aide de sockets. Il n'est pas vrai que le socket = client connecté ou chaque client a besoin de son propre support. Il repose sur le protocole. Par exemple, TCP besoins d'une telle association (1 douille - 1 client) mais UDP ne le fait pas. Même lors de l'utilisation de TCP, qui a dit que la connexion doit être continue?
Je voulais dire, dans notre logiciel un client = un socket... Nous utilisons le protocole SSL, ne UDP est hors de question, et la connexion doit être continu...
OriginalL'auteur skalee
Net/socket.c le fd est alloué dans sock_alloc_fd(), qui appelle get_unused_fd().
Regardant linux/fs/file.c, la seule limite au nombre de fd est
sysctl_nr_open
, qui est limitée àet peut être lu à l'aide de
sysctl fs.nr_open
qui donne 1M par défaut ici. Ainsi, le fd est probablement pas votre problème.modifier vous probablement à l'époque de la vérification, en tant que bien, mais pourriez-vous partager la sortie de
avec nous?
Les Ports doivent être bien aussi. Si vous utilisez un serveur, il doit être à l'écoute sur un port, et tous les clients connectés à ce même numéro de port. Seulement quelques protocoles fonctionnent différemment-avec FTP, étant le seul que je peux venir avec droit de les désactiver, et c'est parce qu'il utilise une socket pour le transfert de données.
votre question a été sur les sockets, et ceux-ci ne semble pas être le problème. "ports" ne peut pas être un problème si vous êtes le serveur et les clients de se connecter à vous. Sinon, il peut être, et vous pouvez avoir à augmenter net.ipv4.ip_local_port_range. S'il vous plaît être un peu plus précis sur la situation; qu'est-ce exactement échoue, donnant à ce que la valeur de retour?
avez-vous vérifier rlimits? voir mise à jour de réponse
Si vous avez besoin d'un seul port par le client, d'augmenter la plage de ports, et l'utilisation de plusieurs adresses ip. Il n'y a qu'64 ko ports dans les 2 octets 😉
OriginalL'auteur mvds
Généralement avoir trop de connexions en temps réel est une mauvaise chose. Toutefois, tout dépend de l'application et les modèles qu'elle communique avec ses clients.
Je suppose qu'il s'agit d'un modèle lorsque les clients doivent être en permanence async-connecté et c'est la seule façon d'une solution distribuée.
Assumimg il n'y a pas de goulots d'étranglement dans la mémoire/cpu/réseau pour le courant de charge, et en gardant à l'esprit que laisser inactif connexion ouverte est la seule façon d'applications distribuées consomme moins de ressources (par exemple, temps de connexion, et l'ensemble de l'/maximale de la mémoire), l'ensemble des OS de performance du réseau pourrait être plus élevé que d'utiliser les meilleures pratiques, nous le savons tous.
Bonne question et il a besoin d'une solution. Le problème est que personne ne peut répondre à cette question. Je suggère d'utiliser divide & conquer technique et lorsque le goulot d'étranglement est trouvé à nous retourner.
Veuillez prendre en dehors de votre application sur banc d'essai et vous trouverez le goulot d'étranglement.
OriginalL'auteur momentics
Vérifier les limites réelles du processus en cours d'exécution.
Le max pour nofiles est déterminé par le Noyau, la suivante en tant que root permettrait d'augmenter le max de 100 000 "fichiers", c'est à dire 100 CC
Pour la rendre permanente, éditez le fichier /etc/sysctl.conf
Vous devez alors le serveur pour demander plus d'ouvrir des fichiers, ce qui est différent par serveur. Dans nginx, par exemple, vous définissez
Redémarrage de nginx et vérifier /proc/{pid}/limites
Pour tester cela, vous avez besoin de 100 000 prises dans votre client, vous êtes limité dans le test pour le nombre de ports en TCP par adresse IP.
Pour augmenter le port local de la gamme au maximum...
Cela vous donne ~64000 ports afin de le tester.
Si ce n'est pas suffisant, vous avez besoin de plus d'adresses IP. Lors de l'essai sur localhost, vous pouvez lier le client/source une adresse autre que l'adresse 127.0.0.1 /localhost.
Par exemple, vous pouvez lier votre client de test de l'IPs sélectionnés au hasard à partir de l'adresse 127.0.0.1 à 127.0.0.5
À l'aide d'apache-banc, vous définissez
Nodejs aux prises l'utilisation
/etc/security/limits.conf configure PAM: il est généralement hors de propos pour un serveur.
Si le serveur proxy demandes à l'aide de TCP, en utilisant, en amont ou mod_proxy par exemple, le serveur est limité par ip_local_port_range. Cela pourrait facilement être la limite de 32 000.
OriginalL'auteur teknopaul