Nginx utilise-t-il le multithreading en interne ?

Question

Nginx divise le traitement d'une requête en plusieurs phases. Y aura-t-il un blocage des E/S pendant ces étapes ? En cas de blocage, Nginx exécutera d'autres requêtes, mais y aura-t-il une distinction de priorité lors de l'exécution d'autres requêtes (les requêtes qui ont déjà progressé vers une étape ultérieure seront-elles exécutées en premier ?) ? retour...

伊谢尔伦 · Answer

cat /proc/3776/status|grep Threads On peut voir que le processus de travail Nginx n'a qu'un seul thread, dont 3776 est le PID du processus de travail Nginx. De plus, Nginx a ajouté la prise en charge du pool de threads AIO à partir de la version 1.7.11 et peut utiliser le multithread AIO pour lire et envoyer des fichiers volumineux afin d'éviter que le processus de travail ne soit bloqué (utilisez sendfile pour les petits fichiers et le pool de threads AIO pour les gros fichiers. ). Pour activer la prise en charge du pool de threads, vous devez ajouter explicitement l'option --with-threads lors de la configuration.
https://www.nginx.com/blog/thread-pools-boost-performance-9x/
http://nginx.org/en/docs/ngx_core_module.html#thread_pool

Transfert :
Lorsque Listen_fd a une nouvelle requête accept(), le système d'exploitation réveillera tous les processus enfants, car ces processus epoll_wait() ont tous le même Listen_fd, et le système d'exploitation n'a aucun moyen de juger qui est responsable de l'acceptation, donc cela les réveille simplement tous. , mais à la fin, un seul processus acceptera avec succès, et les autres processus ne parviendront pas à accepter. Tous les processus enfants sont "effrayés", c'est pourquoi cela s'appelle Thundering Herd.

Le socket d'écoute est initialisé au démarrage. Le processus de travail accepte, lit les requêtes et génère des réponses via ces sockets. Nginx n'utilise pas le processus maître pour distribuer les requêtes comme PHP-FPM. Ce travail est effectué par le mécanisme du noyau du système d'exploitation. , cela peut donc provoquer un phénomène de panique, c'est-à-dire que lorsque Listen_fd a une nouvelle requête accept(), le système d'exploitation réveillera tous les processus enfants.

L'idée de Nginx pour résoudre les groupes tonitruants : évitez les groupes tonitruants
http://nginx.org/en/docs/ngx_core_module.html#accept_mutex
Les mesures spécifiques incluent l'utilisation d'un verrouillage mutex global (accept_mutex activé), et chacun. processus de travail dans epoll_wait () avant de demander le verrouillage, continuez le traitement si l'application est obtenue et attendez si elle ne peut pas être obtenue, et configurez un algorithme d'équilibrage de charge (lorsque le volume de tâches d'un certain processus de travail atteint 7/8 de le volume total défini, il n'essaiera pas de demander à nouveau un verrouillage) pour équilibrer la charge de travail de chaque processus.

La nouvelle façon de Nginx de résoudre le problème des groupes tonitruants : utilisez la fonction Socket ReusePort fournie par le noyau
NGINX 1.9.1 prend en charge le partitionnement de socket :
http://nglua.com/docs/sharding.html
NGINX1.9.1 prend en charge le Option SO_REUSEPORT du socket, cette option est disponible dans les versions plus récentes de nombreux systèmes d'exploitation, y compris DragonFly BSD et Linux (noyau 3.9+). Cette option permet à plusieurs sockets d'écouter sur la même combinaison d'adresse IP et de port. La charge du noyau équilibre les connexions entrantes. à ces sockets.Fragmentation efficace.Lorsque l'option SO_REUSEPORT n'est pas activée, le socket d'écoute avertira un processus par défaut lorsqu'une connexion arrive. Si la commande accept_mutex off réveille tous les processus en cours à ce moment, ils entreront en concurrence. obtenez-le. C'est ce qu'on appelle le phénomène de troupeau de tonnerre. Si vous utilisez epoll sans verrouillage (accept_mutex désactivé), lorsqu'il y a une opération de lecture sur le port d'écoute, un phénomène de troupeau de tonnerre se produira. Après avoir activé l'option SO_REUSEPORT, chaque processus a. son propre socket d'écoute indépendant. Le noyau détermine quel socket (processus) valide obtient la connexion. Cela réduit la latence et améliore les performances des processus de travail, cela signifie également que les processus de travail reçoivent de nouvelles connexions avant d'être prêts à les gérer

.

nginx fonctionne par défaut en mode multi-processus, avec un processus maître et plusieurs processus de travail. Le processus principal est principalement utilisé pour gérer les processus de travail en concurrence égale pour les demandes des clients. mais ne peut pas traiter les demandes d'autres processus de travail. Il n'y a qu'un seul thread principal dans chaque processus de travail. Avec la prise en charge d'epoll, il utilise une méthode asynchrone non bloquante pour traiter les demandes afin d'obtenir une concurrence élevée. epoll prend en charge la surveillance de plusieurs événements (interrogation de socket). ). Lorsque l'événement n'est pas prêt, placez-le dans epoll. Lorsque l'événement est prêt, lisez et écrivez. Par rapport au multi-threading, cette méthode de traitement d'événement présente de grands avantages. Il n'est pas nécessaire de créer des threads et chaque requête occupe. Il y a également très peu de mémoire, pas de changement de contexte et le traitement des événements est très léger. Quel que soit le nombre de simultanéités, cela n'entraînera pas de gaspillage inutile de ressources (un plus grand nombre de simultanéités occupera simplement plus de mémoire). La méthode de travail courante de httpd est que chaque requête occupe un thread de travail. Lorsque le nombre de concurrence atteint des milliers, des milliers de threads traitent les requêtes en même temps. C'est un grand défi pour le système d'exploitation. Cela est très important et la surcharge du processeur causée par le changement de contexte de thread est très importante. Naturellement, les performances de httpd ne peuvent pas être améliorées. L'équipe Tengine a déjà testé le nombre de connexions gérées par Nginx. Le nombre de requêtes simultanées a atteint plus de 2 millions (en moyenne, 1 Go de mémoire peut gérer plus de 80 000 requêtes.) Nginx prend en charge la liaison d'un certain processus à un certain cœur (liaison d'affinité CPU), de sorte qu'il n'y aura aucun problème dû. pour changer de processus. Pour éviter une défaillance du cache, il est recommandé de configurer plusieurs processus de travail en fonction du nombre de cœurs dans le processeur. Cependant, notez qu'un nombre trop élevé de processus de travail ne fera qu'entraîner une concurrence pour les ressources du processeur, provoquant ainsi un contexte inutile. commutation. Par conséquent, les processus de travail Plus il y a de processus, mieux c'est. Pour plus de détails, voir :
http://tengine.taobao.org/book/chapter_02.html

.