Le module Web ou le serveur d'applications arrête de traiter les demandes
Si un processus de serveur d'applications se ferme spontanément ou si des modules Web arrêtent de répondre aux nouvelles requêtes, il est important que vous déterminiez rapidement pourquoi cet interruption se produit. Vous pouvez employer l'une des techniques suivantes pour déterminer si le problème est un problème de module Web ou un problème d'environnement de serveur d'applications.
- Essayez d'isoler l'incident en installant, si possible, les modules Web sur des serveurs différents.
Contrôlez la structure de répertoires produit du fichier avec un nom tel que javacore[number].txt. Il s'agit d'un fichier de cliché de l'unité d'exécution Java™ créé par la machine virtuelle Java si un processus de serveur d'applications se ferme spontanément.
Si un processus de serveur d'applications se ferme spontanément, vous aurez un vidage système à analyser.
- Utilisez Tivoli Performance Viewer pour déterminer si une des
ressources du serveur d'applications telles que le segment Java ou des connexions à une base de données ont atteint leur capacité maximale. S'il s'agit d'un problème de ressources, rechercher sa cause possible
dans le code d'application :
- Si des connexions à une base de données sont assignées à une requête mais ne sont pas libérées lorsque les requêtes finissent le traitement, assurez-vous que le code d'application effectue une méthode close() sur tous les objets Connexion ouverts dans un bloc finally{}.
- Si le nombre d'unités d'exécution du moteur de servlet utilisées augmente constamment, recherchez d'éventuels cas de blocage dans les blocs de code synchronisés.
- Si la taille d'un segment de la JVM augmente constamment, recherchez dans le code d'application les risques de fuite de mémoire, telles que les collections statiques (de niveau classe) qui peuvent faire que les objets ne sont jamais supprimés par le processus de récupération.
- Activez la récupération de place en mode prolixe sur le serveur d'applications pour vous permettre de
déterminer si vous avez des problèmes de fuite de mémoire. Cette fonction ajoute des déclarations détaillées
sur la quantité de mémoire disponible et occupés au fichier journal d'erreurs JVM. Pour activer la récupération de place en mode prolixe :
Dans la console d'administration, sélectionnez nom_serveur Then, under Server Infrastructure, click , and select Verbose garbage collection.
Dans la console d'administration, sélectionnez nom_serveur Then, in the Server Infrastructure section, click , and select Verbose garbage collection.
- Arrêtez, puis redémarrez le serveur d'applications.
- Recherchez régulièrement des déclarations de récupération de place dans le fichier journal. Recherchez les déclarations commençant par "échec d'attribution". Cette chaîne indique qu'un besoin d'attribution de mémoire a déclenché une récupération de place de la JVM en vue de libérer de l'd'espace mémoire inutilisé. Les échecs d'attribution sont normaux et n'indiquent pas forcément un problème. Cependant, les déclarations suivant la déclaration d'échec d'attribution montrent le nombre d'octets nécessaires et le nombre d'octets attribués. Si ces déclarations de nombre d'octets nécessaires indiquent que la JVM continue de s'attribuer de la mémoire pour son propre usage ou que la JVM ne peut plus s'attribuer la quantité de mémoire dont elle a besoin, il peut y avoir une fuite de mémoire.
Vous pouvez utiliser Tivoli Performance Viewer pour détecter les incidents de fuite de mémoire.
Déterminez si le serveur d'applications est à cours de mémoire. Si vous déterminez que le serveur d'applications est à cours de mémoire, il se peut que vous vous trouviez dans l'une des situations suivantes :
- Fuite de mémoire dans le code de l'application que vous devez traiter. Pour identifier la cause de la fuite de mémoire, activez la propriété RunHProf sur la page Machine virtuelle Java de la console d'administration. nom_serveur correspond
au nom du serveur d'applications qui pose problème. Une fois la propriété RunHProf activée,
vous devez :
- Donnez à la zone Arguments HProf une valeur similaire à depth=20,file=heapdmp.txt. Cette valeur affiche les piles d'exceptions jusqu'à un maximum de 20 niveaux et sauvegarde les sorties de vidage de segment mémoire dans le fichier racine_serveur_applis/bin/heapdmp.txt.
- Sauvegardez les paramètres.
- Arrêtez, puis redémarrez le serveur d'applications.
- Si possible, reproduisez le scénario ou accédez à la ressource qui a provoqué la fermeture spontanée du processus du serveur d'applications ou l'arrêt de ses modules Web lors de leur réponse à de nouvelles demandes. Puis arrêtez le serveur d'applications. Si vous ne pouvez pas reproduire le scénario ou accéder à la ressource, attendez que le problème se reproduise pour arrêter le serveur d'applications.
- Examinez le fichier dans lequel le vidage de segment mémoire a été sauvegardé. Par exemple, examinez le fichier
racine_serveur_applis/bin/heapdmp.txt :
- Recherchez la chaîne "SITES BEGIN". Celle-ci trouve l'emplacement d'une liste d'objets Java en mémoire ce qui permet de voir la quantité de mémoire attribuée à ces objets.
- Cette liste d'objets Java apparaît chaque fois qu'il y a une attribution de mémoire dans la JVM. Le type d'objet instancié par la mémoire est enregistré et un identificateur de pile de traces, répertorié ailleurs dans le cliché, montre la méthode Java qui a réalisé l'attribution.
- La liste des objets Java est classée par ordre décroissant selon le nombre d'octets attribués. Depending on the nature of the leak, the problem class should show up near the beginning of the list, but this is not always the case. Recherchez dans la liste les grandes quantités de mémoire ou les réitérations fréquentes d'instances de la même classe instanciée. Dans ce cas-ci, utilisez l'ID dans la colonne trace stack pour identifier les attributions répétitives dans la même classe et dans le même méthode.
- Examinez le code source indiqué dans les piles de traces associées à la recherche d'éventuelles fuites de mémoire.
- La JVM utilise la taille maximale de segment maximale autorisée. Dans cette situation, vous devez augmenter le paramètre de taille maximale de segment du serveur d'applications si vous disposez de suffisamment de mémoire pour cela.
- L'unité d'exécution du serveur rencontre un problème. Si vous déterminez qu'il s'agit d'un problème avec l'unité d'exécution du serveur, assurez-vous que vous avez appliqué toutes les mises à jour de service du produit. Si, après avoir appliqué toutes les mises à jour de service, l'incident persiste, contactez le support technique IBM®.
- Fuite de mémoire dans le code de l'application que vous devez traiter. Pour identifier la cause de la fuite de mémoire, activez la propriété RunHProf sur la page Machine virtuelle Java de la console d'administration. nom_serveur correspond
au nom du serveur d'applications qui pose problème. Une fois la propriété RunHProf activée,
vous devez :
Parcourez le cliché de l'unité d'exécution à la recherche d'indications :
La JVM crée un cliché de l'unité d'exécution chaque fois qu'un processus de serveur d'applications se ferme spontanément. Vous pouvez également forcer une application à créer un cliché de l'unité d'exécution. Après la création d'un cliché, vous rechercher dans le cliché des indices sur la raison pour laquelle les nouvelles requêtes ne sont pas traitées.
Pour forcer un cliché de l'unité d'exécution :
- A l'aide de l'invite de commande wsadmin, procurez-vous un descripteur du serveur d'applications
défectueux :
wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server_name,*]
où nom_serveur correspond au nom abrégé du serveur.
- Générez le vidage de l'unité d'exécution :
wsadmin>$AdminControl invoke $jvm dumpThreads
Remarque : La commande dumpThreads crée d'autres types de fichier de vidage en fonction des paramètres -Xdumps. La sortie de vidage varie en fonction de la plateforme et peut inclure les fichiers core du système, des clichés de segment de mémoire et des clichés de protocole d'adresse de sous-réseau. Recherchez un fichier de sortie du type javacore.jobnum.jobuser.jobname.timestamp.txt dans le répertoire racine_profil/logs.
Recherchez dans le répertoire racine d'installation un fichier de sortie nommé javacore.date.time.id.txt.
Une fois que l'application a créé le cliché, vous pouvez recherchez les indices suivants :
Chaînes "Erreur" ou "informations sur l'exception" au début du fichier. Ces chaînes indiquent l'unité d'exécution qui a causé la fermeture spontanée du processus de serveur d'applications. Ces chaînes n'existent pas si si vous forcez le cliché.
Recherchez une taille actuelle de segment mémoire excessive. Le cliché de l'unité d'exécution apporte des informations sur la taille du segment mémoire Java actuel et sur les paramètres de taille minimale et maximale du segment mémoire.
Observez l'instantané de chaque unité d'exécution du processus. Le cliché d'unité d'exécution contient un instantané de chaque unité d'exécution du processus, en commençant à la section libellée "Full thread dump" (cliché intégral d'unité d'exécution)".
- Recherchez les unités d'exécution dont la description contient "state:R". Ces unités d'exécution sont opérationnelles lorsque le cliché est forcé ou que le processus est fermé.
- Recherchez la présence de plusieurs unités d'exécution dans le même emplacement source de code d'application Java. Cette multiplicité peut être le signe d'un blocage (plusieurs unités d'exécution en attente sur un moniteur) ou d'une boucle infinie, et peut permettre d'identifier le code d'application qui contient l'erreur.
Observez l'instantané de chaque unité d'exécution du processus. Le cliché d'unité d'exécution contient un instantané de chaque unité d'exécution du processus, en commençant à la section libellée "Thread Information".
- Recherchez des unités d'exécution en attente sur des verrous tenus par d'autres unités d'exécution.
- Recherchez la présence de plusieurs unités d'exécution dans le même emplacement source
de code d'application Java. Cette multiplicité peut être le signe d'un blocage (plusieurs
unités d'exécution en attente sur un moniteur) ou d'une boucle infinie, et peut permettre
d'identifier le code d'application qui contient l'erreur.
Il est normal que pour certains composants de l'exécution du produit certains types d'unités d'exécution figurent dans le même emplacement source de code Java. Ces composants comprennent les conteneurs Web et d'EJB et le pool d'unités d'exécution de l'ORB.
- A l'aide de l'invite de commande wsadmin, procurez-vous un descripteur du serveur d'applications
défectueux :