Version du 21 septembre 2018 à 17:17

Présentation générale

Contexte

Un système temps réel est un système informatique chargé de contrôler un dispositif physique dans son environnement, et ce à une vitesse adaptée à la vitesse d'évolution du dispositif. La spécificité principale d'un tel système est qu'il est aussi important de calculer le bon résultat que de le calculer au bon moment. Par exemple, dans le système de contrôle de vol d'un avion, il est essentiel que les calculs soient effectués suffisamment rapidement pour permettre une réaction à des perturbations extérieures (par exemple une bourrasque de vent) dans un laps de temps assurant la stabilité de l'avion. Les systèmes temps réel sont désormais présents dans de nombreux secteurs d'activités, tels que l'aéronautique, les centrales nucléaires, les chaînes de production d'usines ou encore la robotique mobile.

Problématique

Un système temps réel est en général programmé sous la forme d'un ensemble de tâches exécutées de manière concurrente. Le comportement d'un tel système dépend non seulement du code de chaque tâche, mais aussi de leurs interactions et des dates auxquelles elles sont exécutées. Le débuggage d'un tel système nécessite de pouvoir étudier en détail ces interactions et ces dates d'exécution.

Objectifs

Ce projet s'inscrit dans le cadre d'un projet de recherche à l'IRCICA. L'objectif est de mettre au point un outil de traces d'exécution, et de statistiques basées sur ces traces, pour l'aide au débuggage d'un système temps réel. L'exécution du système temps réel en question est basée sur l'API ptask, une sur-couche temps réel aux pthreads POSIX. L'outil de trace s'appuiera sur le mécanisme de traces lttng pour Linux. A l'aide du mécanisme de trace développé, on souhaite pouvoir obtenir des informations sur les préemptions subies par chaque tâche, le temps passé à exécuter chaque tâche, le nombre d'échéances manquées, etc.

Préparation du projet

Cahier des charges

Le projet consiste en deux étapes. Tout d'abord, il faudra étudier les mécanismes de trace lttng existants dans le noyau Linux (il n'est pas demandé d'étudier le code du noyau, juste les informations déjà fournies par lttng), ainsi que le code de l'API ptask, afin de déterminer le code d'instrumentation à ajouter à l'API ptask pour obtenir les traces voulues. Ensuite, il faudra développer un outil permettant d'exploiter les traces obtenues pour en extraire les informations décrivant le comportement temps réel (préemptions, temps d'exécution, etc).

Choix techniques : matériel et logiciel

Les outils nécessaire à la réalisation du projet sont :

• L'outils de traces d'exécutions du kernel Linux, des applications utilisateur, et bibliothèques LTTng.
• L'API ptask basée sur pthreads qui permet de gérer des taches temps réel périodique.

Liste des tâches à effectuer

• Se documenter sur l'outils de traces LTTng.
• Presenter l'outil à l'équipe de recherche.
• Se documenter sur l'API ptask.
• Savoir à quel point l'outils de trace peut être exploiter.
• Implémenter l'API avec l'outil de trace.
• Améliorer et optimiser les résultat du traçage.

Calendrier prévisionnel

Réalisation du Projet

Semaine 1

Les tâches effectuées durant la première semaine étaient sous forme de cherche et de documentation sur les traces d'executions sur Linux, et sur les outils de traces utilisés et leurs fonctionnement. Cette semaine à surtout servie à la compréhension du sujet, et à l'établissement d'un cahier de charges.

Outil de trace LTTng :

Introduction au Kernel Tracing et Profiling :

Le profilage du kernel sert à détecter ce qu'on appelle les "bottlenecks" de performance, -des points d'un système limitant les performances globales, et pouvant avoir un effet sur les temps de traitement et de réponse. Les bottlenecks peuvent être matériels et/ou logiciels-. Le profilage nous aide à déterminer où exactement dans un programme nous perdons de la performance. Les programmes spéciaux génèrent un profil -un résumé d'events- qui peut être utilisé pour déterminer quelles fonctions ont pris le plus de temps à exécuter. Ces programmes, cependant, n'aident pas à déterminer pourquoi le rendement a chuté.

Le traçage est le processus de collecte d'informations sur l'activité dans un système fonctionnel. Cela se fait à l'aide d'outils spéciaux qui enregistrent les événements du système, un peu comme la façon dont un magnétophone enregistre le son ambiant. Les programmes de traçage peuvent tracer simultanément les événements au niveau de l'application et de l'OS. L'information qu'ils recueillent peut être utile pour diagnostiquer de multiples problèmes de système.

