Méthode de débogage parfaite et gestion de la surveillance

Méthode de débogage (méthode de débogage parfaite et gestion de la surveillance)
1. Gestion de la surveillance (processus de surveillance)
1. La détection de

la mémoire détecte la mémoire toutes les 10 secondes. Si la mémoire disponible est inférieure à 15%, libérez le cache système, améliorez l'utilisation de la mémoire et enregistrez Journal.
Utilisez sysinfo pour obtenir la taille de la mémoire ou une commande gratuite pour obtenir

struct sysinfo s_info;
sysinfo(&s_info);

Libération du cache système

nret = system("sync;sync");//先同步,防止数据丢失
nret = system("echo 3 > /proc/sys/vm/drop_caches");
nret = system("echo 1 > /proc/sys/vm/overcommit_memory");
nret = system("free");

2. Détection
du processeur Vérifiez l'état du processeur toutes les 10 minutes et constatez qu'il dépasse 80% pendant 3 fois consécutives
. La formule de calcul du journal du processeur est d'
abord obtenue à partir de / proc / stat au moment t1 de l'utilisateur système global, nice, system, idle, iowait, irq , La valeur de softirq, obtenir le temps CPU total depuis le démarrage (indiqué comme total1) et le temps total d'inactivité du processeur depuis le démarrage (indiqué comme idle1) à ce moment.
Deuxièmement, obtenez le temps CPU total depuis le démarrage (indiqué par total2) et le temps total d'inactivité du processeur depuis le démarrage (noté idle2) du système à t2 à partir de / proc / stat. (La méthode est la même que celle de l'étape précédente)
Enfin, calculez l'utilisation totale du processeur du système entre t2 et t1. C'est-à-dire:
pourcentage du processeur entre t1 et t2 = ((total2-total1) - (idle2-idle1)) / (total2-total1) * 100%

3. Détectez si le thread spécifié existe

ps -T|grep thread_name|grep -v grep|grep app$|wc -l

thread_name est le nom du thread spécifié, et le résultat est le nombre de thread thread_name calculé dans le processus de l'application. S'il est 1, cela signifie qu'il existe, sinon, il n'existe pas.

4. Le
processus de surveillance de l'état de thread bloqué ou la commutation de thread est divisé en commutation volontaire (volontaire) et commutation forcée (involontaire). Si le nombre de fois de leur commutation reste le même, cela signifie que le processus ou le thread est bloqué, afin de détecter si le thread est bloqué. .

pid est le pid du processus. La commande suivante peut afficher tous les noms de threads du processus, le pid du thread, le nombre de commutations volontaires et le nombre de commutations forcées.

