CommandHelper

CommandHelper

46.5k Downloads

Extreme TPS drop caused by Minecart logic

LadyCailinBot opened this issue · 12 comments

commented

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.

commented

Comment by ridddle

Detailed WarmRoast tree: http://i.imgur.com/dUe7OB7.png

commented

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.

commented

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.

commented

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.

commented

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.

commented

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.

commented

Comment by ridddle

<3

Thank you so much for looking into this.

commented

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.

commented

Comment by ridddle

I’d gladly use it, thanks. The problem is quite severe.

commented

Comment by EntityReborn

Pseudo, you can always do a PR. LC and I will discuss and comment on any changes.

commented

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.

commented

Comment by PseudoKnight

Okay, they pulled it, so the commits contributing to this and issue #2938 are reverted in build #2689 until the source of the problems can be figured out.