Comment ajuster le nombre maximum de limites de connexion socket pour les serveurs Web et les serveurs de cache en cas de concurrence élevée

Serveur Web et serveur de cache, sous haute concurrence, la limite du nombre maximum de connexions socket est ajustée :

1. Modifiez la limite du nombre maximum de fichiers qu'un processus utilisateur peut ouvrir.

Effet immédiat : ulimit-nxxx

Effectif définitivement :

echo "ulimit-HSn65536">>/etc/rc.local

echo "ulimit-HSn65536">>/root/.bash_profile

ulimit-HSn65536

2. Modifiez la limite du noyau réseau sur le nombre maximum de connexions TCP.

/etc/sysctl.conf

一、

Sur la plate-forme Linux, que vous écriviez un programme client ou un programme serveur, lors du traitement de connexions TCP simultanées étendues, le nombre le plus élevé de simultanéités sera soumis à la limite du système sur le nombre de fichiers qu'un utilisateur peut ouvrir en même temps. temps en un seul processus (en effet, le système crée un handle de socket pour chaque connexion TCP et chaque handle de socket est également un handle de fichier). Par exemple : un programme Redis qui ne démarre qu'un seul processus ne peut ouvrir que 1024 fichiers (1024 par défaut) (1024 connexions TCP = 1024 descripteurs de connexion socket = 1024 descripteurs de fichiers),

Vous pouvez utiliser la commande ulimit pour vérifier la limite du nombre de fichiers que le système autorise le processus utilisateur actuel à ouvrir :

$ulimit-n

1024

Cela signifie que chaque processus de l'utilisateur actuel est autorisé à ouvrir jusqu'à 1024 fichiers en même temps. Parmi ces 1024 fichiers, l'entrée standard, la sortie standard, l'erreur standard, le socket d'écoute du serveur et le domaine Unix de communication inter-processus. doit être ouvert par chaque processus doit être supprimé. Le socket et les autres fichiers, de sorte que le nombre de fichiers restants pouvant être utilisés pour la connexion au socket client n'est que d'environ 1024-10 = 1014. Autrement dit, par défaut, les programmes de communication basés sur Linux autorisent jusqu'à 1 014 connexions TCP simultanées en même temps.

Pour les gestionnaires de communication qui souhaitent prendre en charge un nombre plus élevé de connexions TCP simultanées, vous devez modifier le nombre de fichiers ouverts par Linux en même temps pour le processus de l'utilisateur actuel :

Soft limit (softlimit) : fait référence à Linux limitant davantage le nombre de fichiers que les utilisateurs peuvent ouvrir en même temps dans la plage que le système actuel peut supporter

;

Limite stricte : le nombre maximum de fichiers pouvant être ouverts simultanément par le système est estimé en fonction des ressources matérielles du système (principalement la mémoire vidéo du système).

Généralement, la limite souple est supérieure ou égale à la limite stricte

Le moyen le plus simple de modifier la limite du nombre maximum de fichiers ouverts par un seul processus est d'utiliser la commande ulimit :

[speng@as4~]$ulimit-n

Dans la commande ci-dessus, spécifiez le nombre maximum de fichiers qu'un seul processus est autorisé à ouvrir. Si le système renvoie quelque chose comme "Operationnotperowed", cela signifie que le changement de limite ci-dessus a échoué. En fait, c'est parce que la valeur spécifiée dépasse la limite souple ou la limite stricte du système Linux sur le nombre de fichiers ouverts par l'utilisateur. Par conséquent, il est nécessaire de modifier les limites souples et strictes du système Linux concernant le nombre de fichiers ouverts pour les utilisateurs.

La première étape consiste à modifier le fichier /etc/security/limits.conf et à ajouter les lignes suivantes au fichier :

spengsoftnofile10240

spenghardnofile10240

