Rendimiento de la memoria
Las incidencias de rendimiento suelen detectarse en el uso general de la memoria de las aplicaciones de ThingWorx. Si la aplicación utiliza el montón de memoria de Java de forma agresiva y crea y descarta constantemente objetos de la memoria de gran tamaño, se observarán indicadores de rendimiento deficientes en las métricas de memoria de este sistema. La frecuencia y la duración de las recopilaciones de basura de Java desempeñan un rol importante en la capacidad de respuesta general del sistema. Si hay bucles constantes de recopilación de basura, la aplicación sufre estrés de memoria, lo que puede provocar que la plataforma de ThingWorx no responda en su totalidad.
Para supervisar el uso de la memoria de Java y la recopilación de basura a lo largo del tiempo, se recomienda activar el registro de GC. Las herramientas como, por ejemplo, PSM o VisualVM, también permiten mostrar la información sobre la utilización de la memoria. Sin embargo, si la JVM no responde debido a bucles completos de GC, puede que estas aplicaciones externas no recuperen los datos para mostrar las incidencias de memoria.
Se debe tener en cuenta que al supervisar la memoria en el nivel del sistema operativo, no se proporciona información sobre el modo en que la aplicación de ThingWorx utiliza la memoria que se le asigna. La herramienta de supervisión permite recuperar datos sobre la cantidad de memoria que Java solicitada del sistema operativo, pero no muestra cómo Java utiliza la memoria. La mayoría de las incidencias de rendimiento se deben al uso interno de la memoria en el espacio del montón de Java, no a las asignaciones de memoria del sistema operativo.
La memoria global asignada a Java la determinan los parámetros -Xms (mínimo) y -Xmx (máximo) que se cargan en tiempo de ejecución. Los parámetros -Xms y -Xmx permiten especificar el tamaño de la agrupación de memoria inicial y máximo, si Tomcat se configura mediante el panel de configuración de tomcat8w.
Si no se especifican valores mínimos o máximos en el inicio, el proceso de Java en el inicio utiliza un método heurístico para preasignar estas cantidades. Por defecto, Java intenta asignar una cuarta parte de la RAM global disponible en el sistema operativo.
Operaciones que causan incidencias de memoria
Se deben supervisar las siguientes operaciones, que pueden provocar incidencias de memoria:
• Operaciones de GC completas, extremadamente largas y frecuentes, con una duración superior a 45 segundos: las operaciones de GC completas no son deseables, ya que se trata de operaciones stop-the-world. Cuanto más tiempo esté en pausa la JVM, más incidencias de memoria hay:
◦ Los demás subprocesos activos se detienen mientras que la JVM intenta liberar memoria.
◦ Las recopilaciones de basura completas tardan un tiempo considerable, a veces minutos, durante el que la aplicación puede dejar de responder.
• Recopilaciones de basura completas que se producen en un bucle: las recopilaciones de basura completas que se producen en una sucesión rápida se denominan bucles de recopilaciones de basura. Pueden provocar las siguientes incidencias:
◦ Si la JVM no puede limpiar memoria adicional, el bucle puede continuar de manera indefinida.
◦ La aplicación de ThingWorx no está disponible para los usuarios mientras el bucle continúa.
• Pérdidas de memoria: las pérdidas de memoria se producen en la aplicación cuando se conserva un número cada vez mayor de objetos en la memoria. Estos objetos no se pueden limpiar, independientemente del tipo de recopilación de basura que realice JVM.
◦ Cuando se verifica el consumo de memoria a lo largo del tiempo, una pérdida de memoria aparece como un uso de memoria cada vez mayor que nunca se ha reclamado.
◦ El servidor se queda sin memoria, independientemente de los límites superiores que se hayan definido.