Définition de la taille du cache en fonction de son utilisation

WebSphere eXtreme Scale peut estimer avec précision l'utilisation du segment de mémoire Java d'une mappe de sauvegarde en octets. Cette capacité vous permet de dimensionner correctement les segments de mémoire de vos machines virtuelles Java et de définir de manière appropriée les règles d'expulsion. Le comportement de cette évaluation varie selon le degré de complexité des objets placés dans la mappe de sauvegarde et selon la configuration de la mappe. Actuellement, cette fonctionnalité n'est prise en charge que pour les grilles de données réparties. Les instances de la grille de données locales ne prennent pas en charge le dimensionnement des octets utilisé.

Remarques sur la consommation du segment de mémoire

eXtreme Scale stocke toutes ses données à l'intérieur de l'espace du segment de mémoire des processus JVM qui constituent la grille de données. Pour une mappe donnée, le segment mémoire qu'utilise cette mappe peut se décomposer dans les éléments suivants :
  • la taille de tous les objets key actuellement dans la mappe
  • la taille de tous les objets value actuellement dans la mappe
  • la taille de tous les objets EvictorData qui sont en cours d'utilisation par le plug-in Evictor dans la mappe
  • la taille de la structure de données sous-jacente

Le nombre d'octets utilisés qui est retourné par les statistiques de dimensionnement correspondra donc à la somme de ces quatre composants. Ces valeurs sont calculées en fonction de chaque entrées dans les opérations de mappe d'insertion, de mise à jour et de suppression, ce qui implique que eXtreme Scale contient toujours la valeur actualisée du nombre d'octets qu'une mappe de sauvegarde donnée consomme.

Lorsque les données sont partitionnées, chaque partition contient une partie de la mappe de sauvegarde. Comme les statistiques de dimensionnement sont calculées au niveau le plus bas du code eXtreme Scale, chaque partition d'une mappe se sauvegarde suit sa propre taille. Vous pouvez utiliser les API Statistics d'eXtreme Scale pour suivre la taille cumulée de l'ensemble de la mappe ainsi, d'ailleurs, que les tailles individuelles des partitions qui composent cette mappe.

En règle générale, utilisez les données de taille comme mesure de tendance des données dans le temps et non pas comme une mesure exacte de l'espace de mémoire segmenté qui est utilisé par la mappe. Ainsi, si la taille signalée d'une mappe double de 5 à 10 Mo, considérez que l'utilisation de la mémoire par la mappe a doublé. La mesure réelle 10 Mo peut être inexacte pour diverses raisons. Si vous tenez compte de ces raisons et que vous appliquez les bonnes pratiques que nous préconisons, le dimensionnement sera presque aussi exact que le post-traitement d'un cliché de segment mémoire Java.

Le principal problème avec l'exactitude vient de ce que le modèle mémoire de Java n'est pas suffisamment restrictif et qu'il tolère une certaine marge de précision dans les mesures de la mémoire. Le problème fondamental réside dans le fait qu'un objet peut figurer dans le segment de mémoire parce qu'il existe des références. Par exemple, si une même instance d'objet 5 Ko est insérée dans trois mappes distinctes, ces trois instances empêchent la récupération de la place occupée par l'objet. Dans ce cas de figure, les mesures suivantes sont tout aussi valables :
  • La taille de chaque mappe augmente de 5 Ko.
  • La taille de la première mappe dans laquelle l'objet est placé augmente de 5 Ko.
  • La taille des deux autres mappes n'augmente pas. La taille de chaque mappe augmente d'une fraction de la taille de l'objet.

Cette ambiguïté est la raison pour laquelle ces mesures doivent être considérées comme des données de tendance, sauf si vous avez supprimé l'ambiguïté en effectuant des choix de conception, en appliquant les pratiques recommandées et en comprenant les choix d'implémentation pour fournir des statistiques plus précises.

eXtreme Scale présuppose que chaque mappe est la seule à détenir la référence durable aux objets Key et Value qu'elle contient. Si le même objet de 5 Ko est placé dans trois mappes, la taille de chaque mappe augmente de 5 Ko. L'augmentation n'est généralement pas un problème, car la fonctionnalité n'est prise en charge que pour les grilles de données réparties. Si vous insérez le même objet dans trois mappes différentes sur un client distant, chaque mappe reçoit sa propre copie de l'objet. Par ailleurs, les paramètres par défaut du mode transactionnel COPY MODE garantissent que chaque mappe ait sa propre copie d'un objet donné.

Internement d'objet

