Guide Optimizing Paper - Remove lag spikes, Fix tps & Improve performance!

Discussion in 'Paper Discussion' started by frash23, Mar 28, 2016.

  1. oroJefe

    oroJefe New Member

    This guide has been really helpful, but how much memory do I really *need*? That might sound silly, but I've always allocated 16G to our server, simply as the dedicated box has 32G, my rationale was simply 'why not, its not being used'.

    We don't have a huge player base, around 10-20 players at any given time but after making the changes here using G1 etc I've seen far greater fluctuation in memory usage; I understand this is to be expected of course. That said with just 10 players on the server can eat up 10GB+ of its allocated memory, suggesting it wants/needs that? Is there any reason not to just leave it at 16G and let the server seemingly use what it needs, or should I be curtailing down to 6G or 10G? TL;DR is too much allocated memory, a bad thing?
    • Informative Informative x 1
  2. Techcable

    Techcable Benevolent Sith Dictator Administrator Waterfall Core Developer Paper Developer

    The recycler capacity is fixed by waterfall, so that maxCapacity thingy isn't needed.
    • Like Like x 1
  3. Z750

    Z750 Taco King Administrator Paper Core Developer Spigot Staff

    • Like Like x 4
    • Funny Funny x 1
  4. frash23

    frash23 Active Member

  5. TitanicFreak

    TitanicFreak New Member

    That's what this is for, Crazy performance with only an extra plugin, year round of course.
    • Useful Useful x 1
  6. frash23

    frash23 Active Member

    Oh that's real nice - I'll just link this instead.
  7. ediTv2

    ediTv2 New Member

    Any tests done with the item-merge rate with something semi-high? Possibly 5-8, I have entity/item issues so am slightly curious. Wanted to double check if a higher rate would make it even more intensive due to tracking the items in a larger radius.:)
  8. frash23

    frash23 Active Member

    I don't believe setting higher a higher radius should make it slower, though I haven't done any tests on that specifically. (Confirmation @Z750 ?)
    If you believe more items would be merged by setting it higher, it will improve performance.
  9. ediTv2

    ediTv2 New Member

    Yeah that's what I figured, but it crossed my mind that'd it "could" be on the intensive side aswell because it'd have to track a larger radius. I guess time will tell :)
  10. frash23

    frash23 Active Member

    Yeah I completely see your logic, I just doubt it'll negatively affect performance. I'd assume it uses a similar function as Entity#getNearByEntities and considering how frequently it's used in pretty large radii, I doubt it'll be a problem in this case.
  11. tuanjr

    tuanjr Member

  12. Aikar

    Aikar git am FixMinecraft.patch Administrator Paper Core Developer

    With the fix to the exploit and the maxcapacity was pulled into waterfall, you dont even need the maxcap or region size flag.

    those were to prevent an exploit from really killing the servers memory. but they are ok in waterfall now.
  13. frash23

    frash23 Active Member

    Techcable only said the maxCapacity flags was no longer needed, nice to see both of them are no longer needed.
    That should be the task trying to spread out lighting tasks - disabling the lighting-queue option would likely hamper performance even more, though.
    I'd recommend lowering view distance and waiting for a fix for async lighting.
    • Like Like x 1
  14. frash23

    frash23 Active Member

    Thanks, corrected!
    • Like Like x 1
  15. Aikar

    Aikar git am FixMinecraft.patch Administrator Paper Core Developer

    Some mistakes:
    Default is false, Users shouldn't have to ever change this. So you should ust remove this from guide.

    This is not disabled by default. it has 2 methods of trigger. time based and count based. only the count based is removed, and that only really applies to plugins who load a lot of chunks.

    Benefits of making Chunk GC run faster will be conditional, but 300 should be ok.

    And can you link to instead of embedding my explanation in spoiler, as I do occasionally update the stuff.
  16. frash23

    frash23 Active Member

    I saw Tech's comment before you replied to it and assumed it would be changed to the default for backwards compatibility. I guess that's not going to happen, updated.

    Wasn't aware, thanks.
    Would you recommend changing / removing the recommendation?

    Seems like a good idea, updated. Will you be putting your large pages stuff in that post as well?
    Last edited: Apr 4, 2016
  17. RoboMWM

    RoboMWM Moderator Moderator

    Setting this to true apparently comes at the cost of increasing memory. So a tradeoff to consider - especially since the queue could potentially grow larger as more chunks are queued for lighting.
    I think I have this set at 100 or 200 on one of my servers, since 10 seconds is the minimum amount of time a mob spawner would spawn a mob iirc. Of course, those values greatly decrease the ticks it can spawn overall; Byteflux suggested 20 iirc. Also, the spinning model might be "de-synced" with the client, resulting in it still spinning up when a mob has already spawned.
    • Useful Useful x 1
  18. frash23

    frash23 Active Member

    Added note, thanks.
    I forgot how this value works! Thanks for reminding me, updated.
  19. Aikar

    Aikar git am FixMinecraft.patch Administrator Paper Core Developer

    Setting mob spawners that high is unnecessary. Consider that a value of 20 is a 95% reduction in cost, the user experience degradation for a mere 4% more isn't worth it.
    • Like Like x 1
    • Informative Informative x 1
  20. Celebrimbor

    Celebrimbor New Member

    Could one feasibly leave transfer and amount at 8 and 1 respectfully and set check to 24(or higher)? Wouldn't this by itself have a massive impact on hopper CPU drag? The idea being that we leave transfer rate at vanilla (is 8 vanilla?) and just reduce the checking rate, which if I'm not mistaken is a good chunk of the resource demand from a hopper.


Share This Page