Maison  >  Article  >  Opération et maintenance  >  Méthodes d'optimisation des performances Nginx

Méthodes d'optimisation des performances Nginx

王林
王林avant
2023-05-28 08:01:511267parcourir

Méthodes doptimisation des performances Nginx

Optimisation des paramètres du système Linux

Certaines configurations mentionnées ci-dessous nécessitent plus Seulement le nouveau Linux (2.6 ou supérieur) peut le prendre en charge. L'auteur utilise CentOS 7.4, version du noyau 3.10. S'il ne répond pas aux besoins, il est préférable de mettre à niveau en conséquence. Après tout, l'application de correctifs est une tâche ingrate. Pour le réglage au niveau du système, nous modifions généralement simplement la limite du descripteur de fichier, la longueur de la file d'attente du tampon et le nombre de ports temporaires.

Limite du descripteur de fichier

Étant donné que chaque connexion TCP occupe un descripteur de fichier, une fois le descripteur de fichier épuisé, les nouvelles connexions renverront "Trop de" fichiers ouverts", afin de Pour améliorer les performances, nous devons le modifier : 1. Restrictions au niveau du système Editez le fichier /etc/sysctl.conf et ajoutez le contenu suivant :

fs.file-max =10000000
fs.nr_open =10000000

Restrictions au niveau de l'utilisateur Editez le fichier /etc/security /limits.conf et ajoutez le contenu suivant :

 *      hard   nofile      1000000
 *      soft   nofile      1000000

Nous devons nous assurer que la limite de niveau utilisateur est inférieure à la limite de niveau système, sinon cela entraînera l'impossibilité de se connecter via SSH. Une fois la modification terminée, exécutez la commande suivante :

 $ sysctl -p

Vous pouvez vérifier si la modification a réussi en exécutant la commande ulimit -a.

Longueur de la file d'attente de connexion TCP

Modifiez le fichier /etc/sysctl.conf et ajoutez le contenu suivant :

# The length of the syn quenenet.ipv4.tcp_max_syn_backlog =65535# The length of the tcp accept queuenet.core.somaxconn =65535

où tcp_max_syn_backlog est utilisé pour spécifier la longueur de la file d'attente SYN semi-connectée. Lorsqu'une nouvelle connexion arrive, le système détectera la file d'attente SYN semi-connectée. Si la file d'attente est pleine, la demande SYN ne peut pas être traitée et les comptes statistiques somaxconn seront augmentés dans ListenOverflows et ListenDrops dans. /proc/net/netstat pour la longueur de file d'attente ACCEPT de connexion complète spécifiée Lorsque la file d'attente est pleine, le paquet ACK envoyé par le client ne sera pas traité correctement et l'erreur « connexion réinitialisée par le homologue » sera renvoyée. journal des erreurs "pas d'amont en direct lors de la connexion aux amonts" Si l'erreur ci-dessus se produit, nous devons envisager d'augmenter la configuration de ces deux éléments.

Port temporaire

Étant donné que Nginx est utilisé comme proxy, chaque connexion TCP au service Web en amont occupera un port temporaire, nous devons donc modifier le paramètre ip_local_port_range pour modifier /etc/ sysctl.conf, ajoutez le contenu suivant :

net.ipv4.ip_local_port_range =102465535
net.ipv4.ip_local_reserved_ports =8080,8081,9000-9010

Parmi eux, le paramètre ip_local_reserved_ports est utilisé pour spécifier le port réservé afin d'éviter que le port de service ne soit occupé et ne puisse démarrer. .

Optimisation des paramètres Nginx

L'optimisation des paramètres Nginx tourne principalement autour du fichier de configuration nginx.conf, qui ne sera pas décrit en détail ci-dessous.

Worker process

Une raison importante des puissantes performances de Nginx est qu'il adopte un modèle d'E/S multi-processus non bloquant, nous devons donc en faire bon usage :

