When a nether portal is repeatedly lit and broken, nearby players (and possibly whole servers, which I have not tested) can experience increasing amounts of "lag". The lag includes
FPS drops
choppy movement
visual updates skipped (such as for redstone dust and portal tiles)
delayed world interaction (such as breaking blocks or flipping levers)
After a period of time the lag becomes so bad that a permanent loading bar appears and the situation is unrecoverable. The player is still able to move, but cannot break or toggle blocks and cannot open the world menu to exit. It looks like this:
[media]If the contraption is shut off before the point of no return, left off for a long time, and then turned on again, the the lag returns at the same level it was at when the contraption was last run. The only way to reset the built-up lag level is to exit the world.
The lag seems to correlate with a memory leak. Lighting and breaking 1 portal every 8 gt corresponded with the following memory usage as shown by Resource Monitor in Windows (amounts are in MB):
time | Committed | Working | Shareable | Private |
|---|---|---|---|---|
baseline | 767 | 611 | 103 | 507 |
1:00 | 787 | 628 | 103 | 524 |
2:00 | 792 | 633 | 103 | 537 |
3:00 | 802 | 640 | 103 | 541 |
4:00 | 813 | 649 | 103 | 549 |
5:00 | 825 | 660 | 103 | 563 |
10:00 | 879 | 710 | 104 | 611 |
Steps to reproduce
Load
. The world consists of two nether portals with contraptions that repeatedly light and break them. The lighting is done by flint & steel and the breaking is done by dispensers placing water. The redstone is set up to break each portal once every 8 game ticks. The contraption must be shut off when you exit the world or else it will likely break when reloaded. Mob spawning is off to test lag specifically caused by the portals. (There are water trays to carry zombie pigmen if mob spawning is turned on because I had originally built this structure to test gold farm storage.)
Flip the lever at 20, 212, -30 and start a stopwatch.
After a few minutes, start moving around the portals to check on choppiness, or check an FPS meter.
When lag becomes noticeable, flip the lever to shut off the portals.
Move around and/or check FPS.
Flip the lever again.
Expected results
The portals break and re-light without generating lag. Or, if the build does generate lag, the lag is steady and just slows down the game. In step 5 there is no lag, and in step 6 the lag is only as bad as it was shortly after flipping the lever the first time in step 2.
Observed results
Lag increases over time. In step 5 there is no lag, but in step 6 the lag immediately returns to how bad it was just before flipping the lever off in step 4, even if you wait a very long time. If you let the contraption continue to run, the game eventually becomes unrecoverable with a permanent loading bar and the player being unable to flip the lever, break a portal frame, or open the menu to exit.
Linked issues
Attachments
Comments
GoldenHelmet
GoldenHelmet
FWIW I think this may have been the cause behind MCPE-89260.
GoldenHelmet
The rate of lag increase seems to be proportional to the size of the portal. I Tested this with a 2 x 4 portal on a 8 gt light/break cycle, and after about 10 hours my FPS had dropped from 60 to 50 and resource monitor showed just over 1 GB of committed memory. That's about how much my FPS drops from running a max-size portal for 10 minutes. Also, I got the same behavior as with a max sized portal where the FPS returns to normal when the portal lighting/breaking is switched off and immediately jumps back down to where it last was when the portal lighting/breaking is switched on again.
10 hours running a 2 x 4 portal corresponds to about the same number of portal tiles generated and deleted as 10 minutes in a max-size 21 x 21 portal.
Even though the lag is proportional to the number of blocks, it is not due simply to the blocks being changed back and forth. I tested this by using command blocks to fill a 21 x 21 wall with honey and then with air on a 2 game tick cycle. This did not produce any lag at all after after 15-20 minutes.
migrated
I have stress tested on both my personal solo world, and on my personal server, to more accurately pin what the issue might be. I was able to run an overnight afk with a 4 21x21 portal zombie piglin gold farm without any issues on my personal solo world, but the server consistently crashes after 10-15 minutes with the same setup, to the point where it needs to be killed in order to remedy the crash. Seems like it's definitely something to do with the server's memory usage. Hope this helps.
GoldenHelmet
Turns out this issue is caused by the "No Portal Particles" resource pack that is included with the attached test world. The pack has be shared a lot around the community I converse with. I received a hint implying that the pack does not remove portal particles from the game, it only makes them invisible, and also gives them an infinite lifetime. That would explain the increasing lag and memory usage. I retested with and without the pack, and it's definitely the pack causing the problem.
migrated
Possibly confirmed in 1.21.05. Built two large nether portals that lit and unlit quickly, framerate dropped slowly to about 2fps but only when looking at the portals. Breaking the portals did not stop the lag, nor did closing the world. Restarting the game fixes this.
EDIT: This issue was caused by the option that improves input response at the potential cost of performance.
The continually increasing lag and memory usage occurs even if you run the portal breaking and lighting more slowly. I confirmed the issue with 1 portal on 16 gt cycle before reporting. I also observe that
CPU usage does not increase much during the lag
RAM usage does not necessarily max out
GPU usage does down
When the lag becomes unrecoverable with the permanent loading bar, the player can still move and the game does not crash
Based on these observations, it seems to me that each portal lighting or breaking creates a memory artifact that gets reread with each subsequent breaking or lighting of the portal. As that memory artifact grows it causes a client-server communication bottleneck. Both client and server threads are still running, but they cannot update each other because there is too much (junk) data they are trying to pass in each game tick.
It has been suggested to me that portals use "instant pending ticks" to light or break or both, and that instant pending ticks have their own per-game-tick processing cap separate from non-instant pending ticks. That would seem to explain why CPU usage does not max out and the game does not completely crash. It does not explain why there is a memory leak and buildup of lag that does not clear until relog. My guess would be that some or all of the instant pending ticks are not removed from the queue of pending ticks when they are processed, so the game is reading an accumulated list of pending ticks on each tick that it tries to light or break the portal.