Outils de surveillance des unités d'exécution

Les fichiers Javacore et les piles d'unités d'exécution en particulier sont des outils de débogage clés. La comparaison de piles entre les unités d'exécution, ainsi que pour différents moments dans le temps, peut aider à réduire la cause des ralentissements des performances.

Le délai est un facteur majeur lors du diagnostic des problèmes à l'aide de fichiers Javacores et de Thread dumps. Les Thread dumps doivent être collectés au moment exact où le serveur rencontre des problèmes de performances. Certains événements sont sporadiques et de courte durée, ce qui rend la collecte difficile. Souvent, au moment où un problème est détecté et qu'un vidage manuel est collecté, le problème est passé.

Collecte automatique de Thread dump

L'outil de surveillance des unités d'exécution automatise la collecte de Thread dump. Il offre des options pour le format, la fréquence et le déclenchement des vidages. Il s'intègre à la structure des métriques pour activer la génération de vidage automatique lorsque certains seuils, tels que le nombre d'unités d'exécution utilisées, sont atteints. Avec cette configuration, l'outil Thread Monitor peut déclencher automatiquement la collecte des clichés lors de pics ou de ralentissements.

Le déclencheur, qui est basé sur le nombre d'unités d'exécution utilisées, nécessite que les métriques soient activées dans values.yaml.

L'outil Thread Monitor est configuré avec le fichier YAML suivant, disponible dans les conteneurs Serveur de transactions, QueryApp, Recherche Solr et CRS. Les configurations incluent le format (c'est-à-dire Thread dump ou Javacore), l'archivage et les déclencheurs de seuil.

Pour plus d'informations sur chaque option de configuration, voir le fichier YAML :

/SETUP/support/thread_monitor.yaml

L'outil Thread Monitor est activé par défaut depuis HCL Commerce version 9.1.9.

Il est configuré pour collecter des clichés au format "Thread dump" (un format personnalisé HCL), lorsque le nombre d'unités d'exécution utilisées dans le pool Default Executor/Web Container dépasse une valeur de seuil de 20. Il collectera un maximum de 10 vidages par heure. Ces configurations peuvent être mises à jour pour mieux correspondre au scénario que vous déboguez.

Les modifications apportées à la configuration dans thread_monitor.yaml sont automatiquement chargées lors de l'exécution. Un redémarrage du conteneur n'est pas requis.

Lorsqu'un vidage est collecté en raison du déclencheur de seuil webContainer.inUseLargerThan, l'avertissement suivant est imprimé dans les journaux :

[4/12/22 16:20:43:937 GMT] 00000124 WebContainerI W com.hcl.commerce.monitor.thread.triggers.WebContainerInUseTrigger 
    evaluateWebContainerUsage( final int inUse ) WebContainer threads in use 21 is higher than threshold of 20. Generating threaddump...

L'outil Thread Monitor peut également être activé et désactivé à partir du coffre en configurant la variable d'environnement comme suit :

${TENANT}/${ENVIRONMENT}/${ENVTYPE}/threadMonitorEnable/${component_name}: value=true

Utilitaire ThreadAnalyzer

L'outil Thread Monitor génère des fichiers Javacore ou des Thread dumps dans le répertoire spécifié par la variable d'environnement DUMP_DIR. L'utilitaire ThreadAnalyzer peut être utilisé pour faciliter l'analyse. Cela est particulièrement utile lorsque des dizaines ou des centaines de vidages sont créés. La révision manuelle peut prendre du temps.

L'outil est disponible dans les conteneurs qui activent l'outil Thread Monitor. Son chemin d'accès est le suivant : /SETUP/support/thread-analyzer.jar.

L'utilisation est la suivante :

java -jar thread-analyzer.jar
Use -y when running inside a container
usage: java -jar thread-analyzer.jar [options]
 -c,--config <arg>      Optional path to a Yaml configuration file
 -d,--directory <arg>   Directory or file where the dumps are found. If a
                        file is specified, only that dump is analyzed. If
                        the file is a Zip, all the dumps within the zips
                        are parsed. If the location is a directory, all
                        dumps and zips within the directory will be parsed
                        (this does not include subfolders). When not set,
                        the tool attempts to determine the directory to
                        use automatically. If a directory is not
                        discovered, it defaults to the current directory.
 -f,--follow            If enabled, the tool will continue to monitor for
                        new threaddumps.  This option is ignored if the
                        parameter is a file, not a directory. When -f is
                        set, -t is ignored.
 -h,--help              Prints this help.
 -r,--report <arg>      Comma separated list of reports. Defaults to 'Base
                        Web Activity'.
 -s,--since <arg>       Optional flag to limit the number of threadumps
                        Defaults to 3 hours. See 'time format'.
 -t,--to <arg>          Optional flag to limit the number of threadumps.
                        Defaults to now. See 'time format'.
 -x,--extract-config    Prints default config in stdout. This option is
                        used to customize the config, that can be then
                        specified with the -c option.
 -y,--yes               Required to acknowledge the utility can have an
                        impact when used within the container.

