Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 18/09/2019, à 12:13

tanfast

probleme de cpu /usr/bin/python3

Bonjour, j'ai un serveur en 16.04 et en regardant le htop je constate de CPU à 151%  et plus et je me demande comment investiguer plus en profondeur sur le % de CPU élevé svp?

  1  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]   Tasks: 134, 120 thr; 69 running
  2  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]   Load average: 54.46 84.18 53.30
  3  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]   Uptime: 00:10:32
  4  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||100.0%]
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||            3.95G/14.3G]
  Swp[                                                                                      0K/0K]

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
 2552 mysql      20   0 2841M  605M 19228 S 148.  4.1  7:07.68 /usr/sbin/mysqld
 2719 root       20   0  734M 37932  7080 S 80.7  0.3 12:02.78 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b
 3111 root       20   0  734M 37932  7080 R 40.3  0.3  4:24.14 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b
 3113 root       20   0  734M 37932  7080 R 39.7  0.3  4:25.38 /usr/bin/python3 /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b
 5962 mysql      20   0 2841M  605M 19228 R  6.0  4.1  0:11.10 /usr/sbin/mysqld
 8081 mysql      20   0 2841M  605M 19228 S  0.7  4.1  0:11.05 /usr/sbin/mysqld
 9000 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:03.26 /usr/sbin/mysqld
 8621 mysql      20   0 2841M  605M 19228 R  8.6  4.1  0:04.39 /usr/sbin/mysqld
 7056 mysql      20   0 2841M  605M 19228 R  9.9  4.1  0:14.07 /usr/sbin/mysqld
 5311 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:05.72 /usr/sbin/mysqld
 8977 mysql      20   0 2841M  605M 19228 R  6.0  4.1  0:01.94 /usr/sbin/mysqld
 8661 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:05.49 /usr/sbin/mysqld
 7528 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:05.77 /usr/sbin/mysqld
 6229 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:16.25 /usr/sbin/mysqld
 8339 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:06.83 /usr/sbin/mysqld
 8782 mysql      20   0 2841M  605M 19228 R  5.3  4.1  0:04.18 /usr/sbin/mysqld
 8794 mysql      20   0 2841M  605M 19228 R  7.3  4.1  0:04.44 /usr/sbin/mysqld
 8116 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:04.39 /usr/sbin/mysqld
 7004 mysql      20   0 2841M  605M 19228 R  7.9  4.1  0:12.24 /usr/sbin/mysqld
 9345 mysql      20   0 2841M  605M 19228 S  1.3  4.1  0:00.44 /usr/sbin/mysqld
 7068 mysql      20   0 2841M  605M 19228 R  7.3  4.1  0:07.95 /usr/sbin/mysqld
 7218 mysql      20   0 2841M  605M 19228 R  7.9  4.1  0:08.20 /usr/sbin/mysqld
 8683 mysql      20   0 2841M  605M 19228 R  6.6  4.1  0:02.18 /usr/sbin/mysqld
 7432 mysql      20   0 2841M  605M 19228 R  9.3  4.1  0:10.71 /usr/sbin/mysqld
 9236 www-data   20   0  547M 79580 31840 S  3.3  0.5  0:01.17 /usr/sbin/apache2 -k start
 9361 www-data   20   0  544M 72636 27932 S  2.6  0.5  0:00.74 /usr/sbin/apache2 -k start
 9360 admin      20   0  540M 72024 31048 R  4.0  0.5  0:00.80 /usr/sbin/apache2 -k start
 3085 admin      20   0  554M  104M 51608 R  3.3  0.7  0:09.13 /usr/sbin/apache2 -k start
 9358 admin      20   0  481M 79748 23040 S  0.7  0.5  0:00.71 /usr/sbin/apache2 -k start
 9368 www-data   20   0  480M 72268 17064 R  4.0  0.5  0:00.61 /usr/sbin/apache2 -k start
 3633 admin      20   0  555M  100M 46684 S  2.6  0.7  0:05.34 /usr/sbin/apache2 -k start
 9335 admin      20   0  480M 68564 13288 R  2.6  0.5  0:00.65 /usr/sbin/apache2 -k start
 9300 admin      20   0  542M 72000 28852 R  4.0  0.5  0:00.82 /usr/sbin/apache2 -k start
 9339 admin      20   0  546M 68988 21512 S  2.0  0.5  0:00.80 /usr/sbin/apache2 -k start
 8824 www-data   20   0  555M  102M 49068 R  3.3  0.7  0:03.61 /usr/sbin/apache2 -k start
 9370 www-data   20   0  544M 72648 27976 R  3.3  0.5  0:00.62 /usr/sbin/apache2 -k start
F1Help  F2Setup F3SearchF4FilterF5Tree  F6SortByF7Nice -F8Nice +F9Kill  F10Quit

Modération : merci d'utiliser les balises code (explications ici).

Dernière modification par cqfd93 (Le 18/09/2019, à 16:22)

Hors ligne

#2 Le 19/09/2019, à 09:00

bruno

Re : probleme de cpu /usr/bin/python3

Bonjour,

De ce que l'on voit les coupables sont fail2ban et surtout mysqld.
Des commandes tu type :

ps auxfw | grep mysql

peuvent aider à voir le nombres de processus actif et pour chacun le CPU et la RAM utilisés. Après il faut regarder du côté des logs et de la configuration pour savoir pourquoi mysql et fail2ban exigent autant de ressources.

Hors ligne

#3 Le 22/09/2019, à 16:09

tanfast

Re : probleme de cpu /usr/bin/python3

Merci pour ton retour :
$ ps auxfw | grep mysql
mysql     2552 67.7  4.9 2917404 751256 ?      Ssl  Sep21 1052:45 /usr/sbin/mysqld
admin    10656  0.0  0.0  12944  1036 pts/1    S+   14:05   0:00  |       |   \_ grep --color=auto mysql

COmment faire quand le service apache2 tombe tout le temps quasi tous les 1/2h ? j'ai d'autres serveurs assez similaire et qui n'ont pas ce problème. Je te remercie

J'ai trouvé un article qui parle de la CPU par rapport à fail2ban mais pour Plesk et je suis sous Vesta
https://support.plesk.com/hc/en-us/arti … -CPU-usage-

Modération : merci d'utiliser les balises code (explications ici).

Dernière modification par bruno (Le 22/09/2019, à 16:37)

Hors ligne

#4 Le 22/09/2019, à 16:49

bruno

Re : probleme de cpu /usr/bin/python3

Là tu n'est plus qu'à 67,7% d'utilisation CPU avec un seul processus mysqld. C'est déjà plus raisonnable.

Pour les services qui consomment trop de ressources ou s'arrêtent, je ne peux pas t'aider. C'est ton serveur, tu dois avoir les outils de surveillance et les logs qui te permettront d'identifier les sources de problèmes. D'autant que Vesta utilise des dépôts non officiels qui font que ta configuration n'est plus celle d'une Ubuntu standard.

Dans le cas particulier de fail2ban, la taille et le nombre de fichiers de logs à examiner est effectivement un facteur déterminant pour les performance et l'occupation mémoire.

Hors ligne