NoLagg
Version: 1.90.4 | CB 1.7.2
Quote from lenis0012:NoLagg has not been updated since 1.7.10, for more info, check BKCommonLib
Description
NoLagg is made out of multiple completely separate components which you can enable and disable freely. Together they offer:
- Send chunks more gracefully with lowered network stress and reduced processing spikes Read more...
- Remove entities, resend chunks in case of chunk holes and clean up server memory Read more...
- Examine server tick rate performance with deep view into per-tick processes of the server Read more...
- Stop a large amount of items from spawning and spawn at a later time to avoid frozen clients Read more...
- Stack items with a configurable per-world radius Read more...
- Fix lighting errors that cause clients to recalculate lighting (and thus lag) Read more...
- Keep track of server performance such as entities, tick rate, memory and more Read more...
- Fix various bugs the server has (Patches component)
- Schedule autosaves and force data to be written to disk to prevent data loss on server crash (Saving component)
- Limit the amount of entities allowed to spawn per world or globally Read more...
- Watch events closely to warn when plugins execute main-thread methods from another thread Read more...
- Show a detailed message explaining the cause for a server freeze (lock) [read more]
- New TNT execution algortithm that is not only more efficient, but also avoids server freezes Read more...
Important
When first installing NoLagg, open up config.yml and disable components you do not need. This is very important, as some components may conflict with other plugins you use, or may not function on the type of demand you have. If you get a warning message [Severe] followed up with a stack trace in the log, this has to do with the main thread not having responded within 10 seconds. 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. If NoLagg DOES show up in there, it is a bug you should report.
FAQ
Separating into jar files
NoLagg consists of multiple components you can individually enable and disable. Reasons for not publishing it as a separate jar file for every component can be read here. Please don't ask to separate the components, I will just link you to here.
Spigot server
Not all components are needed when you use the Spigot server. The ItemStacker, ItemBuffer, Spawn Limiter, Thread Checker and Thread Lock Notifier components are not needed, since Spigot has it's own implementations to deal with that. If you still wish to use one of these components, you can, but it's best to disable the Spigot alternative then.
The other components (such as TNT, Chunks, Lighting, Common, etc.) are not implemented in Spigot (yet?) and offer additional functionality.
PTweaks
Since people keep asking about this, I went ahead and compared the two plugins. I am not going to discuss which is better in functionality, I'm just going to state which features overlap and which do not. Both plugins offer a TNT-lag solving solution, feel free to choose which solution you like better. (the solutions are different) Both plugins also offer a way to change when and how chunks are saved, NoLagg adds to this that you can configure when the server writes data to disk. PTweaks offers a way of showing used memory, NoLagg Monitor too with a bit more information. Again, preference. Chunk Persistence is something PTweaks offers and NoLagg does not. Reason I excluded it from NoLagg is that the implementation used up more processing power than that it solved (I did have this for a while). If you want to give it a try, PTweaks is your answer. Monster Limiter is incorporated in NoLagg as well but then for all entities, and more options. ChunkEdits is a tricky one: NoLagg chunks does something similar, with the difference being that it also changes at what rate chunks are sent, which is the main feature NoLagg chunks offers. In addition, the ability to increase the amount of threads running to process chunk packets and the re-using of packet raw data offers some benefits PTweaks does not offer.
Then there are a lot of other features NoLagg has and PTweaks does not, such as examining server tick rate, item stacker, item buffer, fixing lighting, cleaning up server memory, resending chunks, removing entities on command and others (see description).
In short: Both plugins offer some overlapping features, and you need to pay close attention to the configuration of PTweaks and NoLagg and disable things that conflict. Having two TNT explosion altering plugins is going to have strange results, for example. Compare the functionality, decide, and enable in NoLagg what you do not want in PTweaks, and vice versa.
NoLagg showing up in error stack traces
The examine component inserts various hooks into the server to gather measurements. Specifically, you will find that the following lines show up now and then. These hook classes do absolutely nothing when not examining and can not be the cause for any issues, unless the stack trace ends there (first line after the exception shows this stack trace)
- org.timedbukkit.craftbukkit.*
- com.bergerkiller.bukkit.common.internal.ChunkProviderServerHook
Video
Here is a video by BlueDevonMovies (lenis0012):
Metrics
This plugin sends server count statistics to MCStats.org. You can (globally) opt out in the PluginMetrics/config.yml file.
Hi
I got a problem with the neat examine function of your plugin. My examine files are just 16 B large. It seems they arent written correctly or something like that. Does anybody got an idea what may cause this problem?
btw. I mostly examine 500 ticks, so just standard
EDIT: I forgot the error message http://pastebin.com/1q1jVc0A
thanks
@kamuel87 @InfroCZE Hmn I see, I'll go ahead and debug this this afternoon then. I can't let that packet listener support wait much longer either.
I can confirm kamuel87 error. tried enabling chunk loading with bufferedloading and holy mother, so lenghty error log :D Running latest dev builds of BKCL,NoLagg and Spigot.
@bergerkiller
@zeshan321
i tried with latest dev-versions and it works, yes, i can enable the chunkloading, but... i still get the same error if i enable the "bufferedLoader" (i dont use it, but tried)
Edit: but I have slight stuttering when I fly and load the chunks every 2-3 sec and login is slower, until the first chunks load for the first time (trying with vanilla mc) the chunks loads more smoother if its disabled (this was not with 1.6.4 and pre)
@bergerkiller
Same error: http://pastebin.com/mxHY6PsF
Downloaded latest dev build for nolagg, BKCommonLib and protocolib. Also using the latest spigot build.
permission??
Good!
@zeshan321 @kamuel87 Update BKCommonLib to the latest development build right now and do the same for NoLagg, then install ProtocolLib latest development build from their development server for MC 1.7.2.
@Sshadowkraft
@zeshan321
Its the problem with the Chunkload. its broken with and without Protocollib(v3.0.1). without protocollib u get this error too:
[Server thread/ERROR]: [BKCommonLib] [Network] Network handler is DISABLED: All packet handling routines are broken!
temporary solution until its fixed: Disable in nolagg the feature "chunkload" -> chunks: enabled: false (and eventually too: bufferedLoader: enabled: false).
@zeshan321
I have that same problem
Hello, I'm getting this error with spigot when a player joins: http://pastebin.com/RmzQ54uX
@bergerkiller
Yeah I figured that out a few hours ago. xD Well we've been using NoLagg's save feature most of the evening yesterday and so far it's been fabulous! It even pointed out a plugin that was locking the mainthread so I've removed it for now until it can be taken care of.
^.^ Thanks so much for a wonderful plugin! It's doing wonders!
error last dev - http://pastebin.com/ZVbwQwk4
( test with spigot last version , with chunks: true and bufferedLoader: true )
@stgram They should all work as well, as BKCommonLib supports Spigot AND CraftBukkit server software. It needs testing though.
@sakura_blades @sakura_blades Interval saving. When the server is stopped it already saves based on internal logic, there is no need for a manual save before issuing /stop. The only reason it COULD be useful is because stopping the server might crash it because of some malbehaving plugin. You should get that plugin fixed instead of trying to work around it, as this affects other plugins too. (they can't disable and save their state properly)
one more question then... The save, is it designed to run "one last time" when the server goes to restart? Or is it just on an interval thing and no 'quick saves' are done before the server shuts down?
@bergerkiller
:\ Well since we really need this saving issue of ours resolved and NoLagg's save option does seem to be a lot less stressful on the server, I am willing to test it..
If you could please say whether all features in the upcomming update of NoLagg work with Spigot? And if not, which to disable. Thanks.
@sakura_blades Currently there is no way, so you'll have to take my word for it. You can however see whether NoLagg is saving by monitoring the server, it shows [SAVING] next to the tick rate together with a percentage.
You <could> hook up some disk activity monitor and check whether the files are indeed overwritten, or do the hardcore test like I did: kill the server process after nolagg supposedly should've saved and check whether the changes you made are still there.
Is there a way to enable some kind of notification or something to show that my world is being saved by NoLagg? I'd love to disable my server console's save as it's causing problems, but I am concerned with not being able to see that NoLagg is saving the data regularly
@whiteguygears As said, that's clearlagg, not nolagg.
Today I am going to push a few more changes for BKCommonLib, with those included you can then run the development build of NoLagg with BKCommonLib on 1.7.2 without problems, PROVIDING that you install ProtocolLib with it. I will add a proper message on startup so people know what's up. Writing the packet listening/monitoring logic ourselves took longer than I thought.