Time format: N[s=seconds, m=minutes, h=hours, d=days] OR yyyy-MM-dd HH:mm
OR epoch (e.g. 1650375222829) OR yyyyMMdd.HHmm[ss]

Available reports:
- Top Web Frames (tw): Reports the stacks most frequently found in threads
- Base Web Activity (ba): Summary of total base activities
- Web Activity (wa): Lists the discovered activity for each tread

Note: AVERTISSEMENT : Lorsqu'il est exécuté dans le conteneur, cet utilitaire prend des ressources de l'UC et de la mémoire. La quantité varie en fonction du nombre de vidages traités. Pour les environnements de production, il est recommandé d'utiliser cet utilitaire en dehors du conteneur. Il est également fortement recommandé d'utiliser -Xmx pour limiter l'utilisation de la mémoire.

Logique d'activité ThreadAnalyzer

L'outil ThreadAnalyzer génère des rapports tels que "Activité Web de base" et "Activité Web" qui s'appuient sur la logique afin de "reconnaître" les activités clés à partir d'une pile. La configuration est généralement basée sur l'application de modèles RegEx aux cadres de pile et à la recherche de certaines classes et méthodes connues.

L'exemple suivant rattache l'activité DB2 à une pile avec des cadres qui incluent le package com.ibm.db2.jcc :

  - activity: DB2
    startsWith: com.ibm.db2.jcc
    consumePrevious: true

La configuration par défaut peut être examinée et étendue.

Utilisez l'argument -x pour imprimer la configuration par défaut à l'écran. La sortie YAML peut être redirigée vers un fichier pour édition :
```
java -jar thread-analyzer.jar  -x -y
```

La configuration personnalisée peut être appliquée à l'aide de l'argument -c :
```
java -jar thread-analyzer.jar -c custom_config.yaml
```

Rapports ThreadAnalyzer

Rapport Activité Web de base

Le rapport "Activité Web de base" récapitule l'activité pour chaque Thread dump ou Javacore. Il inclut l'heure du vidage, le nom du fichier, le nombre total d'unités d'exécution non inactives et les activités de base trouvées. Ce rapport est utile pour obtenir une perspective de haut niveau des zones d'incident et pour identifier les délais, qui affichent généralement les unités d'exécution les plus occupées.

Voici un exemple du rapport Activité Web de base :

2021/10/26 13:10:12 - threaddump.20211026.131012.2913.0007.txt:   3 - SocketRead[DB2]:3
2021/10/26 13:10:42 - threaddump.20211026.131042.2913.0009.txt:  10 - SocketRead[DB2]:10
2021/10/26 13:11:12 - threaddump.20211026.131112.2913.0011.txt:  12 - SocketRead[DB2]:7 CMD(RetrieveCatalogEntryTask):3 DB2[DBQuery]:1 CMD(CheckCatalogEntryEntitlementBySearch):1
2021/10/26 13:11:27 - threaddump.20211026.131127.2913.0012.txt:  15 - CMD(RetrieveCatalogEntryTask):5 CMD(RetrieveContentTask):4 Web:4 CMD(InsertMoreMarketingContentAttachmentReferenceData):2
2021/10/26 13:11:42 - threaddump.20211026.131142.2913.0013.txt:   5 - Web:2 Commit:1 CMD(RetrieveContentTask):1 SocketRead[DB2]:1
2021/10/26 13:12:12 - threaddump.20211026.131212.2913.0015.txt:   2 - DB2[DBQuery]:3
2021/10/26 13:13:27 - threaddump.20211026.131327.2913.0020.txt:   2 - Web:1 SocketRead[DB2]:1
2021/10/26 13:13:42 - threaddump.20211026.131342.2913.0021.txt:   1 - SocketRead[DB2]:1
2021/10/26 13:14:12 - threaddump.20211026.131412.2913.0023.txt:   1 - CMD(RetrieveCatalogEntryTask):1

Rapports Activité Web

Le rapport "Activité Web" affiche des détails au niveau de l'unité d'exécution pour chaque vidage trouvé, y compris l'état de l'unité d'exécution et ses activités.

