Sortie de SystemTap 1.3

Posté par  (site web personnel) . Modéré par Xavier Teyssier.
Étiquettes :
13
23
juil.
2010
Linux
Ce 21 juillet, SystemTap est passé en version 1.3.
SystemTap est un outil d'instrumentation de code pour GNU/Linux et ses applications, souvent comparé à DTrace. La version 1.3 marque l'avènement d'une implémentation utilisable de print_ubacktrace() permettant d'obtenir un backtrace (pile d'appel) complet de l'espace utilisateur depuis un événement noyau. Cette amélioration fait partie d'un grand nombre de modifications dans le fonctionnement interne de SystemTap qui ont visé à améliorer ses performances et la qualité des résultats fournis (avec des backtraces plus précis et rapides notamment).

L'actualité SystemTap de ces derniers mois inclut aussi la possibilité d'instrumenter facilement des applications Python et Java dans Fedora 13, ainsi que l'activation de kprobe dans le noyau Debian qui augure la possibilité d'avoir un SystemTap utilisable dans Squeeze.

Aller plus loin

  • # Correction du dredi

    Posté par  (site web personnel) . Évalué à 2.

    SystemTap est un outil d'instrumentation de code pour GNU/Linux et ses applications souvent comparé à DTrace.
    ses applications sont souvent comparées ?
    ses applications, souvent comparées ?

    qui augure une possibilité d'avoir un SystemTap utilisable dans Squeeze.
    la possibilité.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

  • # question

    Posté par  . Évalué à 2.

    Est ce que l'on peut m'expliquer la phrase "instrumentr des applications python"? Je dois avouer que je ne la comprend pas probablement par manque de connaissance :)

    • [^] # Re: question

      Posté par  . Évalué à 5.

      C'est une traduction maladroite, j'aurais plutôt utiliser les verbes tracer ou sonder.
      Pour faire simple, SystemTap permet d'installer des sondes dans l'interpréteur CPython pour pouvoir surveiller les appels de fonctions. SystemTap c'est un outil de profilage dynamique, contrairement à gprof, ça te permet de tracer ton application en temps réel (et avec un impact minimal).
      Tu as des exemples de ce qu'il est possible de faire sur le deuxième lien de la dépêche.

      • [^] # Re: question

        Posté par  . Évalué à 2.

        Je ne sais pas si "instrumenter" est le mot préconisé par l'Académie Française, mais il me semble qu'il est celui employé.

        Il s'agit d'une opération permettant ensuite de tracer. A moins que le traçage ne soit fait à la volée sans instrumentation?

        • [^] # Re: question

          Posté par  . Évalué à 3.

          Dans le cas de SystemTap, le noyau et l'interpréteur te présentent des crochets auxquels tu te branches pour pouvoir tracer ton application, etc ... Dans le cas de SystemTap, tu es "limité" à ce que l'interface te propose (enfin, y a de quoi s'occuper), tu ne peux que "relever" les mesures, mais pas "instrumenter" (c-a-d poser un nouvel instrument de mesure).

          • [^] # Re: question

            Posté par  . Évalué à 3.

            Euh et dans le cas de SystemTap ? ;-)

            Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: question

            Posté par  (site web personnel) . Évalué à 4.

            SystemTap ne te limite pas aux sondes statiques définies par les développeurs. Tu peux très bien poser une sonde à une ligne arbitraire du code. Disons "process("/foo/bar").function("foobar@foo/bar.c:1337") pour la ligne 1337 du fichier foo/bar.c dans la fonction foobar() du programme /foo/bar par exemple. Ou bien "kernel.function("foo").return pour définir une action à exécuter lorsque la fonction noyau foo() retourne.

            Des probes/crochets statiques définis par les développeurs sont aussi disponibles (man -k stapprobes) mais SystemTap n'est pas limitê à cela et il peut très bien être utilisé pour déboguer une application qui n'a pas été prévue pour (tant que tu as les symboles de debug et un noyau incluant krprobe et utrace).

            Par ailleurs, hier j'ai présenté SystemTap à HaxoGreen en rajoutant plus d'exemples d'utilisation de probing userland et d'utilisation de -g (pour modifier ce que le kernel/application fait plutôt que de juste observer): http://people.redhat.com/~akunysz/systemtap-haxogreen-201007(...)

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: question

              Posté par  . Évalué à 2.

              > Par ailleurs, hier j'ai présenté SystemTap à HaxoGreen en rajoutant plus d'exemples
              > d'utilisation de probing userland et d'utilisation de -g (pour modifier ce que le
              > kernel/application fait plutôt que de juste observer): http://people.redhat.com/~akunysz
              /systemtap-haxogreen-201007(...)


              Sympa. Dommage qu'il manque un petit comparatif vite fait avec ftrace, lttng ou perf. Juste pour
              dire qu'ils font pas du tout les mêmes trucs. Mais je chipote.

              En tout cas l'équipe de Systemtap alloue beaucoup d'effort pour faire rentrer uprobes (les hooks userspace) dans la branche principale du noyau. Du coup, ya des chances que ça soit mergé avant la fin de l'année prochaine. Voire même encore avant.

              • [^] # Re: question

                Posté par  (site web personnel) . Évalué à 2.

                Rajouter un slide sur perf est dans ma todo list. Je connais juste pas du tout et il faudrait que je me documente. Pareil pour ftrace et lttng sauf que c'était pas sur la TODO jusqu'à maintenant. Merci.

                pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.