Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lag on Save #565

Closed
Darkere opened this issue Jan 9, 2025 · 3 comments
Closed

Lag on Save #565

Darkere opened this issue Jan 9, 2025 · 3 comments

Comments

@Darkere
Copy link

Darkere commented Jan 9, 2025

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

@noobanidus
Copy link
Collaborator

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?

@embeddedt
Copy link
Collaborator

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.

@Darkere
Copy link
Author

Darkere commented Jan 10, 2025

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

@Darkere Darkere closed this as completed Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants