Hermitpack lag issues #968
Comments
|
@Bebabo10 Thanks, I'll investigate this further when I get some more time to spare =) |
|
@Bebabo10 @LemADEC @hunter688 Please test Let me know if you notice a difference. I'm troubleshooting an odd issue with this pack. |
|
Also here is a highly experimental async build https://www.dropbox.com/s/oy4hu3h4j3cre9w/spongeforge-1.10.2-2098-6.0.0-BETA-async-test1.jar?dl=0 Make sure you backup your entire world before testing this build. DO NOT run in production, i'm not responsible if anything breaks =) Let me know performance results from this build. |
|
Using The /home and /rtp commands fail to teleport unless chunks are already loaded. |
|
@LemADEC Test the other build I posted as well as latest SF. The async build is highly experimental. |
|
|
|
Trying now with spongeforge-1.10.2-2098-6.0.0-BETA-1819.jar Teleportation works as expected. |
|
There seems to be a chunkunloading issue. Version: |
|
After fixing Forestry beehive bugs, lag remains: To reproduce, I'm just doing a 10+ random teleportations to load parts of the map, including the lag base and mine. |
|
Highlights on the Sponge part on a 10mn acquisition: |
|
Test the following builds and report back https://www.dropbox.com/s/59gzwvso8gko58w/spongeforge-1.10.2-2098-6.0.0-BETA-test1.jar?dl=0 Let me know which build is best and if both perform better than build 1819 |
|
http://pastebin.com/ubAxthrM |
|
@bloodmc |
|
With beta-test1, lag is initially severely reduced during the first 10mn profiling: With beta-test2, lag is initially reduced but worse than beta-test1, during first 10mn profiling: I did a few more tests and overall, beta-test2 was the only one able to unload the laggy base (1/3 success vs 0/3), but overall beta-test1 is less laggy. |
|
With Beta-TEST 1. |
|
According to our players, spongeforge-1.10.2-2098-bleeding-BETA-TEST1 is better than spongeforge-1.10.2-2098-6.0.0-BETA-1823. Looks like the lag increase was in fact due to a buggy tile entity from Mekanism or QuantumTanks. |
|
its looking like refined storage and sponge may be causing the issue with hermit pack https://i.gyazo.com/49f7796102cb651250fcfc0871df10b9.png |
|
@Bebabo10 Does that lag occur everytime you go to a specific area? If so, upload your world so I can test it. I also have your old world, if you tell me the location I can see if it occurs. Also, please test the same area with Forge only and let me know if lag persists. |
|
@Vauxite Looks like forestry's swarm is causing most of your lag. Is there a way you can setup a world with JUST forestry and try to reproduce the lag? I can then test it on my end. |
|
Found the issue now its at 20 tps again |
|
@Bebabo10 Please try the same issue without Sponge and let me know if it occurs. I'm curious if Sponge is causing the lag issue. |
|
https://www.dropbox.com/s/r4s2e79mjdwicak/world-hermitpack.zip?dl=1 hope you got good Internet its a 3.8gb world and will test without Forge tomorrow when player count is low |
|
@Bebabo10 What is the lag location? |
|
@Bebabo10 @LemADEC @Vauxite @hunter688 Please test SF 1826. It should solve the chunk unloading issue where performance slowly declines. I also optimized a few areas for chunk lookups. |
|
@bloodmc What do you mean chunk lookup? and it is very difficult to find the source of the lag when your live testing ,will try to get tick profiler to work again to more easily find the locations. |
|
potion fixed with 1830 |
|
We've updated to spongeforge-1.10.2-2107-6.0.0-BETA-0.jar Inventory issue persist with IC2 Jetpacks and weaponcase:weaponsword. No other inventory issue in sight so far. |
|
We had a server hang with spongeforge-1.10.2-2107-6.0.0-BETA-0.jar
A few minutes before that, one player was unable to move his ic2:bronze_leggings. I couldn't reproduce it with my inventory. Rebooting didn't help. Since at least build 1830, we're seeing CME exceptions during world saving: Those exceptions won't show up in log files saved by Forge, for unknown reason, so I'm unable to confirm when it started. We've rolled back to the API 5 bleeding version for now. |
|
Just going to mention that the API 5 bleeding version is not the same as API 5 stable version. Another note: I do have a distaste for Torcherino, mostly because it masks performance by calling additional tile updates: As an example, this is calling neighboring blocks updates, including blocks that generally are unperformant, even if harmless (such as grass or snow). |
|
@Bebabo10 @LemADEC @Vauxite @hunter688 Please test SF 1835 and report back. Also make sure to test with chunk-gc-tick-interval enabled as I've fixed the major issue causing slowdowns with it. Feel free to experiment as well with chunk-unload-delay between 0-30. |
|
@bloodmc fixed in build 1835 |
|
For the record, Torcherino was disabled in all my testings. Lag base still remains chunkloaded, lag is getting better but it's still present on this 2 mn profiling: Inventory issue with Jetpack is still present => is there a separate issue to track it? |
|
nvm #981 https://timings.aikar.co/v2/?id=98743f8f4ccb43c0b8f7ef3109cc9c83&start=1477331947&end=1477332061§ion=lag IC2 tile entities and refined storage again |
|
@LemADEC TrackingUtil simply wraps around each TE tick so we can capture relevant information and the real slowdown is with whatever TE it is showing so I would report to the mod dev as that is not a sponge issue. Report any performance issues with refined storage here |
|
@bloodmc My concern is about java.utils.ArrayList.removeAll taking 14% CPU. To me this indicates chunks are in constant reloading. Have we considered reimplementing the Cauldron (?) trick that disables TE update ticks when no players are in vicinity? |
|
@LemADEC Set the following in your config mob-spawn-range 4 If the issue still occurs, turn on debug logging by setting the following to true Once this is done, simply execute Also upload your world and let me know the location where this lag is occuring and provide a timings report (not warmroast). |
|
@bloodmc timings isn't a valid sub command when I type "/sponge timings" or "/sponge timings -g" To reproduce quickly, I go the lag base (same world and coordinates I've posted last week: -99 91 753), then do 20 times /rtp (using Nucleus plugin, with 30 attempts at 3000 radius), then go back to my base. |
|
@LemADEC For sponge timings the command would be /sponge timings on When done with timings, I still need the output from the chunk load/unload debug. Follow what i said above and report back with the logs. |
|
@bloodmc Server console logger crashed due to the spam so I couldn't get the timings. Here's the logs: |
|
Please remove the link once you've got it. |
|
@LemADEC Thanks, I was able to reproduce the issue. Working on a fix. |
|
@LemADEC Turns out some logic was wrong in my chunkgc handler. I'll be pushing a fix shortly =) Looks like everything is working perfectly now, just need to test a bit more. |
Many mods, including vanilla, tend to leak chunks which end up causing extra processing for our Chunk GC as it has to constantly queue the same chunks for unload everytime. The biggest offending methods are getBlockState and getChunkFromBlockCoords. Both of these methods will load or generate a chunk that does not exist. To avoid this, we now validate the phase and/or state to determine whether or not a chunk request should be allowed to load. Note: This feature can be disabled by setting denyChunkRequests to false in config. * Fix ChunkGC adding duplicate chunks to unload queue. * If chunk unload delay is configured, schedule unloads for chunk leaks. This prevents chunk leaks from immediately unloading at end of tick. Fixes SpongePowered/SpongeForge#968 Fixes SpongePowered/SpongeForge#980
|
@LemADEC Please test latest build and confirm that the lag is fixed. I would recommend keeping the chunk delay at around 15. There were problems with this in earlier builds due to the ChunkGC logic not being correct. I also introduced some optimizations to fight against mods that leak chunks. |
|
I'm pushing a better build, so just wait for next one. |
|
@LemADEC @Bebabo10 @Vauxite @hunter688 Please test SF 1841. It should solve this issue once and for all =). Before you run the build, make sure you change the following defaults in config chunk-gc-tick-interval - 600 The chunk gc will now run once every 30 seconds to cleanup any chunks that leaked. The chunk unload delay is only for player chunks (doesn't affect leaks). So if a chunk that was used by a player is not used within 15 seconds, it unloads. If it gets active before unload, the timer resets. |
|
The lag appears to be gone for the most part. Here's a timings report about Sadly, we're observing a lot of IC2 crashes since we've deployed the latest 2016-10-25 19:43 GMT+02:00 bloodmc notifications@github.com:
|
|
That crash is caused by an IC2 addon not using the API correctly. My guess: calculator. |
|
This is from the FTB HermitPack 1.1.0 version, Calculator isn't part of that pack. However TechReborn and Mekanism are in. |
|
If you update your IC2 version, it will. |
Many mods, including vanilla, tend to leak chunks which end up causing extra processing for our Chunk GC as it has to constantly queue the same chunks for unload everytime. The biggest offending methods are getBlockState and getChunkFromBlockCoords. Both of these methods will load or generate a chunk that does not exist. To avoid this, we now validate the phase and/or state to determine whether or not a chunk request should be allowed to load. Note: This feature can be disabled by setting denyChunkRequests to false in config. * Fix ChunkGC adding duplicate chunks to unload queue. * If chunk unload delay is configured, schedule unloads for chunk leaks. This prevents chunk leaks from immediately unloading at end of tick. Fixes SpongePowered/SpongeForge#968 Fixes SpongePowered/SpongeForge#980 Conflicts: src/main/java/org/spongepowered/common/interfaces/world/gen/IMixinChunkProviderServer.java src/main/java/org/spongepowered/common/mixin/core/world/gen/MixinChunkProviderServer.java
@bloodmc @LemADEC refrencing the hermit pack issue that wasnt resolved in ticket #948
hermit pack warmroast
WarmRoasthermitpack.zip
timings
https://timings.aikar.co/v2/?id=f11ff43a4cd447288ecfab1e069e7991
The text was updated successfully, but these errors were encountered: