Server Implementation

Paper

Server Version

1.21

Describe the bug

After executing some commands, the GC takes a lot of time (because of a high memory usage ?).
As you can see on this spark report everything is fine until some FAWE commands are executed (when the TPS drops).

To Reproduce

• Get the schematic i supplied (this is a .jpg file because Github doesn't want me to upload a .schem)
• Paste it
• Select the whole region pasted with //pos1 and //pos2
• Execute the following commands :
  //replace fire_coral_wall_fan 0
  //replace bubble_coral_wall_fan 0
  //replace brain_coral_wall_fan 0
  //replace tube_coral 0
  //replace tube_coral_wall_fan 0
  //replace dead_brain_coral_wall_fan 0
  //replace short_grass 0
  //replace large_fern 0
• Wait a bit
• Open a spark profiler (/spark profiler open) and keep it open a bit if no noticeable spike is seen.
  -> You should see the GC take a surprising amount of the server time

Expected behaviour

Don't make the GC explode

Screenshots / Videos

No response

Error log (if applicable)

No response

Fawe Debugpaste

https://athion.net/ISPaster/paste/view/a69162cfa61b40df85b08bd24bed8c47

Fawe Version

2.11.3-SNAPSHOT-930;7192e14

Checklist

• I have included a Fawe debugpaste.
• I am using the newest build from https://ci.athion.net/job/FastAsyncWorldEdit/ and the issue still persists.

Anything else?

No response

Could you run the spark allocation profiler and share that too?

What do you mean by the "spark allocation profiler" ?

Here is the schem in a .zip because a .jpg doesn't seem to be usable
rose_port.zip

Could you run the spark allocation profiler and share that too?

e.g. /spark profiler start --alloc --thread * --combine-all

Here is the spark output : https://spark.lucko.me/1v2qdHRqgv

Seems that i haven't let it go that low. It continues to drop after 12 TPS to 1. I'll restart another one tomorrow :)

Please try removing CoreProtect and see if the issue persists.

As you said, the issue is fixed without CoreProtect !
Just a quick question about FAWE logging : does it allows me to see if a specific block at a specific location was edited and by who ? I've never heard about this feature so i'll definetely check into that :)

You will need to restart the server. Unloading the plugin with plugman does completely disable a plugin's integrations. For what it's worth, this is what makes it obviously CoreProtect:

You should just not use CoreProtect for logging FAWE edits as it is poorly coded and puts all blocks into a massive queue to then write to its database. FAWE on the other hand already has integrated edit logging if using history on disk and enabling database, which does not cause massive memory overhead, and also does not slow edits down.

Please try removing CoreProtect and see if the issue persists.

I tried unloading CoreProtect using plugman unload CoreProtect and then reloading FAWE using /fawe reload and the lags are the same : https://spark.lucko.me/6ois4TN1Sr

Yeah exactly that see https://intellectualsites.gitbook.io/fastasyncworldedit/features/main-commands-and-permissions#history-commands

You need history on disk enabled, database enabled, and delete disk history on logout disabled (there's a warning on startup for this)

Great, thanks a lot for your help !