2021/10/26 13:11:12 - threaddump.20211026.131112.2913.0011.txt:
   WebContainer : 0             RUNNABLE   [SocketRead[DB2], DBUpdate, Web]
   WebContainer : 3             RUNNABLE   [SocketRead[DB2], DBUpdate, Web]
   WebContainer : 9             RUNNABLE   [CMD(RetrieveCatalogEntryTask), CMD(FilterCatalogEntryTask), Web]
   WebContainer : 10            RUNNABLE   [SocketRead[DB2], DBUpdate, Web]
   WebContainer : 11            RUNNABLE   [SocketRead[DB2], DBQuery, CMD(RetrieveContentTask), CMD(FilterContentTask), Web]
   WebContainer : 13            RUNNABLE   [SocketRead[DB2], DBUpdate, Web]
   WebContainer : 16            RUNNABLE   [CMD(RetrieveCatalogEntryTask), CMD(FilterCatalogEntryTask), Web]
   WebContainer : 18            RUNNABLE   [DB2[DBQuery], CMD(RetrieveContentTask), CMD(FilterContentTask), Web]
   WebContainer : 19            RUNNABLE   [CMD(RetrieveCatalogEntryTask), CMD(FilterCatalogEntryTask), Web]
   WebContainer : 20            RUNNABLE   [SocketRead[DB2], DBQuery, CMD(RetrieveContentTask), CMD(FilterContentTask), Web]
   WebContainer : 21            RUNNABLE   [SocketRead[DB2], DBQuery, CMD(RetrieveCatalogEntryTask), CMD(FilterCatalogEntryTask), Web]
   WebContainer : 22            RUNNABLE   [CMD(CheckCatalogEntryEntitlementBySearch), CMD(CatalogFilterGetContractUnitPrice), CMD(ComposePriceForCatalogEntry), CMD(RetrieveCatalogEntryTask), CMD(FilterCatalogEntryTask), Web]

Rapport Cadres Web principaux

Le rapport "Cadres Web principaux" répertorie les cadres de pile les plus fréquents pour tous les vidages trouvés.

87 threaddumps, 98 total threads analyzed
       278 (284%) com.ibm.websphere.command.CacheableCommandImpl.execute(CacheableCommandImpl.java:167)
       244 (249%) com.ibm.commerce.command.MeasuredCacheableCommandImpl.execute(MeasuredCacheableCommandImpl.java:69)
       228 (233%) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
       128 (131%) com.ibm.commerce.foundation.client.facade.bod.AbstractBusinessObjectDocumentFacadeClient.internalSendBusinessObjectDocument(AbstractBusinessObjectDocumentFacadeClient.java:818)
       128 (131%) com.ibm.commerce.foundation.internal.client.services.invocation.InvocationService.invoke(InvocationService.java:113)
       128 (131%) com.ibm.commerce.foundation.internal.client.services.invocation.impl.NoInterfaceEJBInvocationBindingImpl.invoke(NoInterfaceEJBInvocationBindingImpl.java:225)
       128 (131%) com.ibm.commerce.foundation.client.facade.bod.AbstractBusinessObjectDocumentFacadeClient.sendBusinessObjectDocument(AbstractBusinessObjectDocumentFacadeClient.java:529)
       125 (128%) com.ibm.commerce.foundation.server.command.bod.BusinessObjectCommandTargetImpl.executeCommand(BusinessObjectCommandTargetImpl.java:116)
       125 (128%) com.ibm.commerce.foundation.server.command.bod.BusinessObjectDocumentProcessor.processBusinessObjectDocument(BusinessObjectDocumentProcessor.java:276)
       117 (119%) com.ibm.commerce.foundation.internal.server.command.impl.CommandTarget.executeCommand(CommandTarget.java:65)
       109 (111%) com.ibm.commerce.foundation.server.command.bod.AbstractGetBusinessObjectDocumentCmdImpl.performExecute(AbstractGetBusinessObjectDocumentCmdImpl.java:158)
        96 (98%) com.ibm.commerce.marketing.commands.marketingspot.MarketingSpotCommandBaseTaskCmdImpl.execute(MarketingSpotCommandBaseTaskCmdImpl.java:387)

Les pourcentages supérieurs à 100 % signifient que la pile a été trouvée plusieurs fois sur une seule unité d'exécution.

Le rapport autorise les configurations (à l'aide de --extract-config et de --config) comme suit :

report:
  ...
  topWebFrames:
    minPercentage: 5
    excluded:
    - com.ibm.ws.
    - org.springframework.
    - javax.
    - java.
    - org.apache.wink.
    - com.ibm.io.