speng spécifie la limite du nombre de fichiers ouverts à modifier pour cet utilisateur. Le signe '*' peut être utilisé pour indiquer la modification de la limite pour tous les utilisateurs ;

soft ou hard spécifie s'il faut modifier la limite logicielle ou la limite stricte ; 10240 spécifie la nouvelle valeur limite que vous souhaitez modifier, c'est-à-dire le nombre maximum de fichiers ouverts (veuillez noter que la valeur limite logicielle doit être supérieure ou égale à la limite dure). Enregistrez le fichier après avoir apporté des modifications.

La deuxième étape consiste à modifier le fichier /etc/pam.d/login et à ajouter les lignes suivantes au fichier :

sessionrequired/lib/security/pam_limits.so Cela indique à Linux qu'une fois que l'utilisateur a terminé la connexion au système, le module pam_limits.so doit être appelé pour définir la limite maximale du système sur le nombre de ressources diverses que l'utilisateur peut utiliser (y compris le nombre maximum de ressources que l'utilisateur peut ouvrir) limite du nombre de fichiers), et le module pam_limits.so lira la configuration du fichier /etc/security/limits.conf pour définir cette valeur limite. Enregistrez ce fichier après avoir apporté des modifications.

La troisième étape consiste à vérifier la limite au niveau du système Linux sur le nombre maximum de fichiers ouverts, utilisez la commande suivante :

[speng@as4~]$cat/proc/sys/fs/file-max

12158

Cela montre que ce système Linux peut autoriser jusqu'à 12 158 fichiers à ouvrir en même temps (c'est-à-dire, y compris le nombre total de fichiers ouverts par tous les utilisateurs), ce qui est une limite stricte au niveau du système Linux pour tous les utilisateurs. les limites sur le nombre de fichiers ouverts ne doivent pas dépasser cette valeur. Généralement, cette limite stricte au niveau du système est la meilleure limite maximale du nombre de fichiers ouverts en même temps, en fonction des ressources matérielles du système au démarrage du système Linux. S'il n'y a pas de besoin particulier, cette limite ne doit pas être modifiée, sauf si. vous souhaitez limiter le nombre de fichiers ouverts au niveau de l'utilisateur. Définissez une valeur qui dépasse cette limite.

La façon de modifier cette limite stricte est de modifier le script /etc/rc.local et d'ajouter la ligne suivante au script :

echo22158>/proc/sys/fs/file-max

Il s'agit de forcer Linux à définir la limite stricte au niveau du système sur le nombre de fichiers ouverts à 22 158 une fois le démarrage terminé. Enregistrez ce fichier après la modification.

Après avoir terminé les étapes ci-dessus, redémarrez le système. Normalement, vous pouvez définir le nombre maximum de fichiers que le système Linux autorise un seul processus d'un utilisateur spécifié à ouvrir en même temps sur une valeur spécifiée. Si après le redémarrage, vous utilisez la commande ulimit-n pour vérifier que la limite du nombre de fichiers qu'un utilisateur peut ouvrir est toujours supérieure à la valeur maximale définie dans les étapes ci-dessus, cela peut être dû au fait que la commande ulimit-n dans le Le script de connexion utilisateur /etc/profile a déjà désactivé le nombre de fichiers que l'utilisateur peut ouvrir en même temps. Le nombre de fichiers est limité. Parce que lorsque vous utilisez ulimit-n pour modifier la limite du système sur le nombre maximum de fichiers qu'un utilisateur peut ouvrir en même temps, la nouvelle valeur modifiée ne peut être que supérieure ou égale à la valeur précédemment définie par ulimit-n. , il est impossible d'utiliser cette commande pour réduire cette valeur limite.