Le traçage est parfois comparé au logging. Il y a certainement des similitudes entre les deux, mais il y a aussi des différences. Avec le traçage, des informations sont écrites sur les événements de bas niveau. Ils se comptent par centaines, voire par milliers. Avec le logging, des informations sont écrites sur les événements de niveau supérieur, qui sont beaucoup moins fréquents. Il s'agit notamment des utilisateurs qui se connectent au système, des erreurs d'application, des transactions dans la base de données, etc.

Tout comme les journaux, les données de traçage peuvent être lues telles quelles ; cependant, il est plus utile d'extraire des informations sur des applications spécifiques. Tous les programmes de traçage en sont capables. Le noyau Linux possède trois mécanismes principaux pour le traçage et le profilage du noyau :

• tracepoints - un mécanisme qui fonctionne sur le code statique instrumenté.
• kprobes - un mécanisme de traçage dynamique utilisé pour interrompre le code d'un noyau à n'importe quel moment, appeler son propre gestionnaire, et revenir après que toutes les opérations nécessaires ont été effectuées.
• perf_events - une interface pour accéder à la PMU (Performance Monitoring Unit).

Introduction à LTTng :

Le traceur kernel "Linux Trace Toolkit : new generation" est un logiciel "toolkit" open source qui peut être utiliser pour tracer simultanément le noyau Linux, les applications utilisateur et les bibliothèques utilisateur. LTTng se compose de :

• Modules du noyau pour tracer le noyau Linux.
• Bibliothèques partagées pour tracer les applications utilisateur écrites en C ou C++.
• Packages Java pour tracer les applications Java qui utilisent java.util.logging ou Apache log4j 1.2.
• Un package Python pour tracer les applications Python qui utilisent le package de logging standard.
• Un module noyau pour tracer les scripts shell et autres applications utilisateur sans mécanisme d'instrumentation dédié.
• Daemons et un outil en ligne de commande, lttng, pour contrôler les traceurs LTTng.

Entre autre, il peut effectuer les tâches suivantes :

• Analyser les interactions interprocessus dans le système.
• Analyser les interactions application-kernel dans l'espace utilisateur.
• Mesurer le temps que le noyau passe à répondre aux demandes d'application.
• Analyser le fonctionnement du système sous des charges de travail élevées.

L'histoire du logiciel a progressé et a conduit à ce qu'on tiens maintenant pour acquis -des applications logicielles complexes, nombreuses et interdépendantes fonctionnant en parallèle sur des systèmes d'exploitation sophistiqués comme Linux- les auteurs de tels composants, les développeurs de logiciels, ont commencé à ressentir le besoin naturel de disposer des outils qui assureraient la solidité et la bonne performance de leurs chefs-d'oeuvre. LTTng a longtemps été inclus dans la plupart des dépôts Linux officiels. Il est utilisé par des entreprises comme Google, Siemens et Boeing.

Historique :

En 1999, un employé d'IBM, "Karim Yaghmour", a commencé à travailler sur LTT (Linux Trace Toolkit). LTT a été construit sur l'idée suivante : instrumenter statiquement les fragments les plus importants du code du noyau et ainsi récupérer efficacement les informations sur les performances du système. Quelques années plus tard, cette idée a été reprise et développée par "Matthew Donahue" dans le cadre du projet LTTng (Linux Tracing Tool New Generation). LTTng a été publié pour la première fois en 2005.

Il y a une raison pour laquelle le titre du projet inclut le terme Nouvelle Génération : Donahue a beaucoup investi dans le développement des mécanismes de traçage et de profilage de Linux. Il a ajouté l'instrumentation statique pour les fonctions les plus importantes du noyau ; c'est ainsi que nous avons obtenu le mécanisme des marqueurs du noyau, dont l'amélioration a conduit au développement des points de trace. LTTng utilise activement les points de trace. C'est grâce à ce mécanisme qu'il est possible de tracer sans augmenter la charge du système. En 2009, Donahue a soutenu sa thèse sur le travail accompli.

Alternatives à LTTng :

En excluant les solutions propriétaires, il existe quelques traceurs logiciels concurrents pour Linux :

