lithium-fabric
lithium-fabric copied to clipboard
Server lags each time an end/nether portal is used.
Version Information
lithium-fabric-mc1.17-0.7.1
Expected Behavior
Server doesn't drop ~40-60 ticks each time a player enters/leaves the end/nether.
Actual Behavior
Server drops ~40-60 ticks each time a player enters/leaves the end/nether.
Reproduction Steps
A player enters/leaves the end/nether.
Other Information
Mods used:
- convenient-mobgriefing-2.0.2,
- fabric-api-0.35.2+1.17,
- fabric-carpet-1.17-1.4.40v210608,
- fastfurnace-1.17-3.0
- krypton-0.1.3
This is usually a consequence of the lighting engine being slow, are you sure this is related to lithium?
I just removed lithium from my server and the issue no longer occurs.
Try replicating this issue with Lithium alone, please.
Can anyone else reproduce the difference between lithium present/absent?
I can confirm the same thing happens to me which meant i had to remove the plugin. You would also fall through the world for several seconds when you returned from the nether. Both issues got fixed when i removed lithium.
Can confirm on 1.18.2.
I ran into the same issue with the 1.19.2. It seems to get considerably worse when the affected player has a high ping (in our case, server in europe, player in US). Are there any links to vanilla issues or is there something that we can do? Because without lithium a lot of other stuff is pretty slow.
Can you check whether adding the line mixin.world=false to the lithium config file (lithium.properties in config folder) followed by restarting the server causes a difference / works around the issue?
Sorry, for the late answer, but I wanted to carefully check with this. We had this setting running for about two days. I became a little better such that people won't timeout anymore and the loading screen appears longer instead of people falling through the world. Anyways, the culprit seemed to be the server-performance. Especially CPU usage spiked regardless of the setting. I wasn't been able to see these spikes on any monitoring, because the spikes where too short. But some manual metric gathering unrevealed the issue. We then turned down the render and simulation distance and everything is better now (with or without mixin.world=false). Anyways, thanks for the support here.