Donc, si le problème ci-dessus existe, vous pouvez uniquement ouvrir le fichier de script /etc/profile et rechercher dans le fichier si ulimit-n est utilisé pour limiter le nombre maximum de fichiers que l'utilisateur peut ouvrir en même temps. Si elle est trouvée, supprimez cette commande de ligne ou modifiez la valeur définie par une valeur appropriée, enregistrez le fichier, puis l'utilisateur peut quitter et se reconnecter au système. Grâce aux étapes ci-dessus, la limite du système sur le nombre de fichiers ouverts est levée pour le programme de traitement des communications qui prend en charge le traitement des connexions TCP à haute concurrence.

2. Modifier les restrictions du noyau réseau sur les connexions TCP

Lors de l'écriture d'un gestionnaire de communication client sous Linux prenant en charge les connexions TCP à haute concurrence, vous constatez parfois que même si le système a levé la limite du nombre de fichiers que les utilisateurs peuvent ouvrir en même temps, il y aura toujours des problèmes lorsque le nombre de fichiers peut être ouvert simultanément. les connexions TCP simultanées tombent à un certain nombre. Il ne parvient pas non plus à établir une nouvelle connexion TCP. Il existe de nombreuses raisons à ces événements.

La première raison peut être que le noyau du réseau Linux a des restrictions sur la plage de numéros de port local. À ce stade, si vous analysez plus en détail pourquoi la connexion TCP ne peut pas être établie, vous constaterez que le problème est que l'appel connect() ne parvient pas à revenir. Le message d'erreur système est "Can'tassignrequestedaddress en même temps, si". Si vous utilisez l'outil tcpdump pour surveiller le réseau à ce moment-là, vous le ferez. Il a été constaté qu'il n'y avait aucun trafic réseau permettant au client d'envoyer des paquets SYN pendant la connexion TCP. Cette situation indique que le problème réside dans les limitations du noyau du système Linux local.

Bien que la cause première du problème soit que le module d'implémentation de contrat TCP/IP du noyau Linux limite la plage de numéros de port local correspondant à toutes les connexions TCP client du système (par exemple, le noyau limite la plage de numéros de port local nombres compris entre 1024 et 32768). Lorsqu'il y a trop de connexions client TCP dans le système à un certain moment, parce que chaque connexion client TCP occupe un numéro de port local unique (ce numéro de port est dans la limite de plage de numéros de port local du système), si certaines connexions client TCP ont occupe tous les numéros de port locaux et il est difficile d'attribuer un numéro de port local pour une nouvelle connexion client TCP. Pour cette raison, le système renvoie l'appel connect() dans ces cas et définit le message d'erreur sur "Can". 'adresse demandée par assignation".

Pour cette logique de contrôle, vous pouvez visualiser le code source du noyau Linux En prenant le noyau linux2.6 comme exemple, vous pouvez visualiser les fonctions suivantes dans le fichier tcp_ipv4.c :

staticinttcp_v4_hash_connect(structsock*sk)

Veuillez noter le contrôle d'accès à la variable sysctl_local_port_range dans la fonction ci-dessus. L'initialisation de la variable sysctl_local_port_range est définie dans la fonction suivante dans le fichier tcp.c :

void__inittcp_init(void)

La plage de numéros de port local par défaut définie lors de la compilation du noyau peut être trop petite, cette limite de plage de ports locaux doit donc être modifiée.

La première étape consiste à modifier le fichier /etc/sysctl.conf pour télécharger l'image système Linux et à ajouter les lignes suivantes au fichier :

net.ipv4.ip_local_port_range=102465000

Cela indique que la limite de plage de ports locaux du système est définie entre 1 024 et 65 000. Veuillez noter que la valeur minimale de la plage de ports locaux doit être inférieure ou égale à 1 024 ; et la valeur maximale de la plage de ports doit être supérieure ou égale à 65 535. Enregistrez ce fichier après avoir apporté des modifications.

La deuxième étape consiste à exécuter la commande sysctl :

[speng@as4~]$sysctl-p

S'il n'y a pas de message d'erreur dans le système, cela signifie que la nouvelle plage de ports locaux est définie avec succès. S'il est défini en fonction de la plage de ports ci-dessus, en théorie, un seul processus peut établir plus de 60 000 connexions client TCP en même temps.

