Maison  >  Article  >  Opération et maintenance  >  Comment résoudre certains problèmes courants causés par la gestion d'une concurrence élevée dans la maintenance des serveurs

Comment résoudre certains problèmes courants causés par la gestion d'une concurrence élevée dans la maintenance des serveurs

巴扎黑
巴扎黑original
2017-07-24 10:49:562831parcourir

Suivons le scénario ici, après tout, le scénario est le meilleur moyen de faire l'expérience de l'aspect pratique. Tout d'abord, parlons de la configuration et de l'environnement du serveur

Hôte cloud Alibaba Cloud ECS, mémoire 8 Go, processeur 4 cœurs, bande passante 20 Mo, disque système 20 Go + disque de données 200 Go, CentOS 6,564 bits, environnement lnmp intégré installé

Scénario : WeChat envoie des enveloppes rouges

Ce scénario est très courant. Généralement, les clients envoient une publicité depuis le compte public WeChat à l'heure actuelle. à environ 5 000. En parlant de cela, cela n'est pas réellement considéré comme une concurrence élevée, mais le serveur est toujours tombé en panne et il a fallu environ 5 minutes pour revenir à la normale. C’est un peu inapproprié, analysons les raisons. L'utilisation du processeur n'est pas élevée et l'utilisation de la mémoire est normale. Dans le panneau de configuration Alibaba Cloud, le trafic de sortie du réseau est saturé. Il semble que le problème soit dû à des raisons de réseau.

Tout d'abord, j'ai vérifié les ressources statiques et j'ai constaté que la plupart des images n'étaient pas optimisées, je les ai donc supprimées et effectué une compression sans perte. J'ai probablement omis environ 1 Mo de taille. Après la soumission, elles ont quand même planté. et le serveur affichait fréquemment 502.

Vérifiez à nouveau les ressources statiques css et js de la page et remplacez la bibliothèque js couramment utilisée par CDN pour réduire le nombre de requêtes. Après soumission, il n'y a toujours pas beaucoup de changement, et le 502 reste le même. .

Vérifiez donc le nombre de connexions nginx et utilisez la commande

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

Le résultat montre

TIME_WAIT 3828SYN_SENT 1FIN_WAIT1 107FIN_WAIT2 27ESTABLISHED 661SYN_RECV 23CLOSING 15LAST_ACK 284

Bon garçon, TIME_WAITE est très élevé, assurez-vous de parler de la signification de TIME_WAITE ici : TIME_WAIT : une version a été initialisée de l'autre côté. Qu'est-ce que cela signifie? Cela signifie que le serveur a été activement arrêté et attend une réponse du client. Si le client ne répond pas, il attendra et cette valeur augmentera. Évidemment, nous devons réduire la valeur de TIME_WAIT à ce moment-là.

Ici, il vous suffit de modifier certains paramètres de sysctl.conf. Modifiez le fichier /etc/sysctl.conf et vérifiez si

est un tel paramètre. Si celui correspondant est introuvable, archiver le fichier Ajoutez-le simplement à la fin. Après avoir enregistré, exécutez

/sbin/sysctl -p

pour le configurer pour qu'il prenne effet.

Continuez à vérifier le nombre de connexions nginx après 20 minutes. Le résultat est

TIME_WAIT 87SYN_SENT 1FIN_WAIT1 60FIN_WAIT2 19ESTABLISHED 477SYN_RECV 12CLOSING 2LAST_ACK 100

et il est revenu à la normale, et la bande passante du réseau a également diminué. .

Mais les bons moments n'ont pas duré longtemps. Quand j'ai commencé à récupérer des enveloppes rouges à la deuxième heure, 502 sont réapparues. La vérification du processus a révélé que l'utilisation du processeur de mysqld était très élevée, provoquant une charge complète du processeur et un crash du serveur. Modifiez le fichier de configuration MySQL et ajustez max_connection à 30000. D'autres paramètres associés ont été ajustés et optimisés, et la situation a été atténuée, mais en quelques minutes, le processeur était à nouveau complètement chargé.

Bizarre ! J'ai donc vérifié le processus dans MySQL et constaté qu'il y avait des requêtes SQL fréquentes et que le volume de données de plusieurs tables interrogées était d'environ 100 000. Il a été jugé que c'était parce qu'aucun index n'était défini. Après avoir consulté le développement back-end, il s'est avéré que seule la clé primaire était définie. Modifiez-le immédiatement. Cinq minutes après l'avoir soumis, le CPU a chuté et s'est stabilisé à environ 10 %, et 502 n'est plus apparu.

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:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn