Major peformance issue impact bug. #326
Comments
|
Seems like the #getData call took too long on your server. Looks like to know more, we could try printing out some debug to find out what type of block is growing and determine why that's taking so long. |
|
Turning the debug on does not print out anything before/after the error/lagspike. Unless i'm missing something, https://mclo.gs/I4sF5X0 Plugin settings: https://mclo.gs/RRgVmIn Another note, it started to happen pretty much right after updating to 1.21, maybe something related to chunk loading/#getData have changed in 1.21. Have not tested this on an test server yet, i can provide an test server for you to see the issue firsthand, including server admin access. (if this even happens on an test server) |
|
Hello. Have updated the server to 1.21.1 and noticed the error is now bigger and different. (more lines) Maybe worth to check out this new error. The error log seems to have several mentions of |
|
Hmm, I wonder if this is perhaps loading chunks, and Minecraft is attempting to convert these blocks to 1.21 format? I wonder if this occurs on a fresh world. Looks like I was starting to add some debug stuff but must've been busy doing other things and forgot. I'll try to remember later this week - I basically plan to separate out those calls to variables beforehand and to print said variables to debug log is all for right now to at least confirm the exact method it's stuck on. |
|
Did attempt the test it with an fresh world. It didnt happen there i believe(Dont quote me). But that isnt that strange. Its an extreem small world while the world we have is... wel. Not massive. But its way bigger then an fresh world. Meaning that the result are kinda "waste of time". Also, would like to point out that the plugin has not officially updated to 1.21, not even 1.20.x. Now granted, it worked "fine" on 1.20.6, but maybe 1.21 changed something, so maybe worth to take a peek atleast at the 1.21 dev changes to see if any of it used by the plugin what then might cause it to hang. (It trying todo something what doesnt exists anymore and/or not in the same way) |
|
getData is a newer method as far as I recall from 1.13, so I see no reason why that would change anything. Only thing it could potentially be is the legacy material conversion. That being said, as for your massive world - are you able to reproduce it? If so, can you use a copy of that in a test server and see if it still happens after the world has been converted (i.e. all chunks loaded and saved once on 1.21)? |
|
Its quite hard to reproduce. As it seems to be very inconsistent. As to where it happens. Some places way more then others. The world is "World Force Upgrade" so it should be already 1.21.1. Have tried testing this on the test server with no result as far i remember. (other then what i said before.) Will wait for the more improved debugging. |
|
For my notes:
Anything else you think I should print out? |
|
Try this. If it downloads as a .zip rename it to .jar, as it seems that appveyor (or maybe the Edge browser?) is starting to mess around with file extensions... https://ci.appveyor.com/project/RoboMWM39862/extrahardmode/builds/50547906/artifacts |
|
Thank you, had something happen in the last days what cause me to forget about this for few days. (Just to be clear i didnt care about it.) Wil start testing it with the provided jar. |
|
Did some testing, and found the following results. Whenever the server lagged it always had the following line. [ExtraHardMode] BlockGrowEvent block material: VINE, location: Location{world=CraftWorld{name=world},x=330.0,y=-10.0,z=-975.0,pitch=0.0,yaw=0.0} Followed by: [org.bukkit.craftbukkit.legacy.CraftLegacy] Initializing Legacy Material Support. Unless you have legacy plugins and/or data this is a bug! Then the lag spike. (See full log) Followed by [ExtraHardMode] Successfully retrieved getNewState#getData When then teleporting to the coords in the first EHM message its always something like this. So, seems EHM does get sometimes stuck on it as other "BlockGrowEvent block material:" gets instantly returned. Also, when teleporting removing the fines it continue to happen, but then just to another one. Need to note also down that when they get returned right away it also have the same or familiar conditions. Full stacktrace: https://mclo.gs/kvLi5Zl |
|
Interesting thing, updated Paper to Build 77. Previous logs are from an older build(20 builds) and now there is i believe another new error log. (Do not quote me on it, just did some line copy checking) |
|
mk, so it seems to always be with vines in underground caves? And does it consistently happen when that chunk is loaded? Or is it only on chunk generation? |
|
It is always underground caves, yes. Same chunk/when loading. Removing it and then doing the same result's in just an different vine. Cant remember if it was always in the same chunk. dont believe so. Turning "Weak Crops:" to false resolves this lagspike. So it has something todo with said mechanic. Keep in mind however that this does not always trigger, but when it does is the above. |
|
I asked the devs of PaperMC, one of the devs said the following:
I mentioned if 2 methods the plugin uses has recently been changed and gave the lastest crashlog. |
|
Expected from them lol; that's an off-the-cuff answer though. I also wonder what changed. I have no problem seeing a need to have older plugins update for better performance on newer versions, but one of the goals of the bukkit API is forward compatibility. Anyone is free to PR this sort of change though (or take over the plugin, if they so desire, as I do not use this plugin myself anymore) since I'd imagine it's not a completely trivial effort. |
Sometimes the server gets a large lag spike with the following massive error in the console:
Reason i believe it has todo with this plugin is because it mentions the plugin.
Paper build: 1.21-108-master@73a863b
EHM build: 3.15.1-beta-c1a56d8
I'm aware that the plugin has no released an 1.21 compatibility update, buit feel it should be updated to it at some point and thus reporting is still usefull.
The text was updated successfully, but these errors were encountered: