Dimensionamiento del consumo de memoria caché

WebSphere eXtreme Scale puede estimar con precisión el uso de memoria de almacenamiento dinámico de Java de un BackingMap determinado en bytes. Utilice esta posibilidad para ayudar a dimensionar correctamente los valores de almacenamiento dinámico de la máquina virtual Java y las políticas de desalojo. El comportamiento de esta característica varía con la complejidad de los objetos colocados en la correlación de respaldo y con el modo en que se configura la correlación. Actualmente, esta característica está soportada solo para cuadrículas de datos distribuidas. Las instancias de cuadrículas de datos locales no dan soporte al dimensionamiento de bytes utilizados.

Consideraciones sobre el consumo del almacenamiento dinámico

eXtreme Scale almacena todos sus datos en el espacio de almacenamiento dinámico de los procesos de JVM que componen la cuadrícula de datos. Para una correlación determinada, el espacio de almacenamiento dinámico que consume se puede dividir en los componentes siguientes:
  • El tamaño de todos los objetos clave que están actualmente en la correlación
  • El tamaño de todos los objetos de valores que están actualmente en la correlación
  • El tamaño de todos los objetos EvictorData que están siendo utilizados por los plug-ins Evictor de la correlación
  • La sobrecarga de la estructura de datos subyacente

El número de bytes utilizados notificado por las estadísticas de tamaño es la suma de estos cuatro componentes. Estos valores se calculan por cada entrada en las operaciones de insertar, actualizar y eliminar correlación, lo que significa que eXtreme Scale siempre tiene un valor actual para el número de bytes que consume una correlación de respaldo determinada.

Cuando se particionan las cuadrículas de datos, cada partición contiene una parte de la correlación de respaldo. Dado que las estadísticas de tamaño se calculan en el nivel bas bajo del código de eXtreme Scale, cada partición de una correlación de respaldo realiza un seguimiento de su propio tamaño. Puede utilizar las API de estadísticas de eXtreme Scale para realizar un seguimiento del tamaño acumulativo de la correlación, así como del tamaño de sus particiones individuales.

En general, utilice los datos de tamaño como medida de las tendencias de los datos a lo largo del tiempo, no como una medida precisa del espacio de almacenamiento dinámico que está utilizando la correlación. Por ejemplo, si el tamaño notificado de una correlación se hace el doble de 5 MB a 10 MB, vea el consumo de memoria de la correlación como que se ha duplicado. La medida actual de 10 MB podría ser imprecisa por diversas razones. Si tiene en cuenta las razones y sigue los métodos recomendados, la precisión de las mediciones de tamaño se aproxima a la del proceso posterior de un volcado de almacenamiento dinámico Java.

El problema principal con la precisión es que el modelo de memoria Java no es lo suficientemente restrictivo para permitir mediciones de memoria que es seguro que son precisas. El problema fundamental es que un objeto puede estar activo en el almacenamiento dinámico debido a varias referencias. Por ejemplo, si se inserta la misma instancia de objeto de 5 KB en tres correlaciones distintas, cualquiera de estas tres correlaciones impide que el objeto sea objeto de la recogida de basura. En esta situación, cualquiera de las mediciones siguientes sería justificable:
  • El tamaño de cada correlación aumenta en 5 KB.
  • El tamaño de la primera correlación en la que se coloca el Objeto aumenta en 5 KB.
  • El tamaño de las otras dos correlaciones no aumenta. El tamaño de cada correlación aumenta en una fracción del tamaño del objeto.

Esta ambigüedad es por lo que estas medidas se deben considerar datos de tendencia, a menos que haya eliminado la ambigüedad mediante opciones de diseño, métodos recomendados y la comprensión de las opciones de implementación que pueden proporcionar estadísticas más precisas.

eXtreme Scale asume que una correlación determinada mantiene la única referencia de larga duración a los objetos clave y valor que contiene. Si el mismo objeto de 5 KB se coloca en tres correlaciones, el tamaño de cada correlación aumenta en 5 KB. El aumento no suele ser un problema, porque la característica solo está soportada para cuadrículas de datos distribuidas. Si inserta el mismo Objeto en tres correlaciones distintas en un cliente remoto, cada correlación recibe su propia copia del Objeto. Los valores de COPY MODE transaccionales predeterminados suelen garantizar también que cada correlación tiene su propia copia de un objeto determinado.

Internación de objetos

La internación de objetos puede presentar un reto al estimar el uso de memoria de almacenamiento dinámico. Al implementar la internación de objetos, el código de la aplicación garantiza deliberadamente que todas las referencias a un valor de objeto determinado apunten realmente a la misma instancia de objeto en el almacenamiento dinámico y, por lo tanto, la misma ubicación en la memoria. Un ejemplo de esto podría ser la clase siguiente:
 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:
     }
 }
La internación de objetos causa una sobrestimación de las estadísticas de tamaño porque eXtreme Scale supone que los objetos utilizan distintas ubicaciones de memoria. Si existe un millón de objetos ShippingOrder, las estadísticas de tamaño visualizan el coste de un millón de series que contienen la información de estado. En realidad, solo existen tres series que son miembros de clase estática. El coste de memoria de los miembros de clase estática nunca se debe añadir a ninguna correlación eXtreme Scale. Sin embargo, esta situación no se puede detectar durante el tiempo de ejecución. Existen docenas de formas en las que se puede implementar internación de objetos similar, y por esto es tan difícil de detectar. No es práctico para eXtreme Scale protegerse frente a todas las implementaciones posibles. Sin embargo, eXtreme Scale se protege frente a los tipos de internación de objetos utilizados más habitualmente. Para optimizar el uso de memoria con la internación de objetos, implemente la internación solo en objetos personalizados que se encuentren en las dos categorías siguientes para ampliar la precisión de las estadísticas de consumo de memoria:
  • eXtreme Scale se ajusta automáticamente para las enumeraciones Java 5 y el patrón de enumeración Typesafe, tal como se describe en el documento Java 2 Platform Standard Edition 5.0 Overview: Enums.
  • eXtreme Scale da cuenta automáticamente de la internación automática de tipos de derivador primitivos como, por ejemplo, un entero. La internación automática de tipos de derivador primitivos se introdujo en Java 5 mediante la utilización de los métodos valueOf estáticos.

Estadísticas de consumo de memoria

Utilice uno de estos métodos para acceder a las estadísticas de consumo de memoria.
API de estadísticas

Utilice el método MapStatsModule.getUsedBytes(), que proporciona estadísticas para una única correlación, incluido el número de entradas y la proporción de coincidencias.

Si desea detalles, consulte Módulos de estadísticas.

Beans gestionados (MBeans)

Utilice la estadística de MBean gestionado MapUsedBytes. Puede utilizar varios tipos distintos de MBeans JMX (Java Management Extensions) para administrar y supervisar despliegues. Cada MBean hace referencia a una entidad específica como, por ejemplo, una correlación, eXtreme Scale, servidor, grupo de réplicas o miembro del grupo de réplicas.

Si desea detalles, consulte Administración con beans gestionados (MBeans).

Módulos PMI (Performance Monitoring Infrastructure)

Puede supervisar el rendimiento de las aplicaciones con los módulos PMI. Especialmente, utilice el módulo PMI de correlación para los contenedores incorporados en WebSphere Application Server.

Si desea detalles, consulte Módulos PMI.

Consola de WebSphere eXtreme Scale

Con la consola, puede visualizar las estadísticas de consumo de memoria. Consulte Supervisión con la consola web.

Todos estos métodos acceden a la misma medición subyacente del consumo de memoria de una instancia de BaseMap determinada. El tiempo de ejecución de WebSphere eXtreme Scale intenta con un mejor esfuerzo calcular el número de bytes de memoria de almacenamiento dinámico que consumen los objetos de clave y valor almacenados en la correlación, así como la sobrecarga de la propia correlación. Puede ver cuánta memoria de almacenamiento dinámico consume cada correlación en toda la cuadrícula de datos distribuida.

En la mayoría de los casos, el valor notificado por WebSphere eXtreme Scale para una correlación determinada está muy próximo al valor notificado por el análisis de volcado de almacenamiento dinámico. WebSphere eXtreme Scale dimensiona de forma precisa su propia sobrecarga, pero no puede dar cuenta de todos los objetos posibles que podrían colocarse en una correlación. Si se siguen los métodos recomendados descritos en Ajuste del agente de dimensionamiento de memoria caché para obtener estimaciones precisas del consumo de memoria se podría mejorar la precisión del tamaño de las mediciones en bytes proporcionadas por WebSphere eXtreme Scale.