J'écris une application Linux qui observe d'autres applications et suit la consommation de ressources. Je planifie le travail avec Java, mais la programmation de la programmation n'est pas importante pour moi. L'objectif est important, je peux donc passer à une autre technologie ou utiliser des modules. Ma candidature utilise toute application tierce partie sélectionnée en tant que processus d'enfant. La plupart des logiciels enfants résoutent un algorithme comme des graphiques, la recherche de chaînes, etc. Le programme d'observateur suit les ressources de l'enfant pendant la fin du travail.
Si l'application enfant est multi-filetée, peut-être d'une manière ou d'une autre est possible de suivre combien de ressources consomme chaque fil? L'application pourrait être écrite à l'aide de toute technologie de threads de mémoire distributive à la mémoire de distribution: fils Java, threads de boost, threads POSIX, openmp, tout autre.
3 Réponses :
dans les systèmes Linux modernes (2.6), chaque thread a un identifiant distinct qui a presque le même traitement que le PID. Il est montré dans la table de processus (au moins, dans htop programme) et il a également son chèque Un seul obstacle est d'obtenir ce thread em> identifiant. Il est différent avec l'ID de processus em>! C'est à dire. distinct / proc code> entrée, c'est-à-dire / proc / man code> et payer une attention particulière à code>, statm code>, statut code>, vous devez trouver les informations qui vous intéressent là-bas. p> getpid () code> Les appels dans tous les threads renvoient la même valeur. Pour obtenir l'identifiant de thread réel, vous devez utiliser (dans un programme C): P> pid_t tid = syscall(SYS_gettid);
La mémoire n'est pas attribuée aux threads et souvent partagée sur les threads. Cela rend généralement impossible et au moins de sens à parler de la consommation de mémoire d'un fil.
Un exemple pourrait être un programme avec 11 threads; 1 Création d'objets et 10 en utilisant ces objets. La majeure partie du travail est effectuée sur ces 10 threads, mais toute la mémoire a été allouée sur le thread unique qui a créé les objets. Maintenant, comment un compte pour cela?
Je ne peux pas dire que tu n'es pas raison. Mais nous pouvons supposer que l'utilisation de la mémoire de thread unique est la quantité de mémoire avec laquelle un thread spécifique fonctionne à l'heure actuelle. La plupart des threads verrouillent la mémoire avec des sémophores ou des mutiles tout en fonctionnant avec des données.
Désolé, mais cela n'a toujours pas de sens. La mémoire en lecture seule n'a pas besoin de verrouillage du tout. Lorsqu'un mutex est utilisé, il n'y a pas de moyen raisonnable de déterminer quelle mémoire il protège sans aller au code.
Je ne parle pas de la seule mémoire. Nous pouvons toujours compter la consommation de mémoire de la mémoire. Par exemple, fonctionnant avec un graphique, créant des nœuds pour certains compter, etc. Chaque donnée pourrait être accessible par un thread, créée par lui-même et nettoyée après le travail.
Donc, lorsqu'un fil fonctionnerait avec un nœud, le nœud comptait-il contre la mémoire utilisée? Ou la mémoire de l'ensemble du graphique est-elle comptée vers la mémoire utilisée par le fil? Je ne dis pas qu'il y a des allocations NO spécifiques à un fil. Ce n'est tout simplement pas suffisant. Dans de nombreux programmes du monde réel, vous constaterez probablement que 90% de toute la mémoire allouée à un processus ne peut être comptabilisée de manière unique à aucun de ses threads. Résultat final: le processus utilise 50 Mo, chacun de ses 10 threads "utilise" 1 Mo et 40 Mo est "manquant". Vos résultats ne seront pas de confiance à cause de cela.
Si vous êtes prêt à utiliser Perl, jetez un coup d'œil à cela: SYS-Statistics-Linux
Je l'ai utilisé avec certains des packages graphiques GD pour générer des graphiques d'utilisation des ressources système pour divers processus.
Une chose à surveiller - vous aurez vraiment besoin de lire sur / Proc et de comprendre les jiffes - la dernière fois que je n'ai pas regardé, ils ne sont pas documentés correctement dans les pages de l'homme, vous devez lire probablement la source du noyau:
http://lxr.linux.no/ # Linux + v2.6.18 / Inclure / Linux / Jiffies.h
En outre, rappelez-vous que sous Linux la seule différence entre un thread et un processus est que les threads partagent la mémoire - autre que ceux qu'ils sont identiques dans la façon dont le noyau les implémente.
Avez-vous regardé Oprofile pour inspiration? OPROFILE.SOURCEFORGE.net
Non, c'est mon travail de maîtrise. Peut-être que mon conférencier a regardé :-) Mais le profil a l'air intéressant. THX.