La deuxième raison de l'échec des connexions TCP peut être que le pare-feu du noyau réseau Linux a une limite sur le nombre maximum de connexions TCP suivies. À ce stade, le programme semblera bloqué dans l'appel connect(), tout comme lors de l'arrêt. Si vous utilisez l'outil tcpdump pour surveiller le réseau, vous constaterez également qu'il n'y a pas de trafic réseau permettant au client d'envoyer SYN. paquets pendant la connexion TCP. Étant donné que le pare-feu suivra l'état de chaque connexion TCP dans le noyau, les informations de suivi seront placées dans la base de données conntrack située dans la mémoire du noyau. Lorsqu'il y a trop de connexions TCP dans le système, la capacité de la base de données est insuffisante, IP_TABLE n'a pas réussi à créer les informations de traçage pour la nouvelle connexion TCP, elle a donc semblé bloquer l'appel connect(). À ce stade, vous devez modifier la limite du noyau sur le nombre maximum de connexions TCP suivies. La technique est similaire à la modification de la limite du noyau sur la plage de numéros de port local :

La première étape consiste à modifier le fichier /etc/sysctl.conf et à ajouter les lignes suivantes au fichier :

net.ipv4.ip_conntrack_max=10240

Cela indique que la limite du système sur le nombre maximum de connexions TCP suivies est fixée à 10 240. Veuillez noter que cette valeur limite doit être aussi petite que possible pour économiser l'utilisation de la mémoire du noyau.

La deuxième étape consiste à exécuter la commande sysctl :

[speng@as4~]$sysctl-p

S'il n'y a pas de message d'erreur dans le système, cela signifie que le système a réussi à modifier la limite du nouveau nombre maximum de connexions TCP suivies. Si les paramètres ci-dessus sont définis, en théorie, un seul processus peut établir plus de 10 000 connexions client TCP en même temps.

Trois,

Lorsque vous utilisez une technologie de programmation prenant en charge les E/S réseau à haute concurrence pour compiler des applications de connexion TCP à haute concurrence sous Linux, vous devez utiliser une technologie d'E/S réseau appropriée et des mécanismes de répartition des tempêtes d'E/S. Les technologies d'E/S disponibles incluent les E/S synchrones, les E/S synchrones non bloquantes (également appelées E/S réactives) et les E/S asynchrones. Dans le cas d'une concurrence TCP élevée, si des E/S synchrones sont utilisées, Cela bloquera gravement le fonctionnement du programme à moins qu'un thread ne soit créé pour les E/S de chaque connexion TCP.

Cependant, limite du nombre de connexions TCP Linux, trop de threads entraîneront d'énormes dépenses en raison de la planification des threads du système. Pour cette raison, il n'est pas conseillé d'utiliser des E/S synchrones dans des situations de concurrence TCP élevée. Dans ce cas, vous pouvez envisager d'utiliser des E/S synchrones non bloquantes ou des E/S synchrones non bloquantes. en utilisant select(), poll(), epoll et d'autres mécanismes. La technologie des E/S asynchrones consiste à utiliser AIO.

