Maison > Article > Tutoriel système > Lâchez-moi, le processeur du système Linux est plein à 100 % !
Hier après-midi, j'ai soudainement reçu une alerte e-mail du service d'exploitation et de maintenance, qui montrait que le taux d'utilisation du processeur du serveur de la plateforme de données atteignait 98,94 %. Ces derniers temps, ce taux d'utilisation est resté supérieur à 70 %. À première vue, il semble que les ressources matérielles aient atteint un goulot d'étranglement et doivent être étendues. Mais après y avoir réfléchi attentivement, j'ai découvert que notre système d'entreprise n'est pas une application hautement concurrente ou gourmande en CPU. Ce taux d'utilisation est trop exagéré et le goulot d'étranglement matériel ne peut pas être atteint aussi rapidement. Il doit y avoir un problème avec la logique du code métier quelque part.
Connectez-vous d'abord au serveur et utilisez la commande top pour confirmer la situation spécifique du serveur, puis analysez et jugez en fonction de la situation spécifique.
En observant la charge moyenne et la norme d'évaluation de charge (8 cœurs), on peut confirmer que le serveur a une charge élevée
;En observant l'utilisation des ressources de chaque processus, nous pouvons voir que le processus portant l'ID de processus 682 a un ratio CPU plus élevé
Ici, nous pouvons utiliser la commande pwdx pour trouver le chemin du processus métier en fonction du pid, puis localiser le responsable et le projet :
On peut conclure que ce processus correspond au service web de la plateforme de données.
La solution traditionnelle se déroule généralement en 4 étapes :
1. premier ordre par avec P : 1040 // Triez d'abord par charge de processus pour trouver maxLoad(pid)
2. top -Hp process PID : 1073 // Trouvez le PID du thread de chargement approprié
3. printf « 0x%x » PID du fil : 0x431 // Convertissez le PID du fil en hexadécimal pour préparer la recherche ultérieure dans le journal jstack
4. Processus jstack PID | vim +/fil hexadécimal PID – // Par exemple : jstack 1040|vim +/0x431 –
Mais pour la localisation des problèmes en ligne, chaque seconde compte, et les 4 étapes ci-dessus sont encore trop lourdes et prennent beaucoup de temps. Oldratlee, qui a déjà présenté Taobao, a encapsulé le processus ci-dessus dans un outil : show-busy-java-threads.sh. Vous pouvez facilement localiser ce type de problème en ligne :
On peut conclure que le processeur d'exécution d'une méthode d'outil temporel dans le système est relativement élevé. Après avoir localisé la méthode spécifique, vérifiez s'il existe des problèmes de performances dans la logique du code.
※ Si le problème en ligne est plus urgent, vous pouvez omettre 2.1 et 2.2 et exécuter directement 2.3. L'analyse ici est sous plusieurs angles juste pour vous présenter une idée d'analyse complète.
Après l'analyse et le dépannage précédents, nous avons finalement localisé un problème avec les outils de temps, qui entraînait une charge excessive du serveur et une utilisation excessive du processeur.
n calculs, et à mesure que le temps augmente, le nombre Le nombre de requêtes uniques se rapproche de minuit et augmentera de manière linéaire. Étant donné qu'un grand nombre de requêtes de requêtes provenant de modules tels que les requêtes en temps réel et les alarmes en temps réel nécessitent d'appeler cette méthode plusieurs fois, une grande quantité de ressources CPU est occupée et gaspillée. 4.Solution
2. Idées de dépannage
;
En observant l'utilisation des ressources de chaque processus, nous pouvons voir que le processus portant l'ID de processus 682 a un ratio CPU plus élevé
2.3 Localisez le fil anormal et les lignes de code spécifiques
1. premier trieur par avec P : 1040 // Triez d'abord par charge de processus pour trouver maxLoad(pid)
2. top -Hp process PID : 1073 // Trouvez le PID du thread de chargement approprié
3. printf « 0x%x » PID du fil : 0x431 // Convertissez le PID du fil en hexadécimal pour préparer la recherche ultérieure dans le journal jstack
4. Processus jstack PID | vim +/fil hexadécimal PID – // Par exemple : jstack 1040|vim +/0x431 –
Mais pour la localisation des problèmes en ligne, chaque seconde compte, et les 4 étapes ci-dessus sont encore trop lourdes et prennent beaucoup de temps. Oldratlee, qui a déjà présenté Taobao, a encapsulé le processus ci-dessus dans un outil : show-busy-java-threads.sh. Vous pouvez facilement localiser ce type de problème en ligne :
On peut conclure que le processeur d'exécution d'une méthode d'outil temporel dans le système est relativement élevé. Après avoir localisé la méthode spécifique, vérifiez s'il existe des problèmes de performances dans la logique du code.
※ Si le problème en ligne est plus urgent, vous pouvez omettre 2.1 et 2.2 et exécuter directement 2.3. L'analyse ici est sous plusieurs angles juste pour vous présenter une idée d'analyse complète.
Après l'analyse et le dépannage précédents, nous avons finalement localisé un problème d'outil de temps, qui entraînait une charge excessive du serveur et une utilisation excessive du processeur.
n calculs, et à mesure que le temps augmente, le nombre Le nombre de requêtes uniques se rapproche de minuit et augmentera de manière linéaire. Étant donné qu'un grand nombre de requêtes de requêtes provenant de modules tels que les requêtes en temps réel et les alarmes en temps réel nécessitent d'appeler cette méthode plusieurs fois, une grande quantité de ressources CPU est occupée et gaspillée. 4.Solution
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!