L'internement des objets peut poser des problèmes pour estimer l'utilisation du segment de mémoire. Lorsque vous implémentez l'internement des objets, le code de l'application fait en sorte que toutes les références à une valeur d'objet pointe vers la même instance d'objet et donc le même emplacement en mémoire. Voici un exemple avec la classe ci-dessous :
 public class ShippingOrder implements Serializeable,Cloneable{

     public static final STATE_NEW = “new”;
     public static final STATE_PROCESSING = “processing”;
     public static final STATE_SHIPPED = “shipped”;

     private String state;
     private int orderNumber;
	private int customerNumber;

	public Object clone(){
        ShippingOrder toReturn = new ShippingOrder();
        toReturn.state = this.state;
        toReturn.orderNumber = this.orderNumber;
        toReturn.customerNumber = this.customerNumber;
        return toReturn;
     }
 
     private void readResolve(){
         if (this.state.equalsIgnoreCase(“new”)
             this.state = STATE_NEW;
         else if (this.state.equalsIgnoreCase(“processing”)
             this.state = STATE_PROCESSING;
         else if (this.state.equalsIgnoreCase(“shipped”)
             this.state = STATE_SHIPPED:
     }
 }
L'internement d'objet entraîne une surestimation par les statistiques de dimensionnement, car eXtreme Scale suppose que les objets utilisent des emplacements de mémoire différents. Si un million d'objets ShippingOrder existe, les statistiques de dimensionnement affichent le coût d'un million de chaînes détenant les informations d'état. En réalité, seules trois chaînes existent qui sont des membres de classe statique. Le coût de la mémoire pour les membres d'une classe statique ne devrait jamais être ajouté à une mappe eXtreme Scale. Toutefois, cette situation ne peut pas être détecté lors de l'exécution. Il existe des dizaines de façons d'utiliser l'internement d'une manière similaire pour les objets et 'est la raison pour laquelle la détection est difficile. eXtreme Scale ne peut pas fournir une protection contre toutes les implémentations possibles. Toutefois, eXtreme Scale offre une protection contre les types usuels d'internement des objets. Pour optimiser l'internement d'objet, implémentez l'internement uniquement sur les objets personnalisés qui se divisent dans les deux catégories suivantes pour améliorer la précision des statistiques d'utilisation de la mémoire :
  • eXtreme Scale s'ajuste automatiquement pour les énumérations et le pattern Typesage Enum Java 5, comme indiqué dans Java 2 Platform Standard Edition 5.0 Overview: Enums.
  • eXtreme Scale tient compte automatiquement de l'internement automatique des types d'encapsuleurs de type primitif, tels que Integer. L'internement automatique des types d'encapsuleurs de type primitif a été introduit dans Java 5 avec l'utilisation des méthodes valueOf statiques.

Statistiques de consommation de mémoire

Pour accéder aux statistiques d'utilisation de la mémoire, utilisez l'une des méthodes suivantes.
API Statistics

Utilisez la méthode La MapStatsModule.getUsedBytes() qui fournit les statistiques pour une seule mappe unique, notamment le nombre d'entrées et le taux de réussite.

Pour des détails, voir Modules des statistiques.

Beans gérés (MBeans)

Utilisez la statistique de bean géré MapUsedBytes. Vous pouvez utiliser plusieurs types de beans gérés JMX (Java Management Extensions) différents pour administrer et surveiller les déploiements. Chaque bean géré fait référence à une entité spécifique, telle qu'une mappe, eXtreme Scale, un serveur, un groupe de réplication ou un membre de groupe de réplication.

Pour des détails, voir Administration avec les beans gérés (MBeans).

Modules PMI

Vous pouvez surveiller les performances de vos applications avec les modules PMI. Particulièrement, utilisez le module PMI de mappe pour les conteneurs imbriqués dans WebSphere Application Server.

Pour des détails, voir Modules PMI.

Console WebSphere eXtreme Scale

Avec la console, vous pouvez visualiser les statistiques d'utilisation de la mémoire. Voir Surveillance à l'aide de la console Web.

Toutes ces méthodes accèdent à la base aux mêmes mesures de l'utilisation de la mémoire par une instance BaseMap donnée. L'environnement d'exécution WebSphere eXtreme Scale s'efforce de calculer le nombre d'octets de segment de mémoire consommé par les objets key et value stockés dans la mappe et la charge de la mappe elle-même. Vous pouvez déterminer la quantité de segment de mémoire qu'utilise chaque mappe dans l'ensemble de la grille de données répartie.

Dans la plupart des cas, la valeur signalée par WebSphere eXtreme Scale pour une mappe donnée est très proche de la valeur signalée par l'analyse des clichés de segments. WebSphere eXtreme Scale calcule avec précision sa propre charge, mais vous ne pouvez pas tenir compte de chaque objet pouvant être placé dans une mappe. Les meilleures pratiques décrites dans Optimisation de l'agent de dimensionnement du cache pour des estimations précises de l'utilisation de la mémoire peuvent améliorer la précision des mesures de taille en octets fournies par WebSphere eXtreme Scale.