Memoria: cuánta asignar y por qué no toda

El gráfico de memoria en el panel asusta a los novatos: casi siempre está alto. Esto es el comportamiento normal de Java.

Cómo interpretarlo

Java reserva memoria por adelantado y solo la libera durante la recolección de basura. El diente de sierra en el gráfico —uso que sube y una caída brusca tras la recolección— es señal de un servidor sano.

Un problema se ve distinto: la línea se pega al techo y no baja después de las caídas. Eso significa que la basura no se está liberando —o la memoria es realmente muy poca, o hay una fuga.

Señales de escasez

• OutOfMemoryError en el log — análisis.
• Congelaciones de varios segundos que aumentan con el tiempo de actividad.
• El servidor va bien tras un reinicio y se degrada por la tarde.

Fuga

Si el consumo crece de forma lineal y no baja, busca al culpable:

spark heapsummary

Normalmente es un plugin que acumula datos, o un mod con cargadores de chunks — Spark.

Una medida temporal es el reinicio automático una vez al día. La solución definitiva es encontrar y actualizar al culpable.

No lo asignes todo

Además del heap, el proceso necesita memoria para metadatos, hilos y búferes, y el contenedor necesita memoria para el sistema. El panel de Millida lo tiene en cuenta por sí solo al fijar los límites de heap según el plan —no necesitas tocarlo manualmente.

Cuándo cambiar de plan

Cuando el consumo máximo llega de forma constante al límite durante el funcionamiento normal y el perfil no muestra una fuga — Cambiar de plan.