Optimisation des machines virtuelles Java

Vous devez prendre en compte plusieurs aspects spécifiques de l'optimisation des machines virtuelles Java (JVM) pour optimiser les meilleures performances WebSphere eXtreme Scale. Dans la plupart des cas, quelques paramètres JVM spéciaux sont nécessaires ou aucun. Si de nombreux objets sont stockés dans la grille de données, définissez une taille de pile appropriée pour éviter de manquer de mémoire.

En configurant eXtremeMemory, vous pouvez stocker des objets dans la mémoire native plutôt que dans le segment de mémoire Java. La configuration eXtremeMemory active eXtremeIO, un nouveau mécanisme de transport. En retirant des objets du segment de mémoire Java, vous pouvez éviter les pauses de récupération d'espace, ce qui permet de bénéficier de performances plus constantes et de temps de réponse plus prévisibles. Pour plus d'informations, voir Configuration de IBM eXtremeMemory et de IBM eXtremeIO.

Plateformes testées

Les tests de performance ont été réalisés principalement sur des ordinateurs AIX (32 voies), Linux (quatre voies) et Windows (huit voies). Avec des ordinateurs AIX haut de gamme, vous pouvez tester des scénarios qui font appel à de nombreuses unités d'exécution pour identifier et corriger les points de conflit.

Récupération de place

WebSphere eXtreme Scale crée des objets temporaires associés à chaque transaction tels que la demande et la réponse ainsi la séquence de journal. Ces objets affectant l'efficacité de la récupération de place, l'optimisation de la récupération de place est cruciale.

Toutes les machines virtuelles Java actuelles utilisent des algorithmes de récupération de place en parallèle, ce qui implique que l'utilisation d'un plus grand nombre de coeurs peut réduire les pauses dans la récupération de place. Un serveur physique avec huit coeurs a une récupération plus rapide qu'un serveur physique avec quatre coeurs.

Lorsque l'application doit gérer une large quantité de données pour chaque partition, la récupération de place peut être un facteur déterminant. Un scénario de lecture principalement est performant même avec de grands segments (20 Go ou plus) si un collecteur générationnel est utilisé. Toutefois, une fois que le segment de réservation est rempli, une pause proportionnelle à la taille de pile réelle et au nombre de processeurs sur l'ordinateur se produit. Cette pause peut être longue sur les petites ordinateurs avec de grands segments de mémoire.

Machine virtuelle IBM pour la récupération de place Java

Pour la machine virtuelle IBM® pour Java, utilisez le collecteur optavgpause pour les scénarios impliquant des mises à jour fréquentes (100 % des transactions modifient les entrées). Le collecteur gencon fonctionne d'une manière similaire au collecteur optavgpause pour les scénarios où les données sont mises à jour peu fréquemment (10 % du temps au plus). Expérimentez les deux collecteurs pour savoir lequel est le mieux adapté à vos besoins. Utilisez la récupération de place prolixe pour vérifier le pourcentage de temps passé à la récupération de place. Des cas ont été relevés où 80 % de l'exécution sont consacrés à la récupération de place jusqu'à ce que l'optimisation corrige le problème.

Utilisez le paramètre -Xgcpolicy pour changer le mécanisme de collecte de place. La valeur du paramètre -Xgcpolicy peut être -Xgcpolicy:gencon ou -Xgcpolicy:optavgpause, selon le récupérateur de place que vous voulez utiliser.

Autres options de récupération de place

Avertissement : Si vous utilisez une machine virtuelle Java Oracle, il peut être nécessaire d'ajuster la récupération de place et d'optimiser la stratégie.

WebSphere eXtreme Scale prend en charge WebSphere Real Time Java. Avec WebSphere Real Time Java, la réponse du traitement des transactions pour WebSphere eXtreme Scale est plus cohérente et prévisible. En conséquence, l'impact de la récupération de place et de la planification des unités d'exécution est considérablement réduit. L'impact est réduit au point où l'écart type du temps de réponse est inférieur à 10 % du langage Java classique.

Performance de la JVM

WebSphere eXtreme Scale peut être exécuté sur différentes versions de Java Platform, Standard Edition. WebSphere eXtreme Scale prend en charge Java SE version 5, Java SE version 6 et Java SE version 7. Pour optimiser la productivité et les performances des développeurs, utilisez Java SE version 5, version 6, ou Java SE version 7 pour tirer parti des annotations et de la récupération de place améliorée. WebSphere eXtreme Scale tourne sur les machines virtuelles Java 32 bits ou 64 bits.

WebSphere eXtreme Scale est testé avec un sous-ensemble de machines virtuelles disponibles mais la liste de prise en charge n'est pas exhaustive. Vous pouvez exécuter WebSphere eXtreme Scale sur n'importe quelle machine JVM de fournisseur au niveau d'édition 5 ou suivant. Toutefois, en cas de problème avec la machine JVM d'un fournisseur, vous devez contacter le fournisseur de la machine JVM pour obtenir une assistance. Si possible, utilisez la machine JVM de l'environnement d'exécution WebSphere sur n'importe quelle plateforme qui prend en charge WebSphere Application Server.

En règle générale, utilisez la dernière version disponible de Java Platform, Standard Edition pour obtenir de meilleures performances.

Taille de pile

Il recommandé d'utiliser des segments de mémoire de 1 à 2 Go avec une machine virtuelle Java pour quatre coeurs. La taille de segment de mémoire optimal dépend des facteurs suivants :
  • le nombre d'objets actifs présents dans le segment
  • le degré de complexité des objets actifs présents dans le segment
  • le nombre de coeurs utilisables par la machine virtuelle Java

Par exemple, une application qui stocke des tableaux de 1 Ko peut utiliser une segment de mémoire beaucoup plus grand qu'une application qui utilise des graphiques complexes de POJO.

Nombre d'unités d'exécution

Le nombre d'unités d'exécution dépend de quelques facteurs. Une limite existe pour le nombre d'unités d'exécution pouvant être gérées par un seul fragment. Un fragment est une instance de partition et peut être un fragment primaire ou une réplique. Avec un nombre plus important de fragments pour chaque JVM, vous disposez de plusieurs unités d'exécution avec chaque fragment supplémentaire fournissant plus de chemins simultanés d'accès aux données. Chaque fragment est aussi concurrent que possible même si l'accès simultané est limité.

Exigences de la fonction ORB (Object Request Broker)

Le kit de développement de logiciels IBM comprend une implémentation ORB IBM qui a été testée avec WebSphere Application Server et WebSphere eXtreme Scale. Pour faciliter le processus de prise en charge, utilisez une machine virtuelle Java IBM. Les autres implémentations de machines virtuelles Java utilisent une autre fonction ORB. L'ORB IBM est fourni uniquement avec les machines virtuelles IBM Java. WebSphere eXtreme Scale requiert une fonction ORB opérationnelle. Vous pouvez utiliser WebSphere eXtreme Scale avec les ORB d'autres fournisseurs. Toutefois, si vous avez un problème avec un ORB de fournisseur, vous devez contacter le fournisseur ORB pour obtenir une assistance. L'implémentation ORB IBM est compatible avec des machines virtuelles Java tierces et peut être remplacée si nécessaire.

Optimisation d'orb.properties

En laboratoire, le fichier suivant a été utilisé sur les grilles de données de jusqu'à 1 500 machines virtuelles Java. Le fichier orb.properties se trouve dans le dossier lib de l'environnement d'exécution.
# IBM JDK properties for ORB
org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton

# WS Interceptors
org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer

# WS ORB & Plugins properties
com.ibm.CORBA.ForceTunnel=never
com.ibm.CORBA.RequestTimeout=10
com.ibm.CORBA.ConnectTimeout=10

# Needed when lots of JVMs connect to the catalog at the same time
com.ibm.CORBA.ServerSocketQueueDepth=2048

# Clients and the catalog server can have sockets open to all JVMs
com.ibm.CORBA.MaxOpenConnections=1016

# Thread Pool for handling incoming requests, 200 threads here
com.ibm.CORBA.ThreadPool.IsGrowable=false
com.ibm.CORBA.ThreadPool.MaximumSize=200
com.ibm.CORBA.ThreadPool.MinimumSize=200
com.ibm.CORBA.ThreadPool.InactivityTimeout=180000

# No splitting up large requests/responses in to smaller chunks
com.ibm.CORBA.FragmentSize=0