Utilisation CPU de 700% du processus immortel Linux

2020-02-14

1. Problème de recherche


 [root @ zwlbs3 ~] # top 
 

i. J'ai constaté qu'il existe un processus avec une utilisation du processeur de 700%. La COMMANDE est composée de chaînes aléatoires. Elle remporte trop l'enchère; la première pensée est de "découper le sable", et la commande kill m'a donné.


 [root @ zwlbs3 ~] # kill -9 "PID" 
 

ii. Mais il a été constaté que le processus de mise à mort a commencé doucement après un certain temps.

Remarque: L'ancienne image est réutilisée et le PID et la COMMANDE sont modifiés.

2. Affichez les détails du processus


 [root @ zwlbs3 ~] # cd / proc / 748 /
 [root @ zwlbs3 748] # ls -ial

 # "748" est le PID du processus. Vérifiez-le simplement en fonction de votre PID.  
 

Comme indiqué:

J'ai trouvé que le processus se trouve dans le répertoire / dev / shm. Quel répertoire est / dev / shm?

Prenez un paragraphe sur Internet et nous expliquerons / dev / shm

1) Tout d'abord, nous pouvons voir que / dev / shm est un fichier de périphérique. Vous pouvez considérer / dev / shm comme l'entrée de la mémoire système. Vous pouvez le considérer comme un périphérique de stockage physique. Un système de fichiers tmp, vous pouvez utiliser Cet appareil lit et écrit des fichiers en mémoire pour accélérer certaines opérations d'E / S élevées, telles que l'ouverture, l'écriture et la lecture fréquentes d'un fichier volumineux.

2) On dit qu'oracle utilise / dev / shm (shitou n'a pas utilisé oracle). Vous pouvez utiliser la commande mount pour lister les systèmes de fichiers actuellement montés de / dev / shm.

3) Puisqu'il s'agit d'un système de fichiers basé sur la mémoire, les fichiers sous / dev / shm n'existent plus après le redémarrage du système. La partition Linux par défaut (CentOS) / dev / shm représente 50% de la mémoire physique du système, bien que l'efficacité des opérations sur les fichiers à l'aide de / dev / shm soit beaucoup plus élevée. Cependant, il est rarement utilisé dans les logiciels de distribution (sauf Oracle mentionné ci-dessus). Vous pouvez vérifier s'il y a des fichiers ci-dessous par ls / dev / shm. Sinon, cela signifie que le périphérique n'est pas utilisé dans le système actuel.

Rechercher les fichiers associés dans le répertoire / dev / shm


 [root @ zwlbs3 ~] # ls -a / dev / shm /
 ..

 # Pas de fichiers associés, bizarre.  
 
      
  • Crontab n'a également aucune tâche planifiée associée.
  •   
  • Aucun fichier pertinent n'a été trouvé à l'aide de la commande which.
  •   
  • La visualisation du journal système est également normale et très étrange.
  •   
  • Peu de fichiers liés à ce processus ont été trouvés.
  • 3. Solutions

    i. Afficher l'analyse de l'occupation du thread interne d'un processus


     [root @ zwlbs3 ~] # top -H -p "PID" 
     

    ii. Il y a tellement de processus liés, tuez-les tous

    iii. Vérifiez à nouveau dans quelques minutes et constatez que la charge du système est revenue à la normale

    Je pensais que c'était résolu, mais après quelques heures d'inspection, je l'ai retrouvé, bon sang.

    Parce que l'environnement de production n'est pas pratique pour redémarrer le serveur, je n'ai pas d'autre choix que d'essayer de redémarrer Dafa.

    4. Redémarrez Dafa

    Une heure après le redémarrage du serveur, vérifiez à nouveau qu'il est revenu à la normale ou redémarrez Dafa pour le faire fonctionner.

    Que fait ce programme malveillant? Pourquoi ne consommer que des ressources CPU? Étant donné que les informations pertinentes sur le fichier n'ont pas été trouvées, la raison n'est pas encore claire.

    Dites-moi si vous savez, merci beaucoup!

    Résumé

    Ce qui précède est le contenu entier de cet article. J'espère que le contenu de cet article aura une certaine référence et valeur d'apprentissage pour l'étude ou le travail de chacun. Merci pour votre soutien.

www.xd1998.com@2001-2030Partage De Technologie