for file in /proc/pid/task/* ;do oneline=`grep -w -E 'Name|Pid|voluntary_ctxt_switches|nonvoluntary_ctxt_switches' $file/status` ;echo $oneline|awk '{print $2,$4,$6,$8}';done

De plus, si la commutation volontaire d'un processus est majoritaire, cela signifie que sa demande de ressources CPU n'est pas élevée. Si la commutation forcée d'un processus représente la majorité, cela signifie que les ressources du processeur peuvent être un goulot d'étranglement pour celui-ci. Ici, il est nécessaire d'exclure que le processus appelle fréquemment sched_yield () pour provoquer une commutation forcée.

5. La détection liée au service,
telle que le service IPC, peut détecter si l'interruption vi et la fréquence d'images venc sont normales

2. Méthode de débogage parfaite
1. Description de fond
Un projet complet aura plus ou moins quelques bogues, et certains bogues sont implicites, certains sont de faible probabilité et ne sont pas faciles à découvrir, les mesures préventives sont donc très importantes . Les bogues courants dans les programmes incluent les pannes de programme probabilistes ou les erreurs de segmentation, les blocages de programme, les fuites de mémoire et les fuites de descripteurs de fichiers.
(1) Plantage du programme probabiliste ou enquête sur les défauts de segmentation
Positionnement de la coredump

trace de pile

Traçage croisé de la pile

Débogage de l'outil GDB

Ce qui précède présente quatre méthodes pour traiter les défauts de segmentation. L'outil gdb est le meilleur outil de débogage des défauts de segmentation. Il contient des informations d'impression complètes, mais il ne convient que pour l'étape de débogage, pas pour l'étape de publication. La trace arrière de la pile convient à l'étape de débogage et de libération, mais les informations d'impression sont pires que gdb et le numéro de ligne ne peut pas être imprimé. Cela ne s'applique pas lorsque la mémoire et le flash sont très petits. Le backtrace cross-stack est fondamentalement le même que le backtrace de pile. Il est meilleur que le backtrace de pile en ce qu'il peut être appliqué à des programmes avec une mémoire flash et une mémoire relativement petites, et le numéro de ligne ne peut pas être imprimé.
(2) Prévention des fuites de mémoire et des fuites de descripteurs de fichiers
En développement, malloc et free sont souvent utilisés pour allouer et libérer de la mémoire de tas, ouvrir, fermer ou fopen, fclose sont utilisés pour ouvrir et fermer des fichiers, et les sockets et ferme sont utilisés pour créer et fermer des sockets. etc.
lorsque ces utilisations non appariées, peuvent provoquer des problèmes de fuites de mémoire, ce qui peut entraîner le redémarrage de l'appareil ou un phénomène anormal de panne.
Ici, nous pouvons utiliser la méthode d'encapsulation secondaire pour éviter les fuites de mémoire. Prenez malloc et free comme exemples. La principale performance est d'enregistrer le nombre de fois où malloc et free sont appelés à différents endroits pour déterminer si malloc et free sont appariés. S'ils ne sont pas appariés, vous pouvez Aidez à localiser quel endroit n'est pas jumelé à utiliser, afin d'obtenir l'effet de l'emplacement de fuite de mémoire.
Prévention des fuites de mémoire et des fuites de descripteurs de fichiers

(3) Dépannage du blocage dans le programme. Si un
processus ou un thread est bloqué, il restera bloqué. Comme mentionné précédemment, l'état bloqué du thread peut être surveillé pour déterminer quel thread est bloqué et où il est bloqué. Vous pouvez basculer vers le thread correspondant en déboguant GDB en ligne. Si vous imprimez ensuite les informations de pile, vous pouvez localiser le thread bloqué. position de s.
Débogage de l'outil GDB

3. Gestion standardisée des
informations de débogage Il existe généralement deux types d'informations de débogage, l'une est contrôlable et l'autre incontrôlable. Les informations de débogage incontrôlables sont généralement utilisées dans la phase de débogage, comme printf, qui est directement imprimée. Les informations de débogage contrôlables sont généralement utilisées dans la phase de maintenance. Un commutateur est utilisé pour contrôler si les informations doivent être imprimées, afin d'éviter que toutes les informations de débogage ne soient imprimées, ce qui entraîne des problèmes de visualisation inchangée et une sélection difficile des informations clés.
1. L'impression des informations de débogage doit être pratique et le
package printf détaillé peut ajouter le nom de fichier, le nom de la fonction et le numéro de ligne correspondants pour faciliter le débogage et le positionnement.

#define DH(fmt, args...)  
printf("%s-%s-%d:" fmt,  __FILE__,__FUNCTION__,__LINE__, ## args)

2. Divisez et contrôlez les informations d'impression en fonction des modules. Les informations de débogage de chaque module n'affectent pas
le contrôle des informations de débogage. Il existe deux façons de contrôler les informations de débogage. L'une est le contrôle général et le contrôle général contrôle l'impression des informations de tous les modules. L'autre est le contrôle du module, chaque module a son propre commutateur de contrôle pour les informations de débogage.

3. Les informations de débogage importantes doivent être enregistrées sur le disque, telles que le journal de redémarrage, le journal des erreurs, le journal des rappels, etc.

Je suppose que tu aimes

Origine blog.csdn.net/weixin_40732273/article/details/109261376
conseillé
Classement