Slow wb fill

[korhox]

Hi!

After i start wb fill with a frequency of 5000. It runs at start for 600-100 After about one minute it drops under 100, and slowes down all the time.

What is going on? What I'm doing wrong? Latest log: https://paste.korho.fi/f/wbfillslow.txt Config: https://pastebin.com/TvHRnCrn

I was running on my Multicraft server (self installed to Ubuntu dedicated vps), but i started a server on my local computer to test this.

Computer specs: CPU: AMD Ryzen 7 2700X Eight-Core Processor (should have enough power, running at 15% while generating) RAM: 32GB DDR4, 16GB assinged to server (server not using any near this value) GPU: NVIDIA GeForce GTX 1060 6GB (not even needed) Intel M.2. SSD, and there is enough free space for server

So, what could i do to improve fill speed?

[AntZaro]

I second this. I've been struggling with this problem for the past several days.

I have wb fill running at the default 20 frequency (at first on paper, but now on Spigot because it seemed to do slightly better). Right when I restart, it beings loading a good amount of chunks each message (100-200 just about). Then after just a minute, it'll plummet down to only doing 20-70 chunks each message. Going further, it can decrease to 8 or even zero.

Meanwhile, there are gigabytes of memory available (about 16gb allocated to Minecraft out of 32gb total). We have used this fill feature for many years with this same map size. It typically takes about a full 2 days to generate the world. Currently, we're on day 3 and only at 55%. I'm starting to wonder if it's even worth it at this point.

I'm not sure what it is, but there is no doubt performance is way down from all the previous versions of this plugin.

[korhox]

I'm not sure, but maybe Minecraft spaghetti code of 1.14 is responsible for this?

I don't know very well about 1.14 performance issues, but is it possible that they reflect to this plugin?

[AngryScandinavian]

Happening here too. It can take as little as 15 minutes for the readouts to go from 200-600 to 0-8 every readout. Also the longer the fill command is left to run, the more often a giant red text readout is displayed saying the server is not responding. I am using Paper 1.14.4 build 163, and I'll test on spigot just on that anecdote alone. Using /wb world set 10000 10000 0 0 and /wb world fill 50 0

Edit1: Okay, I have switched over to Spigot 1.14.4, changed the autosave interval from 300 back to the default 30, deleted the configs and allowed them to return to defaults, changes the fill frequency between 50, 100, 1000, and 5000. The large red error hasnt come up in awhile but the chunks being generated is still in the sub-10's with random spikes of over 500.

Edit2: After letting it run for awhile, I notice using Spigot removes a lot of the server running out of RAM messages, even if it is still very slow. I'm using a 3GB ExtraVM server (2700X) for anyone who needs to reference.

[AntZaro]

I'll say that I ended up switching back to paper, as I believe it was just as fast or better than Spigot. I'm running a dedicated server with 32gb of RAM, 512gb SSD, and Intel Xeon E-2134. I have about 15gb dedicated to the Minecraft server.

Curiously, the fill command ran pretty fast generating the End and Nether. However, generation of the overworld was still extremely slow and I was getting all of those red errors saying that the server was not responding (and the TPS would be ridiculously low... like 3-5 many times).

My worlds finally generated, but it took like a week. I think it indeed might be 1.14 because even with chunks all pregenerated, we're getting huge amounts of lag with all the players on the server. It's really a shame that Mojang would put out a final release with such bad performance issues.