Du point de vue du mécanisme de répartition des tempêtes d'E/S, il est inapproprié d'utiliser select() car il prend en charge un nombre limité de connexions simultanées (généralement dans les 1024). Si les performances sont prises en compte, poll() est également inapproprié limite du nombre de connexions TCP Linux, bien qu'il puisse prendre en charge un nombre plus élevé de concurrence TCP, et parce qu'il utilise un mécanisme de "coroutine", lorsque le nombre de concurrence est élevé, il s'exécute L'efficacité est assez faible et il peut y avoir une répartition inégale des ondes d'E/S, provoquant une « famine » d'E/S sur certaines connexions TCP. Si vous utilisez epoll ou AIO, ce problème n'existe pas (l'implémentation initiale de la technologie AIO dans le noyau Linux a été réalisée en créant un thread pour chaque requête d'E/S dans le noyau. Ces mécanismes d'implémentation sont utilisés dans le cas de hautes performances. (connexions TCP simultanées. Il semble également y avoir de sérieux problèmes de performances. Mais dans le dernier noyau Linux, l'implémentation AIO a été améliorée depuis longtemps).

En résumé, lors du développement d'applications Linux prenant en charge les connexions TCP à haute concurrence, la technologie epoll ou AIO doit être utilisée autant que possible pour obtenir un contrôle des E/S sur les connexions TCP simultanées. Cela améliorera la capacité du programme à gérer TCP à haute concurrence. Connexions. Le support offre des garanties d'E/S efficaces.

Optimisation du paramètre noyau sysctl.conf

/etc/sysctl.conf est un fichier de configuration utilisé pour contrôler le réseau Linux. Il est très important pour les programmes qui dépendent du réseau (tels que les serveurs Web et les serveurs de cache, RHEL fournit les meilleurs ajustements par défaut).

Configuration recommandée (effacez le contenu original de /etc/sysctl.conf et copiez-y le contenu suivant) :

cp/etc/sysctl.conf/etc/sysctl.conf.bak

echo"">/etc/sysctl.conf

vim/etc/sysctl.conf

net.ipv4.ip_local_port_range=102465535

net.core.rmem_max=16777216

net.core.wmem_max=16777216

net.ipv4.tcp_rmem=40968738016777216

net.ipv4.tcp_wmem=40966553616777216

net.ipv4.tcp_fin_timeout=10

net.ipv4.tcp_tw_recycle=1

net.ipv4.tcp_timestamps=0

net.ipv4.tcp_window_scaling=0

net.ipv4.tcp_sack=0

dev_max_backlog=30000

net.ipv4.tcp_no_metrics_save=1

net.core.somaxconn=10240

net.ipv4.tcp_syncookies=0

net.ipv4.tcp_max_orphans=262144

net.ipv4.tcp_max_syn_backlog=262144

net.ipv4.tcp_synack_retries=2

net.ipv4.tcp_syn_retries=2

Cette configuration fait référence à la configuration recommandée du vernis du serveur de cache et à la configuration recommandée de l'optimisation du système du serveur SunOne.

Cependant, la configuration recommandée par Varnish est problématique. Le fonctionnement réel montre que la configuration de "net.ipv4.tcp_fin_timeout=3" entraînera souvent l'échec de l'ouverture de la page et lorsque les internautes utilisent les navigateurs IE6, après avoir visité le site Web pendant un certain temps ; Pendant une période de temps, toutes les pages Web ne pourront pas être ouvertes et fonctionneront normalement après le redémarrage du navigateur. Il se peut que la vitesse d'Internet aux États-Unis soit rapide, mais nos conditions nationales déterminent que nous devons ajuster "net.ipv4.tcp_fin_timeout=10". Dans le cas de 10 secondes, tout est normal (inférence de fonctionnement réel).

Une fois les modifications terminées, exécutez :

sysctl-p/etc/sysctl.conf

sysctl-wnet.ipv4.route.flush=1

La commande prend effet. Pour plus de sécurité, vous pouvez également redémarrer le système.

Ajustez le nombre maximum de descripteurs de fichiers ouverts (nombre maximum de connexions TCP dans un seul processus = nombre maximum de connexions socket dans un seul processus) :

Après avoir optimisé le réseau du système Linux, le nombre de fichiers autorisés à être ouverts par le système doit être augmenté pour prendre en charge une grande concurrence. La valeur par défaut de 1024 est loin d'être suffisante.

Exécuter la commande :

Code Shell

echo "ulimit-HSn65536">>/etc/rc.local

echo "ulimit-HSn65536">>/root/.bash_profile

ulimit-HSn65535

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!