Extreme TPS drop caused by Minecart logic
LadyCailinBot opened this issue · 12 comments
CMDHELPER-2943 - Reported by ridddle
WarmRoast results: http://i.imgur.com/ji27b9A.png
I encountered problems with minecarts when updating my server the last time, it was around this commit: c8fb251
I was able to cherry pick an earlier build which didn’t have that problem.
Right now, however, I am forced to use a recent 1.7.9-compatible build and I cannot simply opt out of those changes.
I cannot overstate how bad the minecart problem is. I run a dedicated server with Intel Xeon E3-1270 (Sandy Bridge 3.4ghz) and 24 GB of RAM on SSD. I am hitting the wall with 10 players online, where I should not have any issues until 50-60 players.
My TPS are tanking. I’m talking about performance being halved. Going from 20/20 TPS to 12, 13, 16, 11, etc.
Please, please, revert those changes until they are stable. This is destroying me.
Comment by ridddle
Detailed WarmRoast tree: http://i.imgur.com/dUe7OB7.png
Comment by ridddle
Update: it’s related to Minecart Chests being stacked in 1 tight spot on top of a hopper. Place 40-50 of them in one place and TPS will tank like mad. This has not happened on build #2614-2074cb7 but upgrading to newer builds (especially the last current dev build, #2686-0827ccf). It is indeed the collision problem reported by WarmRoast.
Comment by PseudoKnight
I don't think that's the commit.
Did you try build 2663? There's issues in builds after that, and the warmroast points to the class loading, which is where the issue resides. http://youtrack.sk89q.com/issue/CMDHELPER-2938 The only thing not 1.7.9 compatible is sudo(), I think. It might be better if you fork off of that build and commit the sudo changes.
Comment by PseudoKnight
I compiled a build that had reverted the capture_runas commit, and it fixed the extension scanning issue. I'll try and recreate your issue (storage minecarts stacked over hoppers) and see if it helps.
Comment by PseudoKnight
So it didn't help. So I'm starting to test more builds. I can confirm that it isn't the commit above and it seems to be reproduce-able.
Comment by PseudoKnight
This is the commit that caused the problem, in build 2661:
01d4775
It's causing the VehicleEntityCollisionEvent to take ~16x as long.
I compiled a build without those two commits (2661 and 2664) and both problems are solved.
Comment by PseudoKnight
This doesn't mean it's solved, and I don't have any control over the project. (i don't think I can just do a pull request to revert these two commits without discussing and looking for the actual causes) I can offer you a fixed jar if you're really in a bind here. Not sure the policy on that, as it can be dangerous to run things from someone you don't know.
Comment by EntityReborn
Pseudo, you can always do a PR. LC and I will discuss and comment on any changes.
Comment by PseudoKnight
Alright, I submitted a PR. It's mostly straightforward reverts until better solutions are found. I don't think anyone will miss those commits.