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

Discussion in 'Inactive/Unsupported Plugins' started by bergerkiller, Sep 17, 2011.

  1. Offline


    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. :)


    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


    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.


    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.


    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. :)


    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.


    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.


    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.


    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)


    Video by brandcool86


    - 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.

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


    Show your appreciation for my plugins by donating
  2. Offline


    Thanks for trying to help; just wanted to give it out as an FYI, I suppose, that you should only use it after world generation. I'm going to test if it works fine (and it should) when I generate a map before putting it in. :)
  3. Offline


    So that is the problem with the 600-900+ ms after a few hours? What about the chunks turning invisible and require you to go up to them to force them to load? I never had that problem in 1.58-1.59.
  4. Offline


    rtcabooservb it's a client issue, and it happens when it receives chunks faster than it can process. To solve this you can lower the max sending rate.
  5. Offline



    Can you make any suggestions to improve performance. We are using Bukkit #1846 and the latest version of NoLagg (1.62)
    Here is a screenshot and my config.

    Click to enlarge

    Also do we need to include all three BKCommonLib, right now i have 1.01, 1.02, and 1.03.

    Here is my config.

      # Whether or not chunks are unloaded after a set delay
      enabled: true
      # The unload delay in milliseconds
      delay: 10000
      # Whether or not the TNT feature is used
      enabled: true
      # The interval (in ticks) at which TNT is detonated by explosions
      detonationInterval: 1
      # How many TNT is detonated by explosions per interval
      detonationRate: 10
      # The explosion crater size factor
      ExplosionRadiusFactor: 1.0
      # The amount of explosion packets to send to the clients per tick
      explosionRate: 5
      # If TNT explosions can change non-TNT blocks
      changeBlocks: true
      # Whether or not items are buffered (spawned at a later time) in chunks
      enabled: true
      # The maximum amount of items allowed per chunk
      maxPerChunk: 40
      # Whether or not items are stacked to one item
      enabled: true
      # The block radius to look for other items when stacking
      radius: 1.0
      # The amount of (physical) items needed to form one stack
      threshold: 2
    # The tick interval at which the server saves automatically (20 ticks = 1 second)
    autoSaveInterval: 400
    # The tick interval at which NoLagg updates internally (item stacking, buffering and chunk unloading) (20 ticks = 1 second)
    updateInterval: 20
    # The tick interval at which performance information is sent and/or logged (20 ticks = 1 second)
    monitorInterval: 40
    # Whether or not to start logging to the log.txt file when NoLagg enables
    startLoggingOnStartup: false
    # Whether or not the lighting of newly-generated chunks is fixed
    autoFixLighting: false
      # Whether or not the alternative chunk sending alghorithms are used
      enabled: true
      # The minimum chunk sending rate (chunks/tick)
      minRate: 0.25
      # The maximum chunk sending rate (chunks/tick)
      maxRate: 4.0
      # The rate at which chunks are 'triggered' (refreshed, make visible) (trigger packets/tick)
      triggerRate: 0.5
      # The amount of threads to use to compress the chunk packets (increase if it can't keep up)
      sendThreadCount: 2
    # Several shortcuts you can use for the /nolagg clear(all) command
    clearShortcuts: {}
    # Whether or not entity spawn limits are used
    useEntitySpawnLimits: true
    # The general spawn limits (natural spawning)
      # The default spawn limits per world, overridden by world limits
        mob: 400
        animals: 150
        monsters: 250
      # The world-specific spawn limits
      worlds: {}
      # The global spawn limits
        mobs: 400
    # The spawn limits for mob spawners
    # For more information, see
      # The default spawn limits per world, overridden by world limits
      default: {}
      # The global spawn limits
      global: {}
      # The world-specific spawn limits
      worlds: {}
    # The item types (materials) to ignore during item stacking, buffering and spawn limits
    # Use 'orb' to ignore experience orbs
    ignoredItemTypes: []
  6. Offline


    PhunkeyMonkeh you only need the latest version of that library; the newest version will always have backwards compatible and will always be better. (bug fixes, etc.)

    As a test, could you disable the spawn limits once? (useEntitySpawnLimits: false)
    I'd like to know if that has a large (positive) impact on the tick rate, as stated before. If it does, then I'll have to fix it. I am thinking of disabling mob spawning altogether when a lot of entities are denied from spawning. This should use 'bursts' when spawning, reducing possible tick rate loss.

    Other than that, all seems well, maybe increase the 'updateInterval', you had 0.6 ms, which is not much though. Would hardly be a 12 ms duration in total every 20 ticks...not something that can cause the tick rate to suffer.

    PhunkeyMonkeh now looking at it. The CraftScheduler is a nice thing to start at; but I need to replace the entire scheduler with my own implementation @ measure times...this can become tricky since several fields are made hidden. :/


    Ok I found a gap. I will have to replace the Runnable with a wrapper with the Runnable inside, which measures the time it took to execute and reports this back to the monitors. I will have to replace the scheduler to automatically replace all these runnable with the wrapped-version automatically. This will allow me to monitor exactly how much time a plugin takes to execute everything.

    Haha sometimes I am just too awesome...well's awesome when the first idea just works :)
    00:49:48 [INFO] My Worlds: 0.1768 ms
    00:49:48 [INFO] NoLagg: 4.30995 ms
    00:49:48 [INFO] Train Carts: 0.13028 ms
    00:49:48 [INFO] Redstone Mania: 0.0 ms
    00:49:48 [INFO] SignLink: 21.78348 ms
    00:49:48 [INFO] BKCommonLib: 0.0 ms
    Scheduled tasks over 200 ticks.

    Now the events...

    Averus yeah that is normal, the clean-up thread is idle most of the time; it only runs once every 10 seconds. Compare it to the garbage collector threads. The operation scheduler does the same; no lighting being fixed? Nothing to do. I could simply remove the operation scheduler thread if lighting isn't performed, but nah.

    rtcabooservb The only thing that got changed between 1.59 and 1.6 is the chunk sending 'responsiveness', it will now use more accurate sending rates. It's possible that the newer version manages to use a slightly higher sending rate. What is/was your sending rate of your server<>client? (not min or max, but the displayed chunks /tick

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Feb 15, 2019
  7. Offline


    Tick rate has decreased, but that could also be due to an increase in players (65 in last screenshot. 81 in the new one)


    Although the mob numbers have increased from 400 to 3500 approx, and no noticeable descrease in tps.

    I set the update interval to 40, was that too much of a hike?
    Also should we increase the thread numbers.
    Specs are
    i7 2600k
    16gb ram
  8. Offline


    PhunkeyMonkeh ow that's unexpected...after reading of it causing more lag etc. I expected the tick rate to be higher then... xd

    And yeah, I should use 3 or 4 compression threads. You are at 20%, not very dramatic, but it is quite possible that this exceeds 60 several times, not being able to keep up. It would slow down chunk sending.

    Could you post the plugins you use? Something is obviously using commonly-fired events (player_move, chunk_unload) and is performing heavy operations in them; the i7 should easily be able to process that many players.
  9. Offline


    Ok, its a pretty long list...maybe thats half the problem.
    Some of the plugins are custom made also. (but none f the custom ones track chunks, or player movement)

    I set the threads to 3, and put it back to 400 mobs...our players were complaining lol.



    donationtracker (custom)
    dynmap essentials
    essentials spawn
    Junkban (custom)
    junkyardplugins (custom)
    logblock questioner
    bukkitcompat r16b
    multiverse core
    multiverse portals
    permissions bridge
    register 1.5

  10. Offline


    The only thing in this list I consider 'oh that might cause lag' is NoCheat. It performs heavy calculations on the onPlayerMove to check if someone is cheating or not, depending on how accurate this is done, it can cause the tick rate to drop. But, since it is a commonly used plugin, I expect it to be scripted very well.

    I should really build in some sort of performance tester for plugins, to see how much time is spent per tick average in each plugin. I already did this once for events (kinda), but it broke during the newer event systems. So for now, try to remove all plugins and then systematically adding them again, until you notice a tick rate drop.
  11. Offline


    Yeah, its not very easy to do that on a live server lol.
    But if you ever make something to measure efficiency on plugins...please let me know! :)
  12. Offline


    If you ever want to test something on a large'ish server i'd be happy to help.
    Skype - phunkeymonkeh
  13. Offline


    Averus can only really think of the endless respawn cycles though...does disabling monster/animal spawning on the worlds fix this? (server properties: allowanimalspawn and allowmonsterspawn false)
    If this doesn't get rid of the lag, then it is something else. if it still lags, it must be something else...[/quote]
    mob: 10000
        animals: 5000
        item: 200
        monsters: 5000
    whith this i have 3500 mobs 19-21 ticks/sec
    now other, how too use spawn item limiter? if world have 200 items with 200 limit, some blocks dont give drops! every second may have it, maybe coz updaterate 360 ? or else...
  14. Offline


    Averus yeah it would be better to remove the items below the stack instead, right now it cancels the item spawn event as well. I guess that the 'max items per chunk' is better suited for items in this case...
  15. Offline


    turn off mob limit in Nolagg and let us know (also plz try my config and let us know too )
    3090 mobs with 79 ppl ?!? no way
    i have 3500 mobs with 50 ppl

    but 600 items cause 2-3 tick rate drop on my serv its tested, i am now using NoLagg only coz item limit ^) realy, so my limit is 200 items.
    in other ways my serv runnung better without Nolagg but items cause hyge lags if some one drops 100-200 in one "chank" tested too.

    also removing dynmap give me +2-3 ticks on 50+ ppl (no problem with 30+ ppl)
    server + dynmap = good
    server + NoLagg = good
    server + NoLagg + dynmap = -2-3 ticks
    tested with 50-53 ppl on serv
    pls take a look at dynmap+Nolagg (cpu load 25% on 50-60 ppl, 6 core cpu, 56% ram load so its not hardware lag)
    make some changes in Nolagg and dynmap config useless, only turn off dynmap give back some ticks

    Berg, this is normal ? Nolagg sleeps all time (^^)

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Jul 14, 2016
  16. Offline


    :( I don't think you understand what I'm saying. I didn't have this issue in 1.58-1.59 of nolagg and the config value is the same because I increased the chunk sending in 1.58/1.59. Never used clientside mods either.

    4 chunks/tick. 20 TPS. This has always been the same in 1.58/1.59 to 1.62.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Dec 28, 2018
  17. Offline


    rtcabooservb I mean, when you use /lag monitor, what is the sending rate that is displayed for you? (the bottom bit)
    You may want to use 2.0 as maximum, it may prevent some issues.
  18. Offline


    Okay, I will drop it to 2.0 as max to test, but as I said before, it shows 4.0 for me. What about the chunk unload delay? Should I keep it at 10,000?
  19. Offline


    rtcabooservb depends on your RAM vs CPU capability. If you have a very good CPU, you can do without these delays. If your CPU isn't too good and this is not the case, it can help you if you set this to around 10-20 seconds to reduce the amount of loaded and unloaded chunks. (reduce the amount of (de)compressions of data)
  20. Offline


    Do you mind giving me a rundown of what you recommend in the config file? For example, start with the default settings and let me know what to change? I have enough ram and my CPU is pretty fast. If you need the exact specs, I can give them to you.
  21. Offline


    rtcabooservb Well then what are your current issues? Before you start using a performance plugin, always consider what are your current problems. Why do I need this plugin? It's just like any other plugin.

    So, disable everything and then run the server, monitor it if you will. Notice the tick rate heavily breaking combined with very high unloaded chunk counts, chunk unload delays may be of use. Notice the chunks being sent too slowly, or others have this issue? Use the chunk sending feature. Want to allow TNT on your server? Enable that feature. Commonly run into item-client-server-lag related issues (torch spam for example), enable the item buffering/stacking and/or item spawn limits. And so on.

    If you don't need it, don't enable it. Chunk unload delays may reduce the amount of chunks unloaded/loaded, but if your server can handle it, why bother?
  22. Offline


    today i turn off Nolagg plugin and i have 60-80 ppl no laggs as you can see
    with plugin i have 45-50 ppl with 12 ticks, so for me beter without. I would like too help if i can, send some logs, files, my custom server or else...

    also plz plz plz do some mini plugin = 1 command 1 function - like "/nolagg clearall" every 30 mins or 1h, lite, no scans.
  23. Offline


    Averus nah it depends on other parts of the plugin too much to make it 'light'. For now you can disable the plugin; I'm adding tick-rate monitoring features in a later version. I can already monitor the processing times of scheduled tasks, but not yet for events.
  24. Offline


    Wasn't there some commit or something to bukkit recently that sounded like it would add an option to measure execution time of events for plugins? If so, how can I enable that?
  25. Offline


    Borch interested as well...
  26. Offline


    bergerkiller All I could find now is stuff in the SimplePluginManager like a useTimings boolean, and the use of a TimedRegisteredListener in case it is active. No Idea where to grab the gathered data, if this is implemented at all.
    CraftServer does ((SimplePluginManager) pluginManager).useTimings(configuration.getBoolean("settings.plugin-profiling", false)); on startup...

    EDIT: OK apparently you can use the /timings [function] command to write stuff to a file
  27. Offline


    Borch ok, maybe I can hook into it. I want to generate a simple graph containing the time spent for each plugin on the main thread :)
  28. Offline


    Hey bergerkiller
    I just wanted to inform you that Showcase 0.8 which has just been released has a new method isShowcaseItem(Item).
    I've made various performance improvements and this method should be much faster than the previous version.
    Maybe you want to update your plugin.
  29. Offline


    narrowtux Ah thanks, you did that at just the right moment :)
    I already had to fix support in NoLagg (BKCommonLib actually) anyway.

    I'll download your latest version and change the dependency. (I'll put the older call after the try-catch block)
  30. Offline


    Ok, cool.
    The older call (getItemByDrop) should already be pretty fast already, but the new method uses hashmap.containsKey(...) which should be even faster.
  31. Offline


    narrowtux well getting from a hashmap is just as fast as using contains; it's the same operation :)

    But, you can optimize it further if you have to. Already prepared the function for the new call, now waiting for the new version to be permitted by Bukkit Dev staff.

Share This Page