WorldGuard

WorldGuard

8M Downloads

Shaky-sand caused memory leak

LadyCailinBot opened this issue ยท 4 comments

commented

WORLDGUARD-4169 - Reported by djytw

(Version: WorldGuard-7.0.2 on 1.14.4)

My server always run out of memory after several hours, and starts full GC, with no effect. Memory usage is still high after lots of Full GC, and server will lag with tps under 5.

After some test, I found this is caused by the 0tick shaky sand and WorldGuard. To validate this, I created a new map with ~300 shaky sand, using a common method (boat on a campfire). With WorldGuard installed, the server will run out 3G of memory and tps drop to 5 in half an hour; on the other hand, without the plugin, and using the same map, the server runs without problem for days.

I use jmap and MAT to analyse the heap, found this line:

occupies most of the memory, which might be called by a EntityChangeBlockEvent: .

I think every time the boat changes the sand between entity and block, these code will add a tracker information to it, then occupy a huge amount of memory.

This is quite a crutial problem since there's an increasing number of players start using this technique to build some farming mechine, and I have to restart the server 4 times a day to free the memory, or it will be extremely lag. Although this method of creating shaky-sand is fixed in 1.15, there're many new methods can also do the same. Futhermore, villager farming and ender dragon and wither destroying blocks might also have the same issue, since the problem is introduced by the EntityChangeBlockEvent.

commented

I have the same issue on the most recent versions of everything as well (Minecraft Paper 1.21.1, WorldGuard 7.0.12, WorldEdit 7.3.7).

Cause is probably setting no-gravity-sand (and gravel).
That causes WorldGuard to never clear the falling block as a cause, since it never fell in the first place.

The function also causes duplicates as well, so once block can cause multiple causes that remain in memory.

commented

Comment by wizjany

from what i can tell there will be at most one cause attached to an entity since put should replace any previous value?
not sure exactly what the leak is and without seeing a heap dump or at least reproduction it's not clear that there's an issue here.

commented

Comment by djytw

hi @wizjany
here's the dump

and all of the ConcurrentHashMap has a key like "UUID:worldguard.cause"

That's why I located Cause.java
This is the content of one hashmap

commented

Comment by djytw

I think everytime the event is triggered, the sand changes from entity->block->entity, so the Cause don't replace the old one because the entity is changed. And due to some reasons, the old entity released but it's metadata didn't.