# 🎜🎜#
  • worker_processes Le Nginx par défaut n'a qu'un seul processus maître et un seul processus de travail. Nous devons le modifier. Il peut être défini sur un nombre spécifié ou sur. auto, qui est le système Le nombre de cœurs de processeur. L'augmentation du nombre de travailleurs peut entraîner une concurrence entre les processus pour les ressources CPU, entraînant des changements de contexte inutiles. Nous l'avons donc simplement défini sur le nombre de cœurs de processeur : worker_processes auto

  • worker_connections Le nombre de connexions simultanées que chaque travailleur peut gérer. la valeur par défaut de 512 n'est pas suffisante, nous l'augmentons de manière appropriée : worker_connections 4096

  • Nginx prend en charge les méthodes de réutilisation d'E/S suivantes. Gérer les connexions : select, poll, kqueue, epoll, rtsig, /dev/poll, eventport. Différents systèmes d'exploitation utilisent différents outils, et dans les systèmes Linux, epoll est le plus efficace. Pour éviter des établissements et des déconnexions fréquents de Nginx vers les services Web, nous pouvons activer la fonctionnalité de connexion longue KeepAlive prise en charge à partir de HTTP 1.1. Elle peut réduire considérablement la surcharge du processeur et du réseau. Dans notre combat actuel, c’est aussi la plus grande amélioration des performances. Keepalive doit être utilisé avec proxy_http_version et proxy_set_header. La configuration de référence est la suivante :

    upstream BACKEND {
        keepalive 300;
         server 127.0.0.1:8081;
     }
    server {
         listen 8080;
        location /{
            proxy_pass http://BACKEND;
            proxy_http_version 1.1;
            proxy_set_header Connection"";
     }
    }

    où keepalive n'est ni le délai d'attente ni le nombre de pools de connexions. L'explication officielle est la suivante : .
  • Le paramètre connections définit le nombre maximum de connexions keepalive inactives aux serveurs en amont qui sont conservées dans le cache de chaque processus de travail. Lorsque ce nombre est dépassé, les connexions les moins récemment utilisées sont fermées.
#🎜🎜. #Vous pouvez voir ce que cela signifie "Nombre maximum de connexions longues inactives", les connexions longues inactives dépassant ce nombre seront recyclées. Lorsque le nombre de requêtes est stable et fluide, le nombre de connexions longues inactives sera très faible (proche de 0). ), mais en réalité le nombre de requêtes ne peut pas toujours être fluide et stable, lorsque le nombre de requêtes fluctue, le nombre de connexions longues inactives fluctue également :

Quand le le nombre de connexions longues inactives est supérieur à la valeur configurée, cela entraînera le recyclage de la partie de la connexion longue qui est supérieure à la valeur configurée

Lorsque la longue connexion la connexion ne suffit pas, une nouvelle connexion longue sera rétablie.

如果该值过小,连接池会经常进行回收、分配和再回收操作。为了避免这种情况出现,可以根据实际情况适当调整这个值,在我们实际情况中,目标QPS为6000,Web服务响应时间约为200ms,因此需要约1200个长连接,而 keepalive值取长连接数量的10%~30%就可以了,这里我们取300,如果不想计算,直接设为1000也是可行的。

Access-Log缓存

记录日志的I/O开销比较高,好在Nginx支持日志缓存,我们可以利用这个功能,降低写日志文件的频率,从而提高性能。结合使用buffer和flush两个参数可以控制缓存行为

  access_log /var/logs/nginx-access.log buffer=64k gzip flush=1m

其中 buffer制定了缓存大小,当缓冲区达到 buffer所指定的大小时,Nginx就会将缓存起来的日志写到文件中;flush指定了缓存超时时间,当 flush指定的时间到达时,也会触发缓存日志写入文件操作。

文件描述符限制

Nginx配置中同样有相应的配置项:worker_rlimit_nofile, 理论上这个值应该设置为 /etc/security/limits.conf 中的值除以 worker_processes, 但实际中不可能每个进程均匀分配,所以这里只要设置成和 /etc/security/limits.conf 一样就可以了

 worker_rlimit_nofile 1000000;

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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer