Lootr (Forge & NeoForge)

Lootr (Forge & NeoForge)

66M Downloads

Lag on Save

Darkere opened this issue ยท 3 comments

commented

Not sure what is happening here. https://spark.lucko.me/fVkrCqMw6b

lootr neoforge 1.21-1.10.34.86

Enigmatica 10
User report discord link https://discord.com/channels/195234321836146688/1326997323066249327

commented

This is bizarre and totally not what I expected the issue to be about. #556 shows there are some instances (specifically with ATM10) where saving can become problematic, which seems to be related to a potential NeoForge issue addressed at neoforged/NeoForge#1796

In this instance, however, I'm suspicious that there's some sort of file-system-related shenanigans:

These methods shouldn't be taking up so much of the tick time and I don't think I've ever seen them show up on a profile before; that they're specifically bottlenecked in the readSavedData and readTagFromDisk makes me think that this is some sort of filesystem issue.

This is another interesting point. I'm not sure if this is some sort of deferred DataFixerUpper, but I imagine that this going on in the background is going to be problematic.

I will assume that there are some mods that that have older structures and that the DFU updates to them is consuming quite a bit of the tick time, but I'm unsure why it would be constantly triggering -- or if it is actually constantly triggering?

That said, the profile itself confuses me -- some methods seem to be consuming more than 100% of the tick time. I'm guessing this is only measuring ticks over a certain duration?

commented

In this instance, however, I'm suspicious that there's some sort of file-system-related shenanigans

It may be worth investigating if the user has a non-standard antivirus configuration, or something similar. The system specs look good enough that I doubt this is a slow disk.

I will assume that there are some mods that that have older structures and that the DFU updates to them is consuming quite a bit of the tick time, but I'm unsure why it would be constantly triggering -- or if it is actually constantly triggering?

If the structure file is extremely large (some mods have such files, like When Dungeons Arise) DFU will take a while on the structure. Moreover, the upgraded file is not cached on disk, so every server restart will require this upgrade process to run again. ModernFix used to cache it, but I dropped that feature in 1.21 because it broke with some vanilla change, and DFU seemed fast enough on reasonably sized structures. Maybe I need to revisit that...

That said, the profile itself confuses me -- some methods seem to be consuming more than 100% of the tick time. I'm guessing this is only measuring ticks over a certain duration?

This happens with Spark sometimes. In my experience, the amount of time each method takes relative to others is still accurate enough to get an idea of the bottleneck.

commented

the 100+% issue could be related to only tracking ticks above 200ms.

User reported the issue fixed, when moving the server off of a HDD.

As #556 is still open I'll close this one