Memory: how much to allocate and why not all of it

The memory graph in the control panel scares newcomers: it’s almost always high. This is normal Java behavior.

How to read it

Java allocates memory in advance and frees it only during garbage collection. The sawtooth on the graph — rising usage and a sharp drop after collection — is a sign of a healthy server.

A problem looks different: the line is pinned to the ceiling and doesn’t come down after the dips. That means garbage isn’t being freed — either memory is genuinely too low, or there’s a leak.

Signs of shortage

• OutOfMemoryError in the log — analysis.
• Freezes for several seconds that grow with uptime.
• The server runs fine after a restart and degrades by evening.

Leak

If consumption grows linearly and doesn’t drop, look for the culprit:

spark heapsummary

Usually it’s a plugin that accumulates data, or a mod with chunk loaders — Spark.

A temporary measure is auto-restart once a day. The permanent fix is to find and update the culprit.

Don’t allocate everything

Besides the heap, the process needs memory for metadata, threads, and buffers, and the container needs memory for the system. The Millida control panel accounts for this itself by setting heap limits according to the plan — you don’t need to touch it manually.

When to change your plan

When peak consumption consistently hits the limit during normal operation and the profile doesn’t show a leak — Changing your plan.