I'm getting an OOM using this software. What's going on?

[granny]

No, there is no memory leak.

Yes, Pl3xMap uses as much ram as it can. That's by design.

What you both are seeing is the server using more ram than the server has to give it. This is due to misconfigurations of the heap allocations on your part.

Let's take Temmy's example since it's got actual numbers I can point at. He has a server with 20GB of physical ram. He's telling the MC server it can use 18GB of that by setting 18432MB as his Xmx parameter in the startup script. This leaves little to no room for the OS to operate on or the JVM to breathe (the JVM comes with overhead).

Ok, so this is all fine and dandy, because he also told the JVM to start up with only 256MB of heap. this is will below the max limit, so it starts up and is fine. Until something starts needing more heap, then the JVM will grow that 256MB until it reaches the Xmx cap you set at 18GB. Except, the JVM's been crunching heavily on some numbers (in this case, Pl3xMap), so the JVM overhead is rather high. Very probably more than 2GB of overhead. And we still havent thought about the OS, or other programs running on the machine, etc etc. All of a sudden the server has run out of ram before it can even allocate all the heap space you told it it could have.

Boom. OOM.

See, look for yourself. The physical ram has run out, and the JVM has only allocated 16GB out of the 18GB it was allowed to grab.

image

You'll see the same OOM almost instantly if you were to follow Aikar's advice on his blog post about JVM flags where he states to make sure Xms is the same value as Xmx. This is important, not only for his flags to operate properly, but to ensure the heap can and does get everything you tell it it can get.

Another thing you can do is lessen the burden on the JVM/heap by lowering the amount of threads Pl3xMap can use (its in the config.yml file). This will result in Pl3xMap needing less ram at one time to do what it needs to do. Since ya'll look to have only 4 cores, I recommend lowering the thread count to 1 for Pl3xMap.

And yet another thing you could do to lessen the burden on your heap is to turn on both GC options in Pl3xMap's config file. This will make the GC run way more aggressively, cleaning out old, dead objects much faster that letting the JVM do it on it's own.

So yeah. TLDR; There's no memory leak. Do the 3 things I suggest and you should be fine.