Description du problème

Il existe un processus dans notre environnement de développement qui consomme particulièrement des ressources. Cela s'est déjà produit plusieurs fois sur site et dans le cloud public. Finalement, ce processus remplira la mémoire de la machine et entraînera des temps d'arrêt. Maintenant, je viens de découvrir ce problème sur place

Idées et méthodes de solutions

La première chose à faire lorsque le processus est plein est de regarder le nom du processus et de vérifier visuellement qu'il est terminé. la première fois que je l'ai vu

top -pH 48297 Jetez un œil au thread du processus spécifique qui a un problème et constatez qu'un seul processus n'a pas de thread

ps Regardez où se trouve le répertoire de ce service

[root@yq01-kg-section1-bud3 libexec]# ps -ef | grep  abrt-hook-ccpp
root     45733 11797  0 12:18 pts/8    00:00:00 grep --color=auto abrt-hook-ccpp
root     48297     2 99 Nov16 ?        15:42:50 /usr/libexec/abrt-hook-ccpp 11 0 8669 0 0 1605530067 e 8669 8669

Aucune idée ! ! J'ai commencé à chercher sur Baidu et j'ai trouvé ce qui suit

abrtd

abrtd est un processus démon qui surveille les crashs d'applications. Lorsqu'un crash se produit, il collectera l'application crash (ligne de commande des fichiers principaux, etc.) et la prendra. mesures en fonction du type Le crash se produit et est basé sur la configuration dans le fichier de configuration abrt.conf. Il existe différentes actions du plug-in : par exemple, bugzilla signale un crash, transfère le rapport via FTP ou report ou scp. consultez la page de manuel du plug-in correspondant.
abrtd : démon de rapport de bug automatique
Lors du débogage d'un programme Linux, le plus pénible est que le programme plante anormalement, mais le fichier core est introuvable, ce qui rend difficile la localisation du problème. Mais avec le fichier core, il est beaucoup plus facile à localiser.

Généralement, vous pouvez définir ulimit -c unlimited dans la variable d'environnement. Mais les responsables de la mise en œuvre sur le terrain oublient parfois de définir cette commande. Alors que faire ? Cela peut être réalisé en configurant le service abrt de Linux.

Modifiez le fichier abrt-action-save-package-data.conf

Modifiez-le pour :

vi /etc/abrt/abrt-action-save-package-data.conf

# With this option set to "yes",
# only crashes in signed packages will be analyzed.
# the list of public keys used to check the signature is
# in the file gpg_keys
#
OpenGPGCheck = no


# Blacklisted packages
#
BlackList = nspluginwrapper, valgrind, strace, mono-core


# Process crashes in executables which do not belong to any package?
#
ProcessUnpackaged = yes


# Blacklisted executable paths (shell patterns)
#
BlackListedPaths = /usr/share/doc/, /example*, /usr/bin/nspluginviewer, /usr/lib/xulrunner-*/plugin-container


还可以调整core文件的大小：

[root@xx-host2 abrt]# cat abrt.conf 
# Enable this if you want abrtd to auto-unpack crashdump tarballs which appear
# in this directory (for example, uploaded via ftp, scp etc).
# Note: you must ensure that whatever directory you specify here exists
# and is writable for abrtd. abrtd will not create it automatically.
#
#WatchCrashdumpArchiveDir = /var/spool/abrt-upload


# Max size for crash storage [MiB] or 0 for unlimited
#
MaxCrashReportsSize = 1000


# Specify where you want to store coredumps and all files which are needed for
# reporting. (default:/var/spool/abrt)
#
# Changing dump location could cause problems with SELinux. See man abrt_selinux(8).
#
#DumpLocation = /var/spool/abrt


# If you want to automatically clean the upload directory you have to tweak the
# selinux policy.
#
DeleteUploaded = no

Redémarrez le service abrtd : service abrtd restart

Si vous avez un fichier principal, vous devez le supprimer à temps. le fichier via le package abrt-cli list, puis utilisez abrt-cli rm [package de fichiers].

Lorsque le programme plante, abrt-hook-ccpp utilise trop de CPU et les E/S sont trop élevées, ce qui provoque la saturation du système. Désactivez-le simplement
systemctl stop abrt-ccpp.service
systemctl désactiver abrt-ccpp.service
. systemctl status abrt-ccpp.service

J'ai vérifié systemctl status abrt-ccpp.service et j'ai constaté que ce service n'est pas démarré du tout

Baidu encore une fois

usr/libexec/abrt-hook-ccpp Pourquoi ce processus continue-t-il d'augmenter ? Parce que ce n'est pas possible. Le

sed -i 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/g' /etc/abrt/abrt-action-save-package-data.conf&& service abrtd restart

Nov 17 13:15:15 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297
Nov 17 13:15:15 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297
Nov 17 13:15:16 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297
Nov 17 13:15:16 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297
Nov 17 13:15:17 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297
Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: abrtd.service stop-sigterm timed out. Killing.
Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: abrtd.service: main process exited, code=killed, status=9/KILL
Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: Unit abrtd.service entered failed state.
Nov 17 13:15:17 yq01-kg-section1-bud3 systemd: abrtd.service failed.
Nov 17 13:15:17 yq01-kg-section1-bud3 abrtd: Lock file '.lock' is locked by process 48297

kill -9 48297

Vérifiez l'état du service

Tutoriel vidéo Linux"