• dtrace4linux est un portage de DTrace vers Linux de Sun Microsystems. L'outil dtrace interprète les scripts utilisateur et est responsable du chargement du code dans le noyau Linux pour une exécution ultérieure et la collecte des données de sortie.
• ftrace est le traceur de fonction facto du noyau Linux. Son interface utilisateur est un ensemble de fichiers spéciaux dans sysfs.
• perf est un outil d'analyse des performances pour Linux qui prend en charge les compteurs de performances matérielles, les tracepoints, ainsi que d'autres compteurs et types de sondes. L'utilitaire de contrôle de perf est l'outil perf en ligne de commande.
• strace est un utilitaire en ligne de commande qui enregistre les appels système effectués par un processus utilisateur, ainsi que les signaux système et les changements d'état du processus. strace utilise ptrace pour remplir sa fonction.

La principale particularité de LTTng est qu'il produit des traces corrélées du noyau et de l'espace utilisateur, tout en réduisant au minimum les frais généraux parmi d'autres solutions. Il produit des fichiers de traces au format CTF, un format de fichier optimisé pour la production et l'analyse de données multi-gigaoctets. L'interface principale pour le contrôle de traçage est un outil en ligne de commande unique nommé lttng. Ce dernier peut créer plusieurs sessions de traçage, activer et désactiver les événements à la volée, filtrer efficacement les événements avec des expressions utilisateur personnalisées, démarrer et arrêter le traçage, et bien plus encore. LTTng peut enregistrer les traces sur le système de fichiers ou les envoyer sur le réseau, et les conserver totalement ou partiellement. Vous pouvez visualiser les traces une fois que le traçage devient inactif ou en temps réel.

Installation :

