Inactive [FIX/ADMN] NoLagg v1.88.1 - Prevent common lag causes on your server [2338]

I had already made this plugin before after having a major lag issue. (lots of torches being filled, turned into items, lag for 20 minutes) It also works for 1060.

Some feature ideas are taken over from PerformanceTweaks by @LexManos so some credit goes to him. Code, however, written from scratch by me.

Important:

If you get a warning message [NoLagg TLN] followed up with a stack trace in the log, this has to do with the main thread not having responded within 10 seconds. When a plugin takes more than this time to enable, it will show that. The warning is NOT an error and is no bug, and not a bug related to NoLagg. To disable this feature, disable 'threadlocknotifier' in the config.yml. This feature is mainly intended to notify you what plugin is causing the server to freeze, may it ever happen. It is used to debug plugins in general, as they may get stuck for whatever reason.

NoLagg's features in a nutshell

Description

Prevent lag caused by many items

Every time an item gets spawned, it is buffered per chunk. For example, you spawn 30 items using Q and the maximum allowed items per chunk is 20, then the 10 remaining items are not spawned. They are spawned as soon the item count in this chunk is < 20 again.

Read more...

Form item stacks - fully automatically

Whenever two or more (configurable) items or experience orbs get near each other, they form a single stack of that item type. If someone drops 64 dirt blocks on the ground using Q, it will show a single item of 64 dirt instead.

Read more...

Prevent lag caused by TNT

This plugin takes over tnt ignition caused by explosions. When exploding stacks of tnt, it does not rush all tnts into a single tick, but detonate them nicely in sync. This results in pretty awesome fireworks.

Read more...

Prevent lag caused by lighting glitches

Whenever a new chunk is generated, it's lighting information is generated and all nearby players receive the updated chunk data. If the auto-method fails, you can use /nolagg fix to do it manually. This fixing fixes, for example, dark spots in and around caves lagging the client.

Read more...

Set entity spawn limits

You can set a spawn limit on virtually every entity in the game. From mobs to items to TNT. Only thing being excluded is Players, since I can't simply kick someone 'like that'.
Note: It removes already spawned entities too. So, if you want to keep your animals alive, don't set mob or animal limits, or it will possibly clear your farm animals. (or you can disable the spawn limiter all together)

I recommend finding an alternative plugin for this instead. Removing entities after they are spawned causes more lag than it prevents!

Global auto-saver

Since asynchronous chunk saving is now implemented internally, it is no longer a problem to save entire worlds frequently. You can set auto-save intervals in the configuration. If used with an interval higher than 400 ticks (20 seconds) it will use a scheduled task instead of the internal saver to prevent chunks never getting saved. Another benefit is that player information is also auto-saved, preventing your players losing their inventory state.

New chunk sending mechanics

Instead of loading chunks all around the player, the player direction is used to load the visible chunks first. This means that players can expect chunks in front of them to load quickly, while chunks on the sides take a bit longer to appear. When the player looks into another direction, the direction changes and thus the new visible chunks get loaded first. Only if all chunks ahead of the player are loaded, chunks around the player are sent. This all can be configured using a simple minimum and maximum sending rate.

Read more...

Examining the server tick rate

If you encounter very low tick rates and you want to find out what plugin is causing it, you can use the examine component to find it out. It comes with a graphic viewer, which makes bug tracking the easiest thing ever.

Read more...

Prevent cross-thread access for events

As it seems, some plugins don't follow the rules and use Bukkit methods in another thread. This plugin will notify you and cancel if possible whenever this happens so other plugins understand their mistake. If you encounter a lot of spam in the console, first check the stack trace for the plugin that caused the error. Report this error to the author or remove the plugin, if you have questions you are free to ask.



Configuration (on BukkitDev)

Commands and Permissions (on BukkitDev)

Synchronized code accessed by another thread? (BukkitDev)



Media



Video by brandcool86


FAQ

- Help I experience missing chunks
If you are using Spout, don't use Reloads. This is also the reason why Spout added a warning when a player tries to reload the server. Not using Spout, then it's a bug which you can report.

- Can this plugin be used with PTweaks
(this message was really old...) Yes, they are compatible, but if certain features overlap, make sure you disable these features in either plugin.

- I get a warning about the async auto save and interval. Wat do?
Change the autoSaveInterval value in the configuration to a value higher than 400, like 600. The warning is to prevent endless autosaves to occur, clogging up CPU.

- I have experienced CPU usage
CPU usage is not the same as lag. NoLagg uses multiple (2-3) extra threads to prevent tick and network lag. If a lot has to be done, it does this quicker, but this takes more CPU obviously.

- I have lag when using NoLagg
See also the FAQ above. Explain what type of lag you have: tick lag, client lag, network lag and/or 'block placement' lag. You can use /nolagg monitor to check the tick rate. If this is normal (>15), then you have network lag. Client lag is when the FPS drops. Block placement lag is lag when the tick rate is normal and other network messages, like chat, are instant.

- WorldEdit causes lag...
YES because it is unsafe to take over the main thread while another plugin is having hold over it. I can try fixing this, but it could ultimately lead to some serious concurrency exceptions. Don't expect this to be implemented very soon...

- Do spawn limits interfere with mob-spawning plugins like MobArena?
No, it does not. It only limits mobs spawned by 'nature': all custom creature spawns are ignored throughout the run of the plugin. Only after you reload will it lose track of these entities and will it remove custom-spawned mobs. If you use MobArena, be sure nothing is going on when you reload the server.

- Does item stacking interfere with Showcase or BleedingMobs?
It supports Showcase and ShowcaseStandalone entirely. (showcased items are completely ignored at all times) The same applies to the 'particles' created by the BleedingMobs plugin. Know of a plugin where it stacks items which should not be stacked? Post the plugin name so I can add support. You are an owner and want to add support? Only having a function in your plugin to check if an item is 'ignored' is enough.

- Can this plugin be used with Chunk Manager
If you want to use the Chunk Manager with Nolagg, disable the chunk sending of Nolagg first. If you don't do that, this plugin will do that by itself and send a warning in the log. Of course, compare the results first.

- What are the best settings if I have a lot of RAM memory?
This plugin does not deal with reduced RAM memory. If I could, I would, but you simply can't reduce the amount of memory Java uses. This data is locked and secured, so I can't simply throw away bits of data or write and read data from/to disk. Any plugin claiming to reduce RAM usage on a server, is probably 'garbage collecting'. This fakes having less RAM usage by removing unused data, but Java does this by itself as well once it hits a certain limit. All these plugins will do is make the Garbage Collector run in overdrive, which will only kill your tick rate and/or CPU speeds. A bad thing.

- I get a lot of 'Synchronized code accessed from another thread' errors
Find out what plugin is acting up by inspecting the stack trace. If the plugin that causes this is inactive, all you can do is wait for a refurnished version or someone to fix it for you, or use an alternative plugin. If it's still under development, notify the author of this, it IS an error caused by that plugin. If you can't find out the cause, PM me or post in this thread.


Before you begin writing a lag issue

This is very important, just posting a 'it causuz lagz und shitz' won't do, won't help and I won't be able to help you any further either. Question is if I even want to help you, if you post such a message without anything worth looking at. Things to include in your message:
- Errors in the log if possible
- What CB version you use and what NoLagg version you use
- When this lag occurs. Tick rate drop in general?
- The configuration you used when running this plugin
- What type of lag if applicable. Options are: tick lag, client lag, network lag (see above)

Important links

NoLagg Download page and others at Dev Bukkit
View the source code of NoLagg at GitHub

Use an archive extracting program (WinRar, WinZip) to open the archive.

TODO-list:
- Add option to disable physics when the tick delay becomes too high

Changelog

Show your appreciation for my plugins by donating

 

Any news on the reupload?

 

Weeelll I'm kinda stuck; the synchronization keeps on locking up the input queue, making regular inputs have a hard time getting processed...

 

Maybe it'd be a good idea to have a "development" and "stable" branch, or "recommended" as bukkit does.

 

Are you referring to the nolagg plugin or the chunks plugin. If it's the chunks addon, do you think its possible to have something to do with the spout requirement? If it is in fact the chunks addon, it could be possible that maybe try a different way around the synchronization of whatever you are calling into queue.. I'm not sure how you have done the whole chunks addon so I couldn't really tell you. If it is the chunks addon that is causing the problems (which is what it sounds like) the nolagg plugin itself should be good to go?

 

@rbos I know, but for some reason I always notice a bug JUST when I updated it, it's pretty annoying but can't change that xd

@Eminam It's the main NoLagg plugin. Explanation:

What I found is separating the list in two: one is on the main thread and is commonly filled with new data, another is on the saving thread. When the saving thread list is empty and it finds out that there are 'tasks' to do on the main thread, it copies the data over and clears the main thread list. Then it continues on like this.

The problem is that saving/fixing the chunks is almost instant, it only works when a lot of chunks are being processed. I now try to fix this by adding a delay between 'my list is empty' and 'transfer the lists'.

EDIT

Another cause could be the 'restore data from saving queue' feature. It has to loop through (all!) those chunks (200-500 sometimes) every time a chunk loads...I'll use a hashmap there to reduce lag.

 

AHHHH ok, so in a sense it's stepping on itself. At least that is what it sounds like to me anyways. I could be misinterpreting what you are saying though.

I take it this happens when generating new chunks? So lets say you have a world boarder already set and the chunks already rendered and saved. There shouldn't be any problems?

restore data from saving queue <<-- I would start there first. That could be the possible root cause of the problem. I could be wrong but, with server like the one I'm running. There are MANY more chunks then that being loaded at a time. Hash mapping could help reduce some of the tick rate loss from the threading issues. Again, I could be wrong though.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

@Eminam yep if a border is set, it will have no problem with it, since it only happens when exploring areas that have to be generated.

EDIT It restored chunks getting loaded (onChunkLoad) and which are currently queued for saving. It is to prevent chunks to lose data because they were saved before loading.

 

hmm..... perhaps maybe look back at the coding you did for the chunk generation and calls from 1.44 and work from there. I used 1.44 i think before 1.48 and it had no problems. Sometimes finding the solution for a given problem is by back tracking and seeing what you have changed and how to make it stable in a sense. Is it a possibility that you went overboard with the coding and the threading? Making it too complex, causing an issue and the "deadlock"?

 

@Eminam v1.44 didn't use async saving and was having huge lag spikes whenever it went to unload all the (50-100) chunks. I just had to make it async, but it introduced stuff like thread locks.

But no worries, even when having 300 in the queue it doesn't have impact when loading chunks. Hashmap works really well with this. The remaining tick loss is probably caused by the massive chunk generation. (generating 50 chunks is a bit hard ofc...)

EDIT

Yup it's the cause lol...sigh xd

 

shit happens

So I take it you located the problem huh lol

 

Wow that chest wipe bug sucked... lol.
But we still love your plugin @bergerkiller.
Good thing we have hourly backups and LogBlock.

If you don't have a backup and do have LogBlock you can redo all the chest changes by standing near one and typing /lb redo chestaccess since 1 d area 3
(Obviously not everyone has LogBlock but it's a start to fixing things.)
On the other hand the Final Release is coming soon so most of us are planning on genning a new map anyway.

 

I must say, hiccups aside, for server admins this is the best plugin to come down the pike in a LONG time. In terms of reducing player complaints and preventing problems, it's right up there with LWC and WorldGuard.

Good work.

 

@bergerkiller
So you managed to tackle chunk load lag and fix up the issues in the 1.47 build.

 

@ledhead900 Yeah, but it still needed improvements :/
I noticed I was (secretly) sorting all sorts of chunk operations, so now replacing these with a 'ChunkOperation' and 'ChunkScheduler' thread to perform operations in. Uses a mode to sort them. This way lighting fixes are done first, then chunk unload saves, then auto-save saves. I can add chunk generate in here too if I ever manage to make it work.

EDIT

Ok well that is awkward...seems that I have to transfer entities out of chunks during saves, or they become ghosts...sigh

EDIT

Huray for not giving up. Ghost entity issue solved in one strike.

EDIT

Ok updated it, it is a LOT smoother now I used a new way of storing the chunk operations. Also fixes those annoying ghost mobs.

 

Using 1.48 with all settings true. The server ended up loading 100's of items every second. After turning off ItemBuffer and SpawnLimit it stopped. I don't have any settings set for spawn limits while it was true. But autosave was at 800; what would be the cause of that?

 

@silentdojo how do you mean 'loading' items? As in, spawn them randomly in chunks, or increasing 'item buffer' when monitoring? Note that chunks can contain items when they load, so whenever you walk around items, that were in that chunk, will be spawned with the chunk.

 

Yes using the monitor after noticing the console "can't keep up errors" The Entities colum for items was increasing up to 8000 items causing lag. Had to keep on using nolagg clear untill I turned off the ItemBuffer and EntityBuffer options in the config and changed my saveinterval to 1700. So it was one of the 3 just haven't pinpointed the actual cause.

 

@silentdojo mh yeah that can't be right...
Could you set only 'buffer items' to true? If it happens when you do, then I know where to pinpoint the cause.

 

Just tested 1.48.2 and signs are not saving on chunkunload. Haven't tested with chests yet.

Edit. Seems like nothing saves now...

 

@silentdojo works fine here, do you have world saving disabled? (/save-off)

EDIT

Uploaded v.3 of 1.48, you can check if it fixes the chunk unloading issue. Couldn't find anything in the item handler or spawn handler causing endless spawns though.

 

Yeah we don't use /save-off We use a MCtoolkit that does auto saves ever 30 minutes and autorestarts every 4 hours. With all settings true (but never actually set any spawn limits) and a 800 saveinterval is how everything was set. We may have also been using the addon with a sendrate of 2; rest default. I'm thinking it was the saveinterval because I changed it to 1700 when i disabled the other 2 config options. There were 15 users online when the items were showing up on the monitor. And at no time did the ItemBuffer budge from 0. - 1.48.1

As for the problem with things saving like signs (was the main test we did) I can't replicate anymore. What we did was place a sign, write some text, and unload the chunk, came back and just the text was missing. - 1.48.2

 

This plugins screwed my server up

ALL SIGNS and CHEST were WIPED.


.....

 

@silentdojo doh ur right. But why does it only happen if I walk away, and not if I leave and rejoin the server after some time....sigh

Can only be the clearEntities thing, custom implementation time I guess...
Stick with 1.46 for now (friggen tile entities -.-)

 

@bergerkiller (hug) you poor guy lol this plugin is giving you hell huh? You'll get it straightened out you always do man.

 

I can replicate the sign wipe again in 1.48.2 now. Login to our server if ur still up. incraftion.com

Edit: But yeah we rolled back to 1.46 already.

Still a great plugin berg wish you luck and if you need help let us know.

 

@Eminam yeah ;(
First the 'I have lag when using unload delay' issue and now 'Tile entities get wiped' (...)

 

Yessir this is the risk you take with using ANY plugin. As an Admin for a whole year we know how important hourly backups are. Being able to pinpoint exactly what you did to cause it is always a big plus. Rollback to 1.46 and you'll be fine again.

 

It's like it always goes. If it isn't one thing... it's another lol.

 

I know. But, a good plugins author should test his plugins before releasing it to the public

at least test a while

 

@Calvin Alexander I tested for 8 straight hours, never noticed signs getting wiped anywhere. So yeah, now I know what to look out for I can test it. Same as for when people experienced missing chunks, found out after I reloaded while chunks were sent. It's never easy to spot bugs quickly on your own...