Lorsque vous profilez une application, la vue Console n'apparaît pas dans la perspective Profilage et consignation par défaut.
Pour ouvrir la vue Console dans la perspective Profilage et consignation, sélectionnez Fenêtre->Afficher la vue->Console.
Pour que stdout apparaisse dans la console, cliquez sur Fenêtre->Préférences->Exécution/Débogage->Console et sélectionnez Afficher lorsque le programme écrit dans le fichier de sortie standard.
Lors de la création d'un fichier source Probekit, l'assistant permet de choisir le codage XML à utiliser. Le codage par défaut est ASCII. Si vous voulez utiliser des caractères non ASCII dans le fichier source de sonde (par exemple, dans les zones Libellé ou Description ou dans le code Java d'un fragment), vous devez choisir un codage UTF-8 et non ASCII.
Pour modifier le codage d'un fichier source de sonde existant, cliquez sur ce fichier à l'aide du bouton droit de la souris et sélectionnez Ouvrir avec -> Editeur de texte. Remplacez le codage dans l'en-tête XML par "UTF-8", puis sauvegardez et fermez le fichier. A l'aide du bouton droit de la souris, cliquez de nouveau sur le fichier et choisissez Ouvrir avec -> Editeur de sonde pour en éditer le contenu.
La fonctionnalité d'analyse des fuites n'est pas disponible pour les programmes utilisateur exécutés sous OS/400® iSeries(TM). Les vidages mémoire optimisés pour Hyades générés sur cette plate-forme sont incomplets et il n'est pas possible de générer des vidages mémoire dans un autre format.
Les performances des outils de profilage sont directement liés à la quantité de données collectée et à la vitesse à laquelle ces données sont transférées dans le plan de travail. A mesure que la quantité de données collectée augmente, l'utilisateur constate une baisse des performances en termes de durée de l'analyse et de mémoire disponible pour les différentes tâches à effectuer. Il existe plusieurs manières permettant à un utilisateur d'améliorer les performances de profilage.
- Pour commencer, il est recommandé de collecter la quantité minimale de données nécessaire pour profiler une partie de fonctionnalité donnée. Pour cela, configurez un filtre plus efficace dans la configuration de lancement du profilage. Dans la boîte de dialogue Exécuter->Profil, sélectionnez l'onglet Profilage. Sélectionnez un jeu de profilage, cliquez sur le bouton Editer, puis sur Suivant > ; la boîte de dialogue Filtre s'affiche. Utilisez un filtre pour n'inclure que ce qui vous intéresse. Vous pourrez toujours modifier le filtre pour inclure d'autres données ou des données supplémentaires lors d'une exécution ultérieure.
- Si vous ne voulez pas profiler le code de démarrage, essayez de désélectionner la case "Commencer automatiquement la surveillance lors du lancement d'une application" de la page Limites de profilage de la boîte de dialogue Exécuter->Profil. Cela devrait permettre de réduire le temps nécessaire à lancer le programme analysé et d'éviter le profilage du code de démarrage. Notez que pour commencer le profilage, vous devez cliquer sur le bouton Lancer la surveillance de la barre d'outils, dans le moniteur de profilage, une fois l'espace de travail affiché.
- Vous pouvez essayer de réacheminer la sortie dans un fichier. Cela permet d'utiliser moins de mémoire dans RAD. Vous pouvez importer ce fichier dans RAD ultérieurement, lorsque le programme n'est utilisé que pour consulter ce fichier de profilage, afin qu'il dispose de davantage de mémoire pour cette tâche. Pour cela, utilisez la boîte de dialogue Exécuter->Profilage, sélectionnez l'onglet Profilage, le sous-onglet Destination et cochez la case "Envoyer les données de profilage dans un fichier" avant de procéder au profilage. Utilisez ensuite la boîte de dialogue Fichier->Importer et sélectionnez le type Fichier de profilage. Notez que vous ne pouvez pas afficher les données lors du profilage si cette option est sélectionnée. Vous devez d'abord les importer, puis les visualiser. Il existe un moyen de réduire encore davantage la quantité de mémoire en n'important qu'un fragment du fichier de profilage dans la boîte de dialogue Importation. L'importation de différents fragments et l'examen de chacun de manière indépendante devrait vous aider.
- Le profilage peut demander une quantité importante de mémoire ; il est donc recommandé d'augmenter la quantité de mémoire virtuelle utilisée par RAD. Pour démarrer RAD avec 512 Mo de mémoire virtuelle (1 Go au maximum), ajoutez la ligne suivante à votre fichier rationalsdp.ini : VMArgs=-Xms512m -Xmx1024m
- Si l'incident survient lors de la collecte des données sur le système cible, vous pouvez essayer d'augmenter la taille des mémoires tampon qu'il utilise pour envoyer les données à RAD. Ajoutez la ligne ci-après au fichier serviceconfig.xml, puis redémarrez l'agent. (La taille de la mémoire tampon passe à 256 Mo). Dans les applications sollicitant considérablement le processeur, l'augmentation de la taille du canal des données peut également aider : <Agent configuration="default" name="Java Profiling Agent" dataChannelSize="256M" type="profiler"/>
Lors de la collecte des données binaires de vidage mémoire optimisées pour Hyades, si vous envoyer les données dans un fichier trcxml en sélectionnant "Envoyer les données de profilage dans un fichier", prenez en compte les points suivants :
Agent Controller doit être exécuté sur l'hôte de déploiement pour accéder aux fichiers de segment de mémoire qui y sont sauvegardés. La première fois que vous exécutez Importer->Fichier de profilage sur le fichier trcxml, l'analyse des fuites et l'affichage des graphiques de références d'objet fonctionnent comme prévu.
Si vous exécutez Importer->Fichier de profilage une seconde fois, l'importation fonctionne, mais les tentatives d'exécution de l'analyse des fuites ou d'affichage d'un graphique de références d'objet risque d'échouer. En effet les fichiers de segment de mémoire requis ne sont peut-être plus disponibles sur l'hôte de déploiement.
En cas d'incident, accédez aux fichiers de segment de mémoire à partir du projet dans lequel vous avez importé le fichier trcxml pour la première fois. Les fichiers de segment de mémoire se trouvent dans le répertoire "leakanalysisheapdir", sous le répertoire du projet.
La taille des vidages mémoire IBM OS/390(SVC) est considérable. Le développement de vidages mémoire de grande taille pour les afficher dans la vue Graphique des références d'objet peut prendre un temps considérable. L'opération peut sembler bloquée. Il se peut que le plan de travail soit toujours en train de développer le vidage mémoire, même si l'indicateur de progression semble être bloqué à 100 %.
L'action de capture des vidages mémoire génère des vidages mémoire optimisés pour Hyades sur l'hôte où l'application cible est déployée. Le répertoire de destination du vidage mémoire est contrôlé par le paramètre LOCAL_AGENT_TEMP_DIR, dans le fichier de configuration serviceconfig.xml d'Agent Controller. Pour plus d'informations sur l'emplacement et la modification de ce fichier, reportez-vous à la rubrique d'aide "Gestion d'Agent Controller", sous "Détection et analyse des incidents d'exécution."
Si le message d'erreur "Expand Heap Dump failed in step: ...Reading file" (Le développement du vidage du segment de la mémoire a échoué à l'étape : ... Lecture du fichier) ou "Leak Analysis failed in step: Creating heap object reference graph" (L'analyse des fuites a échoué à l'étape : Création du graphique des références d'objet de segment de mémoire) est affiché, vérifiez qu'Agent Controller est actif sur l'hôte de déploiement, puis relancez votre commande. Agent Controller vous aide à copier les fichiers de l'hôte de déploiement vers le répertoire des projets du plan de travail.
Si vous rencontrez des difficultés lors de l'analyse des fuites, consultez le fichier journal de l'analyse des fuites.
Lors de cette analyse, des informations de diagnostic sont consignées dans le fichier LeakAnalysis.log. Ce fichier contient la sortie des diverses étapes effectuées lors de l'analyse des fuites et indique si l'exécution de cette analyse a abouti ou échoué.
Le fichier LeakAnalysis.log est enregistré dans le projet de profilage associé aux données du profil. Par exemple, sous Windows, <mon_espacedetravail>\ProfileProject\LeakAnalysis.log.
Des informations supplémentaires peuvent être enregistrées dans le fichier journal à l'aide de la propriété système RADLEAKREGIONDUMP. Ajoutez cette option au fichier rationalsdp.ini :
VMArgs=-DRADLEAKREGIONDUMP=1
Le fichier rationalsdp.ini se trouve dans le répertoire d'installation de Rational Software Architect.
Si votre analyse des fuites échoue et que le message "JVMDUMP006I Processing Dump Event "uncaught", detail "java/lang/OutOfMemoryError"" est affiché dans le fichier LeakAnalysis.log, vous devez augmenter la taille des segments de mémoire du processus d'analyse des fuites.
Pour cela, définissez l'attribut système RADLEAKJVMSIZE de Rational Software Architect. Cet attribut contrôle la taille des segments de mémoire de la JVM disponible lors de l'analyse des fuites.
pour définir RADLEAKJVMSIZE, ajoutez cette option au fichier rationalsdp.ini :
VMArgs=-DRADLEAKJVMSIZE=valeur
valeur correspondant à la nouvelle limite de la taille des segments de mémoire (par exemple, 1024M). La valeur par défaut est 512M. Vous devez indiquer si la taille des segments de mémoire est exprimée en méga-octets ou en giga-octets (M ou G).
Le fichier rationalsdp.ini se trouve dans le répertoire d'installation de Rational Software Architect.
Lors de l'utilisation de la machine JVM classique d'IBM avec la fonction de profilage Analyse des unités d'exécution, la vue Unité d'exécution de la perspective Profilage et consignation n'affiche pas l'état "Attente de verrouillage" pour toutes les unités d'exécution impliquées dans un interblocage. Il manque en effet des informations dans les données collectées. Solution : Utilisez la machine JVM J9 d'IBM en ajoutant -Xj9 dans la zone Arguments VM de la page Arguments de la boîte de dialogue Profil.
Les fichiers source Probekit dont les noms comportent des caractères non ASCII ne sont pas traités correctement. N'utilisez que des caractères ASCII dans les noms des fichiers source Probekit.
N'utilisez pas l'action Probekit->Compile qui apparaît dans le menu contextuel des fichiers *.probe. Au lieu de cela, convertissez le projet contenant le fichier *.probe en un projet Probekit et utilisez le mécanisme de compilation standard. (Pour convertir un projet Java en projet Probekit, utilisez Fichier->Nouveau->Autre, puis choisissez Conversion de projets Java en projets Probekit dans la section Profilage et consignation).
N'utilisez pas de caractères non ASCII dans les modèles des spécifications "cible" de Probekit. Les sondes qui contiennent des caractères non ASCII dans les modèles cible ne sont pas traitées correctement.
N'utilisez pas de caractères non ASCII lors de l'ajout de modèles de méthode pour le "vidage des données d'analyse lorsque..."
Si vous entrez des caractères non ASCII dans les zones de package, de classe ou de méthode de la boîte de dialogue Ajout du modèle de méthode, une erreur d'entrée non valide est affichée et vous ne pouvez pas fermer la boîte de dialogue.
Solution : Utilisez un caractère générique (astérisque) à la place des caractères non ASCII dans vos modèles.
Si un filtre EXCLUDE commençant par un caractère générique (astérisque), tel que "*foo", est utilisé, les vues Statistiques de couverture, Navigateur de couverture et Source annotée n'affichent pas de données. Solution : N'utilisez pas de filtre EXCLUDE.
Pour collecter des données de profilage, Agent Controller doit être exécuté sur la machine à partir de laquelle vous voulez collecter les données. Sur les machines RedHat Linux, Agent Controller requiert le correctif libstdc++.so libstdc++-libc6.2-2.so.3.
La fonctionnalité d'analyse des fuites n'est pas disponible pour les programmes utilisateur exécutant la machine JVM J9 d'IBM.
La machine JVM J9 d'IBM crée des fichiers de segment de mémoire dont les noms sont similaires à heapdump.20041012.093936.2192.dmp lorsque vous définissez la variable d'environnement IBM_HEAPDUMP et envoyez des signaux "kill -3" au processus Java en cours d'exécution. Ces fichiers .dmp doivent faire l'objet d'un traitement ultérieur en exécutant j9extract et jdmpview et en créant des vidages mémoire IBM.
Le format de ces vidages mémoire n'est pas identique au format des vidages mémoire générés par la machine JVM classique d'IBM.
Si vous importez plusieurs ensembles de vidages mémoire avec le même nom de moniteur dans un projet existant, vous risquez de perdre des données si vous sauvegardez ultérieurement le projet ou que vous quittez le plan de travail.
Pour empêcher cela, spécifiez une combinaison Projet/Moniteur unique pour chaque ensemble de segments de mémoire importé.
Si vous démarrez un serveur WAS et que vous vous y connectez, les types de profilage Probekit et Analyse au niveau des lignes ne collectent pas les données des classes déjà chargées dans la machine JVM cible. Solution : Pour collecter les données de ces classes, redémarrez le projet contenant ces classes.
Lors du profilage de vos applications WAS pour l'analyse des fuites sous Linux, les fichiers optheap sont placés dans le répertoire suivant :
Pour WAS 6.0, dans le répertoire runtimes/base_v6/profiles/default du répertoire d'installation de Rational Software Architect
Pour WAS 5.x, dans le répertoire d'installation de Rational Software Architect
Lors du profilage, tous les caractères sur deux octets apparaissent sous la forme ???? dans la vue de la console.
Les paramètres d'environnement local sur l'hôte du plan de travail, l'hôte de déploiement éloigné et l'application cible doivent être identiques lors de la collecte des vidages mémoire optimisés pour Hyades.
Lors d'un profilage pour l'analyse des unités d'exécution avec IBM JVM 1.4.1 ou une version antérieure, la vue Unités d'exécution de la perspective Profilage et consignation n'affiche pas le propriétaire des moniteurs de verrouillage des unités d'exécution car ces données ne sont pas collectées. Solution : Migrez vers IBM JRE 1.4.2.
Lors d'un profilage à distance sous Solaris, un incident de l'environnement JRE de Sun 1.4.x empêche le profilage de certaines combinaisons de fonctionnalités, surtout si le profilage de la mémoire ou l'analyse des unités d'exécution est activé. Le site de Sun décrit cet incident : http://developer.java.sun.com/developer/bugParade/bugs/4614956.html Solution : Utilisez Sun JRE 1.4.2_06 ou une version ultérieure.
Retour au fichier Readme principal