LTTng est un ensemble de composants logiciels qui interagissent pour instrumenter le noyau Linux et les applications utilisateur, et pour contrôler le traçage (démarrer et arrêter le traçage, activer et désactiver les règles d'événements, et le reste). Ces composants sont regroupés dans les packages suivants :

• LTTng-tool : Bibliothèques et interface en ligne de commande pour contrôler le traçage.
• LTTng-modules : Modules du noyau Linux pour instrumenter et tracer le noyau.
• LTTng-UST : Bibliothèques et paquets Java/Python pour instrumenter et tracer les applications utilisateur.

Pour installer LTTng, se referer à la documentation LTTng.

Conceptes de bases :

Du point de vue de l'utilisateur, le système LTTng est construit sur quelques concepts, ou objets, sur lesquels lttng command-line tool fonctionne en envoyant des commandes à la session deamon. Comprendre comment ces objets sont liés les uns aux autres est essentiel pour maîtriser l'outil. Les concepts de base sont :

1. Session de trace

Une session de traçage est un dialogue dynamique entre l'utilisateur et la session deamon. La commande lttng create permet de créer une session de traçage, et chaque session a :

• son propre nom.
• ses propre fichiers de trace.
• son propre état d'activité (démarré ou arrêté).
• son propre mode (local, streaming réseau, snapshot ou en direct).
• ses propres channels qui ont leurs propres règles d'événements.

Ces attributs et objets sont complètement isolés entre les différentes sessions de traçabilité.

Une session de traçage est analogue à une session de guichet automatique : les opérations qu'on effectue sur le système bancaire via le guichet automatique ne modifient pas les données des autres utilisateurs du même système. Dans le cas d'un distributeur automatique de billets, une session dure aussi longtemps que la carte bancaire est à l'intérieur. Dans le cas de LTTng, une session de traçage dure de la commande lttng create à la commande lttng destroy.

LTTng peut envoyer les données de trace générées à différents endroits. Le mode session de traçage dicte où l'envoyer. Les modes suivants sont disponibles dans LTTng 2.10 :

• Mode local : LTTng écrit les traces dans le système de fichiers de la machine tracée (système cible).
• Mode streaming réseau : LTTng envoie les traces sur le réseau à un démon relais fonctionnant sur un système distant.
• Mode snapshot : LTTng n'écrit pas les traces par défaut. Au lieu de cela, LTTng peut prendre un snapshot, c'est-à-dire une copie des tampons de traçage actuels, et de l'écrire dans le système de fichiers de la cible ou de l'envoyer sur le réseau à un démon de relais fonctionnant sur un système distant.
• Mode temps réel : Ce mode est similaire au mode de diffusion en continu sur le réseau, mais un visualiseur de trace en direct peut se connecter au démon relais distant pour visualiser les enregistrements d'événements lorsque LTTng les génère par les traceurs.

2. Domain de trace.

Un domain de traçage est un espace pour les sources d'événements. Un domaine de traçage a ses propres propriétés et caractéristiques. Il y a actuellement cinq domaines de traçage disponibles :

• noyau Linux
• espace utilisateur
• java.util.logging (JUL)
• log4j
• Python

On peut spécifier un domaine de traçage lors de l'utilisation de certaines commandes pour éviter toute ambiguïté. Par exemple, puisque tous les domaines supportent les tracepoints nommés comme sources d'événements (points d'instrumentation que vous insérez manuellement dans le code source), vous devez spécifier un domaine de traçage lors de la création d'une règle d'événement car tous les domaines de traçage peuvent avoir des tracepoints avec les mêmes noms.

Il est également possible de créer des canaux dans les domaines de traçage du noyau Linux et de l'espace utilisateur. Les autres domaines de traçage ont un seul canal par défaut.

3. Channel et ring buffer.

Un channel est un objet responsable d'un ensemble de buffers circulaires. Chaque buffer circulaire est divisé en plusieurs sous-buffers. Lorsqu'un traceur LTTng émet un événement, il peut l'enregistrer dans un ou plusieurs sous-buffers. Les attributs d'un channel déterminent ce qu'il faut faire lorsqu'il n'y a plus de place pour un nouvel enregistrement d'événement parce que tous les sous-buffers sont pleins.

Un channel est toujours associé à un domaine de traçage. Et possède également des règles d'événement.

Un channel possède au moins un buffer circulaire par CPU. LTTng enregistre toujours un événement dans le buffer circulaire associé au CPU sur laquelle il s'est produit. Deux schémas de mise en mémoire buffer sont disponibles lorsque un channel est créé dans le domaine de traçage de l'espace utilisateur :

• Mise en mémoire par utilisateur : affectez un jeu de buffers circulaires -un par processeur- partagé par tous les processus instrumentés de chaque utilisateur Unix.
• Mise en mémoire par processus : affectez un jeu de buffers circulaires - un par processeur - à chaque processus instrumenté.

Le domaine de traçage du noyau Linux n'a qu'un seul schéma de tamponnage disponible qui consiste à allouer un seul jeu de buffer circulaires pour l'ensemble du système. Ce schéma est similaire à l'option par utilisateur, mais avec un seul utilisateur global qui exécute le noyau.

Lorsqu'un événement se produit, LTTng l'enregistre dans un sous-buffer spécifique du buffer circulaire d'un channel spécifique. Quand il n'y a plus de place dans un sous-buffer, le traceur le marque comme consommable et un autre sous-buffer vide commence à recevoir les enregistrements d'événements suivants. Un deamon consommateur finit par consommer le sous-buffer marqué. Par défaut, les modules LTTng et LTTng-UST sont des traceurs non bloquants : lorsqu'aucun sous-buffer vide n'est disponible, il est acceptable de perdre des enregistrements d'événements alors que l'alternative serait de causer des retards importants dans l'exécution de l'application instrumentée. Mais à partir de LTTng 2.10, le traceur d'espace utilisateur LTTng, LTTng-UST, supporte un mode de blocage. Ce qui veut dire que lorsqu'il s'agit de perdre des enregistrements d'événements parce qu'aucun sous-buffer vide n'est disponible, ou parce que le délai de blocage est atteint, le mode de perte d'événement du channel détermine ce qu'il faut faire. Les modes de perte d'événement disponibles sont :

• Mode discard : lâchez les enregistrements d'événements les plus récents jusqu'à ce que le traceur libère un sous-buffer. (c'est le seul mode disponible lorsque un délai de blocage est spécifié.)
• Mode overwrite : effacez le sous-buffers contenant les enregistrements d'événements les plus anciens et commencez à y écrire les enregistrements d'événements les plus récents.

Lorsque un channel est créé, le nombre de sous-buffers et leur taille peut être définit. La temporisation de commutation est aussi un attribut configurable important d'un channel. A l'expiration de la temporisation de commutation, un changement de sous-buffer' se produit.

4. Points d'instrumentation, règles d' event, event, enregistrement d' event.

Semaine 2

Documents Rendus

Sources

Le 19/09/2018 :

• Introduction à outil de trace LTTng.
• Introduction à outil de trace ftrace.
• Documentation officiel LTTng.
• Definition bottleneck.

pas encore :

• Documentation kernel tracepoint.
• Documentation kernel event.
• Thèse Mathieu Desnoyers: Low-impact operating system tracing.