Performances mémoire
Les problèmes de performances sont généralement liés à la consommation de mémoire globale des applications ThingWorx. Si votre application utilise le segment de mémoire Java de manière agressive et crée et se débarrasse constamment de gros objets mémoire, vous observez des indicateurs de performance médiocres dans les mesures portant sur la mémoire pour ce système. La fréquence et la durée des garbage collections Java jouent un rôle significatif dans le temps de réponse global du système. En cas de boucle continue de garbage collections, l'application se trouve en manque de mémoire, avec le risque que votre plate-forme ThingWorx dans sa globalité ne soit plus en capacité de répondre.
Pour surveiller au fil du temps la consommation de mémoire Java et les garbage collections, il est recommandé d'activer la journalisation GC. Des outils tels que PSM ou VisualVM fournissent également des informations sur les consommations de mémoire. Toutefois, si la JVM ne répond pas en raison d'un problème de GC complets en boucle, ces applications externes risquent de ne pas pouvoir récupérer les données voulues pour mettre en lumière les problèmes de mémoire.
Notez que lorsque vous surveillez la mémoire au niveau du système d'exploitation, aucune information ne vous est fournie sur la façon dont votre application ThingWorx utilise la mémoire qui lui est allouée. L'outil de surveillance extrait des données sur la quantité de mémoire demandée par Java au système d'exploitation, mais ne montre pas comment Java utilise la mémoire. La plupart des problèmes de performances sont dus à la consommation interne de mémoire dans le segment de mémoire Java, et non aux allocations de mémoire du système d'exploitation.
La mémoire globale allouée à Java est déterminée par les paramètres -Xms (minimum) et -Xmx (maximum) qui sont chargés à l'exécution. Les paramètres -Xms et -Xmx spécifient la taille initiale et maximale du pool de mémoire, si Tomcat est configuré à l'aide du panneau de configuration tomcat8w.
Si aucune valeur minimale ou maximale n'est spécifiée au démarrage, le processus Java au démarrage utilise une heuristique pour préallouer ces quantités de mémoire. Par défaut, Java tente d'allouer un quart de la RAM totale disponible dans le système d'exploitation.
Opérations provoquant des problèmes de mémoire
Vous devez surveiller les opérations suivantes susceptibles de provoquer des problèmes de mémoire :
• Opérations de GC complet très longues et fréquentes (d'une durée de 45 secondes et plus) : les GC complets sont particulièrement indésirables dans la mesure où il s'agit d'opérations "stop-the-world". Plus le temps d'arrêt de la JVM est long, plus il survient des problèmes de mémoire.
◦ Tandis que la JVM s'efforce de libérer de la mémoire, tous les autres threads actifs sont interrompus.
◦ Les GC complets prennent beaucoup de temps, parfois plusieurs minutes, temps pendant lequel l'application peut se retrouver dans l'incapacité de répondre.
• GC complets en boucle : une succession rapide de GC complets est appelée "boucle de GC complets". De telles boucles peuvent provoquer les problèmes suivants :
◦ Si la JVM ne parvient pas à libérer de la mémoire supplémentaire, la boucle peut se poursuivre indéfiniment.
◦ L'application ThingWorx n'est pas disponible pour les utilisateurs tant que dure la boucle.
• Fuites de mémoire : des fuites de mémoire surviennent dans l'application lorsqu'un nombre croissant d'objets sont conservés en mémoire. Ces objets ne peuvent pas être nettoyés, quel que soit le type de garbage collection effectué par la JVM.
◦ Lorsque vous contrôlez la consommation de mémoire dans le temps, une fuite de mémoire se manifeste sous la forme d'une consommation sans cesse croissante qui n'a jamais été récupérée.
◦ Le serveur finit par se retrouver à court de mémoire, quelles que soient les limites supérieures définies.