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.

Si un processus de serveur d'applications se ferme spontanément ou si des modules Web exécutés sur le serveur d'applications arrêtent de répondre aux nouvelles requêtes :
  • Essayez d'isoler l'incident en installant, si possible, les modules Web sur des serveurs différents.
  • [AIX Solaris HP-UX Linux Windows]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.
  • [z/OS]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 :
    1. [AIX Solaris HP-UX Linux Windows][IBM i]Dans la console d'administration, sélectionnez Serveurs > Types de serveurs > Serveurs d'applications nom_serveur Then, under Server Infrastructure, click > Java and process management > Process definition > Java virtual machine, and select Verbose garbage collection.
    2. [z/OS]Dans la console d'administration, sélectionnez Serveurs > Types de serveurs > Serveurs d'applications nom_serveur Then, in the Server Infrastructure section, click > Java and process management > Process definition > Java virtual machine, and select Verbose garbage collection.
    3. Arrêtez, puis redémarrez le serveur d'applications.
    4. 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.

    [AIX Solaris HP-UX Linux Windows][IBM i]Vous pouvez utiliser Tivoli Performance Viewer pour détecter les incidents de fuite de mémoire.

  • [AIX Solaris HP-UX Linux Windows]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®.
  • [AIX Solaris HP-UX Linux Windows][IBM i]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 :

    1. 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,*] 

      nom_serveur correspond au nom abrégé du serveur.

    2. 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.
    3. [IBM i]Recherchez un fichier de sortie du type javacore.jobnum.jobuser.jobname.timestamp.txt dans le répertoire racine_profil/logs.
    4. [AIX Solaris HP-UX Linux Windows]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 :

    • [AIX Solaris HP-UX Linux Windows]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é.
    • [IBM i]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.
    • [AIX Solaris HP-UX Linux Windows]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.
    • [IBM i]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.

Le service de support IBM dispose de documents et d'outils qui peuvent vous aider à collecter plus rapidement les informations dont vous avez besoin pour résoudre votre incident. Avant d'ouvrir un rapport d'incident, consultez la page du service de support :

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_appdies
Nom du fichier : rtrb_appdies.html