I have COG setup on my server. At first I had everything set up the way I wanted but COG generated so much lag that the server dropped everyone and I was forced to go in and alter my config. I now have HALF of the config I had before and the lag COG generates on generation of new terrain is still unbearable.
Here is my generation config, please tell me i'm doing something wrong.
We've been down this road before. Please narrow down which distribution(s) are causing the lag.
I assumed that you went on to inspect the 108 block vein yourself and found that it was not, after all, truncated. The question was based on an incorrect assumption of how the deferredPopulationRange option works, and until I have the time to write a proper wiki my only advice is to leave it alone.
We've been down this road before. Please narrow down which distribution(s) are causing the lag.
After extensive testing i can't determine any point of greater impact. I was starting to think the nether ore gen was doing it because it wasn't flagged for a specific dimension, but i checked the wiki and it doesn't look like there's a way to specify a dimension, but after further testing even with no nether ore gen and 75% less distributions the server seems to have the same exact load. once the tick ms goes over 500ms the server starts to spiral downward, the tps drops to 0.8 or lower and the ms keeps going up to around 2000ms even if no more world gen is happening.
more details:
Server is an 8 core machine, with 4 dedicated cores to the server, running with 4 threads, the machine has 32G of ram and 8G of it is dedicated to the server.
When custom ore gen is not installed the server runs normally with no problems.
I have rechecked all id's and confirmed they are all correct, I have tried using specific groups of distributions at the same time to pin point the problem and at the beginning it seemed like there was something specific causing it, now it just seems random.
I am doing further test right now to see if i can narrow it down at all.
These tests were without using any ore from other dimensions. Results:
test 1:
tps=20
ms=6
recoverytime=0 seconds
config:
The results suggest that the config added from test3 had the most impact on the game, but as you can see from test 3 vs test 4, more distributions were added to the config and the tps actually went up and the ms went down, which is inconsistent with the changes made.
Another thing that doesn't make sense is that the distributions of test 3 are some of the rarest ores in the game, so it should have the least impact on the generation.
Inconsistency in testing is a sign that there is a problem with your methods. You would need to run each test on a new world with the same seed and gather a significant amount of data each time before it makes any sense to compare them.
Moving on - disable the wireframes. You can't possibly be using them because with that many distributions at those frequencies that you would see nothing but a yellow mess. Wireframe data chews up memory on the server, and it may be contributing to your problem.
Inconsistency in testing is a sign that there is a problem with your methods. You would need to run each test on a new world with the same seed and gather a significant amount of data each time before it makes any sense to compare them.
Moving on - disable the wireframes. You can't possibly be using them because with that many distributions at those frequencies that you would see nothing but a yellow mess. Wireframe data chews up memory on the server, and it may be contributing to your problem.
Each test was done on a new world, with the same seed, with 2 people who run from a specified point A to a specified point B. Once both players reach their point B's, they stop moving and do nothing while I monitor the servers tick rate, latency, and recovery time from the world gen overload.
I will disable wireframes and test, i didn't know they had any effect if I was not in debug mode. If this is the cause, it would make perfect sense since I am using the wireframe on ALL of the vein distributions. (I was checking the distance of ore from one another when using ores, because I don't want a lot of different ores near the same point. With my currently frequency settings, there is actually not yellow spammy wireframes everywhere, but if the frequency was higher yea, you wouldn't be able to see anything.)
Tested with wireframes removed, almost exact same result. Guess that wasn't the problem.
Each test was done on a new world, with the same seed, with 2 people who run from a specified point A to a specified point B. Once both players reach their point B's, they stop moving and do nothing while I monitor the servers tick rate, latency, and recovery time from the world gen overload.
I will disable wireframes and test, i didn't know they had any effect if I was not in debug mode. If this is the cause, it would make perfect sense since I am using the wireframe on ALL of the vein distributions. (I was checking the distance of ore from one another when using ores, because I don't want a lot of different ores near the same point. With my currently frequency settings, there is actually not yellow spammy wireframes everywhere, but if the frequency was higher yea, you wouldn't be able to see anything.)
Run the same test multiple times. If your results are not consistent then there is an uncontrolled variable somewhere. Once you have a way to consistently reproduce the problem we can proceed.
For the record wireframes will not consume memory when debugging mode is off, but you should disable them anyway to eliminate the possibility.
Run the same test multiple times. If your results are not consistent then there is an uncontrolled variable somewhere. Once you have a way to consistently reproduce the problem we can proceed.
For the record wireframes will not consume memory when debugging mode is off, but you should disable them anyway to eliminate the possibility.
Here is something consistent: No matter what distributions are in the config *excluding dimensional ores .. haven't tested yet). The server never fully recovers, it normally runs at about 10ms consistently, but when we do the test it starts at 10ms and goes up to whatever it goes up to. Then when we watch the recovery time, it has NEVER gone back below 60ms and the server continually reports the overloaded message even when the server is showing it's not overloaded. However, after a server restart the ms is back to 10 and everything that has been generated works fine. It only starts acting up again once we start genning more world again. Too bad noone has created a mod(that works with the latest ver of minecraft) to pre-generate a specified amount of chunks around the spawn.
summary: restarting the server fixes whatever is continually causing performance problems after any world gen.
No matter what distributions are in the config (excluding dimensional ores .. haven't tested yet). The server never fully recovers, it normally runs at about 10ms consistently, but when we do the test it starts at 10ms and goes up to whatever it goes up to. Then when we watch the recovery time, it has NEVER gone back below 60ms and the server continually reports the overloaded message even when the server is showing it's not overloaded.
Am I to understand that this happens even if you use the standard COG config instead of your own?
Here is something consistent: No matter what distributions are in the config *excluding dimensional ores .. haven't tested yet). The server never fully recovers, it normally runs at about 10ms consistently, but when we do the test it starts at 10ms and goes up to whatever it goes up to. Then when we watch the recovery time, it has NEVER gone back below 60ms and the server continually reports the overloaded message even when the server is showing it's not overloaded. However, after a server restart the ms is back to 10 and everything that has been generated works fine. It only starts acting up again once we start genning more world again. Too bad noone has created a mod(that works with the latest ver of minecraft) to pre-generate a specified amount of chunks around the spawn.
summary: restarting the server fixes whatever is continually causing performance problems after any world gen.
Number one: As I understand it, COG can force generation of chunks during population.
If you stand at spawn, and type (I think)
/cogPopulate 100
then it will generate 100 chunks in each direction around you.
Warning: This will probably kill your memory.
The next thing you point to -- overhead time going up, and then not going back down -- sounds like what I was seeing during memory testing. Basically, the default garbage collection assumptions stink for Minecraft.
Look at http://www.minecraft...-and-minecraft/ -- it's a work in progress, but should give you hints on getting started. You must -- MUST -- ask Java to report memory statistics, and watch it. It certainly looks like you are seeing something causing Java's memory to become worse than normal.
I assumed that you went on to inspect the 108 block vein yourself and found that it was not, after all, truncated. The question was based on an incorrect assumption of how the deferredPopulationRange option works, and until I have the time to write a proper wiki my only advice is to leave it alone.
It was during regeneration of already existing chunks around spawn, so I knew that the chunks would have been existing, and the vein intact. I was just curious if it would have worked at the edge of "explored space". Since you now confirm that it does work, dPR does not work the way I think, and it's "don't touch it", I'm fine
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Number one: As I understand it, COG can force generation of chunks during population.
If you stand at spawn, and type (I think)
/cogPopulate 100
then it will generate 100 chunks in each direction around you.
Warning: This will probably kill your memory.
The next thing you point to -- overhead time going up, and then not going back down -- sounds like what I was seeing during memory testing. Basically, the default garbage collection assumptions stink for Minecraft.
Look at http://www.minecraft...-and-minecraft/ -- it's a work in progress, but should give you hints on getting started. You must -- MUST -- ask Java to report memory statistics, and watch it. It certainly looks like you are seeing something causing Java's memory to become worse than normal.
I appreciate your help!
heres some info:
The generating a lot of chunks taking a lot of memory: I can allocate 30G of memory to the server if need be. I tried the cogPopulate command and it says "You do not have permission to use this command". I am opped on the server and i tried in creative mode.
Yea, the ms goes up and DOES go back down, it just never goes back down to where it's supposed to be. I found that restarting the server fixes it until new world gen happens. I also found out a second ago that if you die and go back to spawn the ms goes back to normal, then if you run back to where you died (already generated) the ms goes back up to the same levels where it wasn't going down any further again.
I am actually running the server with all of the advanced garbage collection flags
I will attempt the link you sent if i can't get this working at any optimal level.
Yes, that is correct. After world genning with pure vanilla COG, the ms goes up, and then never goes back down. It sits at the same exact level as every other test. All test increase to 80+ then they go back down to 60 and hang around 60 never getting any better until the players in the world go back to the spawn. The closer to the spawn the players get, the better the ms gets, when both players are a spawn, it's at 3ms, when both players are 1000 blocks in opposite directions from the spawn the ms hangs around 60 and the server continually spams the server overloaded message, however the server load meter shows stable load.
Restarting the server: players re-join in the same 1000 block position and the ms varies between 15-25ms. Going back to the spawn area or any previously generated chunks puts ms at 3-10ms.
Testing without COG:
tps=13
ms=40
recoverytime=0 seconds
config: none
At the end of the test without COG, vanilla sits at 15-25ms, which is where the ms changes to after a restart of the server when using COG.
After a restart without COG the ms is still 15-25. Returning to the spawn puts ms at 3 still.
If your interested, you can watch the server stats live here:
I'm also on TS: grimshad.doesntexist.com
if you want to speak with me directly about it.
just streamed this test with COG and all ores + other dimensions:
Hello, I do not understand how to configure this mod to generate IC2 ores differently so I am asking someone to do it for me, if someone doesn't mind.
So first of all, I don't know how copper, tin, and uranium are distributed in real life, so if someone could tell me, that would be great.
Using the way they are distributed in real life, I need to configure this mod so that it generates the ores the way they do in real life in the world. I am getting this mod because it makes minecraft more realistic so if someone could help me with these 3 mod ores, that would be great.
I think the ID for these 3 ores were 247,248, and 249 but I don't remember which ore was which ID.
The generating a lot of chunks taking a lot of memory: I can allocate 30G of memory to the server if need be. I tried the cogPopulate command and it says "You do not have permission to use this command". I am opped on the server and i tried in creative mode.
Beyond me. Anyone else?
I am actually running the server with all of the advanced garbage collection flags
Since it does matter, can you give me your server's command line?
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
13 ticks per second, approximately 80 ms per tick (normally 50 ms or less per tick)
What is "recovery time"?
What mod are you using for stat reporting?
Recovery time is the amount of time it takes for the server to go from the overloaded state back to the stable state. Which is going from 100+% load to 10% load usually. Normally this should take about 1-2 seconds, but it has been taking minutes or in same cases like with ores from other dimensions enabled.. it never recovers.
I am use the Ticks Per Second mod + the server stats for checking and a stop watch for timing
Hello, I do not understand how to configure this mod to generate IC2 ores differently so I am asking someone to do it for me, if someone doesn't mind.
Umm... Can someone help me make settings for the Infused Stone and Ores from Thaumcraft 3? ^-^" My brain is too feeble to understand how all the stuff strings together and such... ^-^" Like, I understand how to get the certain block ID and the "only if this certain mod is installed" kinda thing, but everything else to me just runs together into gibberish... ^-^"
Edit:
Well, I know what I want it to do, but I don't know who to make it do it is more of what I mean... Like I want the Water-Infused Stone to generate in smallish veins in Ocean, Ice Plains, Swamp, and Taiga biomes, but I have no such idea of how to write it into the config, or even which config to put it in...
If you would like me to explain the rest of them, I don't mind, but I really would like some help setting them up. ^-^"
Recovery time is the amount of time it takes for the server to go from the overloaded state back to the stable state. Which is going from 100+% load to 10% load usually. Normally this should take about 1-2 seconds, but it has been taking minutes or in same cases like with ores from other dimensions enabled.. it never recovers.
I am use the Ticks Per Second mod + the server stats for checking and a stop watch for timing
Hello, I do not understand how to configure this mod to generate IC2 ores differently so I am asking someone to do it for me, if someone doesn't mind.
I won't do it for you, but I did post a short example of how to add ores to the config here. You should be able to find the block IDs for IC2 ores in your IC2 config file, and you can see them in-game in the creative menu if you enable item details with F3+H.
Yea, the ms goes up and DOES go back down, it just never goes back down to where it's supposed to be. I found that restarting the server fixes it until new world gen happens.
My own server tests show that, while COG does have an impact on server latency during chunk generation, everything quickly returns to normal once new chunks stop generating. You are reporting that performance remains laggy even after all players have stopped moving. That could be memory related, but I have not seen anything like it myself.
Repeat the test twice, once with the standard COG config and once with COG uninstalled. Take a 4 screencaps like the one above during each test: 1 at spawn before starting, 1 while the player is moving and new chunks are generating, 1 after the player has reached their destination and remained still (wait at least a minute) and 1 after the player has returned to spawn (wait another minute). Post the 8 images back here and we will go from there.
Ok. I'm assuming you have two cores (I think you said 1+1).
You're using 8 GB for memory. Got it.
You're already using CMS/parallel new. Good.
I'm not sure whether incremental is going to be a good thing or not. You have a second core that the server cannot use. Letting the CMS collector run non-stop when needed may be better than the incremental. Can't tell without some numbers.
We need a couple of more debugging flags.
And, I want to get a handle on "eden".
That should give us 1gib for new, 200 mib each for survivor, and 600 mib for eden. That's what "Dynamic Maps" needs to avoid going crazy. It was more than enough for me to repopulate a 1024x1024 section without any problem. It also will go up to 8 gig total, but only as needed -- so we can see if there actually is a constant increase in memory consumption.
(Remember: We don't want more than 50% surplus in long-term, but we really do not want less; 100% surplus is too much. We want as much in eden as we can get.)
-XX:+UseCompressedOops -- according to the documentation, optimizes the 64 bit system when less than 32gib of heap is used
Most importantly, it will log the output. You'll see things like:
{Heap before GC invocations=1592 (full 318):
par new generation total 89600K, used 79789K [0000000009800000, 000000000fc00000, 000000000fc00000)
eden space 76800K, 100% used [0000000009800000, 000000000e300000, 000000000e300000)
from space 12800K, 23% used [000000000e300000, 000000000e5eb660, 000000000ef80000)
to space 12800K, 0% used [000000000ef80000, 000000000ef80000, 000000000fc00000)
concurrent mark-sweep generation total 207608K, used 110344K [000000000fc00000, 000000001c6be000, 0000000028c00000)
concurrent-mark-sweep perm gen total 30964K, used 27161K [0000000028c00000, 000000002aa3d000, 000000002cc00000)
8177.967: [GC 8177.967: [ParNew
Desired survivor size 6553600 bytes, new threshold 1 (max 4)
- age 1: 11057712 bytes, 11057712 total
- age 2: 1794528 bytes, 12852240 total
- age 3: 42296 bytes, 12894536 total
- age 4: 131808 bytes, 13026344 total
: 79789K->12800K(89600K), 0.0248735 secs] 190134K->147974K(297208K), 0.0249326 secs] [Times: user=0.05 sys=0.02, real=0.03 secs]
Heap after GC invocations=1593 (full 318):
par new generation total 89600K, used 12800K [0000000009800000, 000000000fc00000, 000000000fc00000)
eden space 76800K, 0% used [0000000009800000, 0000000009800000, 000000000e300000)
from space 12800K, 100% used [000000000ef80000, 000000000fc00000, 000000000fc00000)
to space 12800K, 0% used [000000000e300000, 000000000e300000, 000000000ef80000)
concurrent mark-sweep generation total 207608K, used 135174K [000000000fc00000, 000000001c6be000, 0000000028c00000)
concurrent-mark-sweep perm gen total 30964K, used 27161K [0000000028c00000, 000000002aa3d000, 000000002cc00000)
}
On the line:
concurrent mark-sweep generation total 207608K, used 135174K [000000000fc00000, 000000001c6be000, 0000000028c00000)
the tenured space is 135174K -- that's the long-term data usage.
On the line:
- age 4: 131808 bytes, 13026344 total
that's how much space has been promoted from "new" to "tenured".
Compare to the line:
Desired survivor size 6553600 bytes, new threshold 1 (max 4)
You want to see "new threshold" the same as max.
You want to see the "age 3" line 'total' value below that desired survivor size.
On the line:
from space 12800K, 100% used [000000000ef80000, 000000000fc00000, 000000000fc00000)
(That's in the "After" section)
the 100% used means that there is too much memory being produced for short-term. (This sample comes from a run with a much lower cutoff level.)
You want to see this below 66%.
Lets see some numbers.
600 MB of eden -- those numbers I gave you -- should give very infrequent GC of eden space.
The less often eden collects, the better -- it means more time for objects to die.
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I'm just about to update my server to 1.4.5 from 1.4.2... do I need to retool my COG config from 1.4.2 at all or can I just drop it in for 1.4.5 and everything should work as per before. I read in the changelog you split the config into 2 files... so I'm just wonderin' (and a little worried) I'll have to rework my config.
You're using 8 GB for memory. Got it.
You're already using CMS/parallel new. Good.
I'm not sure whether incremental is going to be a good thing or not. You have a second core that the server cannot use. Letting the CMS collector run non-stop when needed may be better than the incremental. Can't tell without some numbers.
To be honest it doesn't seem to matter how much memory I allocate, the server only ever uses a maximum of 512mb at any given time, I give it 2G or 4G or 8G or 16G and it always runs at exactly the same performance.
I am entering unknown territory here, I don't know what any of this stuff does, but i'll throw it in my bat and see if I get improved performance.
EDIT: Wow, whatever this stuff does, it significantly increased server performance. It now runs at 10-20% load rather than 75% load, recovers much faster, and rarely goes into the red anymore.
I would like to continue this conversation, but I have fixed the COG portion of my performance issues and don't want to be offtopic here in the COG thread, so could you please PM me your reply
That should give us 1gib for new, 200 mib each for survivor, and 600 mib for eden. That's what "Dynamic Maps" needs to avoid going crazy. It was more than enough for me to repopulate a 1024x1024 section without any problem. It also will go up to 8 gig total, but only as needed -- so we can see if there actually is a constant increase in memory consumption.
I really want to try this repopulate thing, but COG continues to tell me that I do not have permission to use the command. I am opped and I also tried it in creative mode, is there anything special in the config I have to do to be able to use the command?
Repeat the test twice, once with the standard COG config and once with COG uninstalled. Take a 4 screencaps like the one above during each test: 1 at spawn before starting, 1 while the player is moving and new chunks are generating, 1 after the player has reached their destination and remained still (wait at least a minute) and 1 after the player has returned to spawn (wait another minute). Post the 8 images back here and we will go from there.
If you still want me to do this I will, however, I figured out some of the performance issues already. While COG does have a performance hit on the server (especially with ores from other dimensions), it was not the root of the problem. It turns out the version of ExtraBiomesXL was conflicting with COG and causing my headache. I have since updated ExtraBiomesXL and performance has gotten _much_ better. With ExtraBiomesXL disabled and COG enabled performance is stable and recovery time is quick.
I appreciate all of your help Jroush. I hope I didn't waste any of your time.
I'm just about to update my server to 1.4.5 from 1.4.2... do I need to retool my COG config from 1.4.2 at all or can I just drop it in for 1.4.5 and everything should work as per before. I read in the changelog you split the config into 2 files... so I'm just wonderin' (and a little worried) I'll have to rework my config.
There have been no breaking changes to the config file syntax. You can (and probably should) continue using your original config file with existing worlds. Good luck with the update
I really want to try this repopulate thing, but COG continues to tell me that I do not have permission to use the command. I am opped and I also tried it in creative mode, is there anything special in the config I have to do to be able to use the command?
Debugging commands require a world reference, so they can only be executed by players at the moment. You will be able to use the commands directly from the server console in the next version.
If you still want me to do this I will, however, I figured out some of the performance issues already. While COG does have a performance hit on the server (especially with ores from other dimensions), it was not the root of the problem. It turns out the version of ExtraBiomesXL was conflicting with COG and causing my headache. I have since updated ExtraBiomesXL and performance has gotten _much_ better. With ExtraBiomesXL disabled and COG enabled performance is stable and recovery time is quick.
Ah, I remember that bug. It was something in vanilla minecraft that ExtraBiomesXL triggered, causing runaway chunk generation. I believe it was fixed a while ago (1.4.4?). I'm glad the problem has been resolved; let me know if you have any other issues.
I assumed that you went on to inspect the 108 block vein yourself and found that it was not, after all, truncated. The question was based on an incorrect assumption of how the deferredPopulationRange option works, and until I have the time to write a proper wiki my only advice is to leave it alone.
After extensive testing i can't determine any point of greater impact. I was starting to think the nether ore gen was doing it because it wasn't flagged for a specific dimension, but i checked the wiki and it doesn't look like there's a way to specify a dimension, but after further testing even with no nether ore gen and 75% less distributions the server seems to have the same exact load. once the tick ms goes over 500ms the server starts to spiral downward, the tps drops to 0.8 or lower and the ms keeps going up to around 2000ms even if no more world gen is happening.
more details:
Server is an 8 core machine, with 4 dedicated cores to the server, running with 4 threads, the machine has 32G of ram and 8G of it is dedicated to the server.
When custom ore gen is not installed the server runs normally with no problems.
I have rechecked all id's and confirmed they are all correct, I have tried using specific groups of distributions at the same time to pin point the problem and at the beginning it seemed like there was something specific causing it, now it just seems random.
I am doing further test right now to see if i can narrow it down at all.
These tests were without using any ore from other dimensions.
Results:
test 1:
tps=20
ms=6
recoverytime=0 seconds
config:
<Veins name='overworlddef' block='220:5' inherits='PresetLayeredVeins'>
<DrawWireframe>true</DrawWireframe>
<WireframeColor>0xFFFFD000</WireframeColor>
<Setting name='MotherlodeFrequency' avg='0.027'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Setting name='MotherlodeSize' avg='2' range='1'/>
<Setting name='BranchFrequency' avg='3' range='2'/>
<Setting name='OreDensity' avg='1' range='0'/>
<Replaces block='stone'/>
</Veins>
<Veins block='1819:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.027'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='2001:3' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.027'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
<Cloud name='Uranium' block='3676:0' inherits='PresetStrategicCloud'>
<Setting name='DistributionFrequency' avg='0.03'/>
<Setting name='CloudRadius' avg='1' range='1'/>
<Setting name='CloudThickness' avg='1' range='1'/>
<Setting name='CloudHeight' avg='10' range='5'/>
<Setting name='OreRadiusMult' avg='1' range='1'/>
<Setting name='OreDensity' avg='0.5'/>
<Setting name='OreVolumeNoiseCutoff' avg='0'/>
</Cloud>
<Cloud name='Iridium' block='4019:2' inherits='PresetStrategicCloud'>
<Setting name='DistributionFrequency' avg='0.03'/>
<Setting name='CloudRadius' avg='0.5' range='1'/>
<Setting name='CloudThickness' avg='0.5' range='1'/>
<Setting name='CloudHeight' avg='10' range='5'/>
<Setting name='OreRadiusMult' avg='1' range='1'/>
<Setting name='OreDensity' avg='1'/>
<Setting name='OreVolumeNoiseCutoff' avg='0'/>
</Cloud>
<Veins block='4019:3' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.020'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Biome name='Desert'/>
<Biome name='DesertHills'/>
<Replaces block='stone'/>
</Veins>
<Veins block='4019:4' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.020'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Biome name='Ocean'/>
<Biome name='FrozenOcean'/>
<Replaces block='stone'/>
</Veins>
<Veins block='4019:5' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.65'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Biome name='Forest'/>
<Biome name='Plains'/>
<Replaces block='stone'/>
</Veins>
test 2:
tps=17
ms=50
recoverytime=2 seconds
added to config:
<Veins block='919:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.065'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='919:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.052'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='919:2' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.008'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='954' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.021'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='954:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.016'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='954:2' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.005'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.021'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
test 3:
tps=3
ms=850
recoverytime=60 seconds
added to config:
<Veins block='925:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.011'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:2' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.007'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:3' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.006'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:4' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.006'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:5' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.005'/>
<Setting name='MotherlodeHeight' avg='20' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:6' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.005'/>
<Setting name='MotherlodeHeight' avg='20' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:7' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.005'/>
<Setting name='MotherlodeHeight' avg='20' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:8' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.003'/>
<Setting name='MotherlodeHeight' avg='20' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:9' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.004'/>
<Setting name='MotherlodeHeight' avg='10' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:10' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.002'/>
<Setting name='MotherlodeHeight' avg='10' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='925:11' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.002'/>
<Setting name='MotherlodeHeight' avg='10' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='957:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.008'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
test 4:
tps=4
ms=400
recoverytime=80 seconds
added to config:
<Veins block='957:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.016'/>
<Setting name='MotherlodeHeight' avg='80' range='20'/>
<Replaces block='stone'/>
</Veins>
<Veins block='957:2' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.016'/>
<Setting name='MotherlodeHeight' avg='80' range='20'/>
<Replaces block='stone'/>
</Veins>
<Veins block='957:3' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.008'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='957:4' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.008'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
<Veins block='957:5' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.008'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Replaces block='stone'/>
</Veins>
The results suggest that the config added from test3 had the most impact on the game, but as you can see from test 3 vs test 4, more distributions were added to the config and the tps actually went up and the ms went down, which is inconsistent with the changes made.
Another thing that doesn't make sense is that the distributions of test 3 are some of the rarest ores in the game, so it should have the least impact on the generation.
test 5:
tps=3
ms=300
recoverytime=45 seconds
Config: test1 + test2 + test4
test 6: Added other dimensions
tps=0.4
ms=2500
recoverytime=never recovers
config: test1 + test2 + test 4 + added:
<Veins block='4011:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.06'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.007'/>
<Setting name='MotherlodeHeight' avg='10' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:2' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.012'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:3' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.027'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:4' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.020'/>
<Setting name='MotherlodeHeight' avg='40' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:5' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.012'/>
<Setting name='MotherlodeHeight' avg='40' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:6' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.042'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4011:7' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.050'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='930:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.014'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Biome name='Sky'/>
</Veins>
<Veins block='930:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.005'/>
<Setting name='MotherlodeHeight' avg='50' range='16'/>
<Biome name='Sky'/>
<Replaces block='121'/>
</Veins>
<Veins block='937:0' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.046'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:1' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.033'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:2' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.021'/>
<Setting name='MotherlodeHeight' avg='40' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:3' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.019'/>
<Setting name='MotherlodeHeight' avg='40' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:4' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.008'/>
<Setting name='MotherlodeHeight' avg='40' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:5' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.006'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:6' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.003'/>
<Setting name='MotherlodeHeight' avg='10' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:7' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.003'/>
<Setting name='MotherlodeHeight' avg='10' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:8' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.02'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='937:9' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.006'/>
<Setting name='MotherlodeHeight' avg='40' range='16'/>
<Biome name='Hell'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4019:6' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.35'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4019:7' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.15'/>
<Setting name='MotherlodeHeight' avg='32' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4019:8' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.20'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='hellrock'/>
</Veins>
<Veins block='4019:9' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.27'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='121'/>
</Veins>
<Veins block='4019:10' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.27'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='121'/>
</Veins>
<Veins block='4019:11' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.27'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='121'/>
</Veins>
<Veins block='4019:12' inherits='overworlddef'>
<Setting name='MotherlodeFrequency' avg='0.27'/>
<Setting name='MotherlodeHeight' avg='64' range='16'/>
<Replaces block='121'/>
</Veins>
I Just realized all these tests are flawed because I didn't separate the id's correctly.
Moving on - disable the wireframes. You can't possibly be using them because with that many distributions at those frequencies that you would see nothing but a yellow mess. Wireframe data chews up memory on the server, and it may be contributing to your problem.
Each test was done on a new world, with the same seed, with 2 people who run from a specified point A to a specified point B. Once both players reach their point B's, they stop moving and do nothing while I monitor the servers tick rate, latency, and recovery time from the world gen overload.
I will disable wireframes and test, i didn't know they had any effect if I was not in debug mode. If this is the cause, it would make perfect sense since I am using the wireframe on ALL of the vein distributions. (I was checking the distance of ore from one another when using ores, because I don't want a lot of different ores near the same point. With my currently frequency settings, there is actually not yellow spammy wireframes everywhere, but if the frequency was higher yea, you wouldn't be able to see anything.)
Tested with wireframes removed, almost exact same result. Guess that wasn't the problem.
For the record wireframes will not consume memory when debugging mode is off, but you should disable them anyway to eliminate the possibility.
Here is something consistent: No matter what distributions are in the config *excluding dimensional ores .. haven't tested yet). The server never fully recovers, it normally runs at about 10ms consistently, but when we do the test it starts at 10ms and goes up to whatever it goes up to. Then when we watch the recovery time, it has NEVER gone back below 60ms and the server continually reports the overloaded message even when the server is showing it's not overloaded. However, after a server restart the ms is back to 10 and everything that has been generated works fine. It only starts acting up again once we start genning more world again. Too bad noone has created a mod(that works with the latest ver of minecraft) to pre-generate a specified amount of chunks around the spawn.
summary: restarting the server fixes whatever is continually causing performance problems after any world gen.
Number one: As I understand it, COG can force generation of chunks during population.
If you stand at spawn, and type (I think)
/cogPopulate 100
then it will generate 100 chunks in each direction around you.
Warning: This will probably kill your memory.
The next thing you point to -- overhead time going up, and then not going back down -- sounds like what I was seeing during memory testing. Basically, the default garbage collection assumptions stink for Minecraft.
Look at http://www.minecraft...-and-minecraft/ -- it's a work in progress, but should give you hints on getting started. You must -- MUST -- ask Java to report memory statistics, and watch it. It certainly looks like you are seeing something causing Java's memory to become worse than normal.
It was during regeneration of already existing chunks around spawn, so I knew that the chunks would have been existing, and the vein intact. I was just curious if it would have worked at the edge of "explored space". Since you now confirm that it does work, dPR does not work the way I think, and it's "don't touch it", I'm fine
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I appreciate your help!
heres some info:
The generating a lot of chunks taking a lot of memory: I can allocate 30G of memory to the server if need be. I tried the cogPopulate command and it says "You do not have permission to use this command". I am opped on the server and i tried in creative mode.
Yea, the ms goes up and DOES go back down, it just never goes back down to where it's supposed to be. I found that restarting the server fixes it until new world gen happens. I also found out a second ago that if you die and go back to spawn the ms goes back to normal, then if you run back to where you died (already generated) the ms goes back up to the same levels where it wasn't going down any further again.
I am actually running the server with all of the advanced garbage collection flags
I will attempt the link you sent if i can't get this working at any optimal level.
Vanilla COG test:
tps=13
ms=80
recoverytime=2 seconds
Config: Vanilla
Yes, that is correct. After world genning with pure vanilla COG, the ms goes up, and then never goes back down. It sits at the same exact level as every other test. All test increase to 80+ then they go back down to 60 and hang around 60 never getting any better until the players in the world go back to the spawn. The closer to the spawn the players get, the better the ms gets, when both players are a spawn, it's at 3ms, when both players are 1000 blocks in opposite directions from the spawn the ms hangs around 60 and the server continually spams the server overloaded message, however the server load meter shows stable load.
Restarting the server: players re-join in the same 1000 block position and the ms varies between 15-25ms. Going back to the spawn area or any previously generated chunks puts ms at 3-10ms.
Testing without COG:
tps=13
ms=40
recoverytime=0 seconds
config: none
At the end of the test without COG, vanilla sits at 15-25ms, which is where the ms changes to after a restart of the server when using COG.
After a restart without COG the ms is still 15-25. Returning to the spawn puts ms at 3 still.
If your interested, you can watch the server stats live here:
I'm also on TS: grimshad.doesntexist.com
if you want to speak with me directly about it.
just streamed this test with COG and all ores + other dimensions:
So first of all, I don't know how copper, tin, and uranium are distributed in real life, so if someone could tell me, that would be great.
Using the way they are distributed in real life, I need to configure this mod so that it generates the ores the way they do in real life in the world. I am getting this mod because it makes minecraft more realistic so if someone could help me with these 3 mod ores, that would be great.
I think the ID for these 3 ores were 247,248, and 249 but I don't remember which ore was which ID.
I got izzet and mtg is baws. it pwns. real hard.
Beyond me. Anyone else?
Since it does matter, can you give me your server's command line?
Ok, let me see if I understand this.
13 ticks per second, approximately 80 ms per tick (normally 50 ms or less per tick)
What is "recovery time"?
What mod are you using for stat reporting?
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
Recovery time is the amount of time it takes for the server to go from the overloaded state back to the stable state. Which is going from 100+% load to 10% load usually. Normally this should take about 1-2 seconds, but it has been taking minutes or in same cases like with ores from other dimensions enabled.. it never recovers.
I am use the Ticks Per Second mod + the server stats for checking and a stop watch for timing
Add this to your config:
MAKE SURE YOU CHANGE THE BLOCK ID's TO THE ID's OF YOUR ORES!
Edit:
Well, I know what I want it to do, but I don't know who to make it do it is more of what I mean... Like I want the Water-Infused Stone to generate in smallish veins in Ocean, Ice Plains, Swamp, and Taiga biomes, but I have no such idea of how to write it into the config, or even which config to put it in...
If you would like me to explain the rest of them, I don't mind, but I really would like some help setting them up. ^-^"
1: which part is the block ID again? I forgot
2: does it distribute the ores like it would in real life? What level do these ores generate?
I got izzet and mtg is baws. it pwns. real hard.
My own server tests show that, while COG does have an impact on server latency during chunk generation, everything quickly returns to normal once new chunks stop generating. You are reporting that performance remains laggy even after all players have stopped moving. That could be memory related, but I have not seen anything like it myself.
Repeat the test twice, once with the standard COG config and once with COG uninstalled. Take a 4 screencaps like the one above during each test: 1 at spawn before starting, 1 while the player is moving and new chunks are generating, 1 after the player has reached their destination and remained still (wait at least a minute) and 1 after the player has returned to spawn (wait another minute). Post the 8 images back here and we will go from there.
Ok. I'm assuming you have two cores (I think you said 1+1).
You're using 8 GB for memory. Got it.
You're already using CMS/parallel new. Good.
I'm not sure whether incremental is going to be a good thing or not. You have a second core that the server cannot use. Letting the CMS collector run non-stop when needed may be better than the incremental. Can't tell without some numbers.
We need a couple of more debugging flags.
And, I want to get a handle on "eden".
java -server \
-XX:CompileThreshold=3000 \
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC \
-XX:+CMSIncrementalPacing -XX:ParallelGCThreads=2 \
-XX:MaxHeapFreeRatio=20 \
-XX:MinHeapFreeRatio=12 \
-XX:NewSize=1g -XX:SurvivorRatio=3 \
-Xms1300m -Xmx8g -XX:+UseCompressedOops \
-XX:MaxTenuringThreshold=4 \
-XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution \
-XX:+PrintCommandLineFlags -XX:+PrintGCDetails -Xloggc:GC.log \
That should give us 1gib for new, 200 mib each for survivor, and 600 mib for eden. That's what "Dynamic Maps" needs to avoid going crazy. It was more than enough for me to repopulate a 1024x1024 section without any problem. It also will go up to 8 gig total, but only as needed -- so we can see if there actually is a constant increase in memory consumption.
(Remember: We don't want more than 50% surplus in long-term, but we really do not want less; 100% surplus is too much. We want as much in eden as we can get.)
-XX:+UseCompressedOops -- according to the documentation, optimizes the 64 bit system when less than 32gib of heap is used
Most importantly, it will log the output. You'll see things like:
On the line:
concurrent mark-sweep generation total 207608K, used 135174K [000000000fc00000, 000000001c6be000, 0000000028c00000)
the tenured space is 135174K -- that's the long-term data usage.
On the line:
- age 4: 131808 bytes, 13026344 total
that's how much space has been promoted from "new" to "tenured".
Compare to the line:
Desired survivor size 6553600 bytes, new threshold 1 (max 4)
You want to see "new threshold" the same as max.
You want to see the "age 3" line 'total' value below that desired survivor size.
On the line:
from space 12800K, 100% used [000000000ef80000, 000000000fc00000, 000000000fc00000)
(That's in the "After" section)
the 100% used means that there is too much memory being produced for short-term. (This sample comes from a run with a much lower cutoff level.)
You want to see this below 66%.
Lets see some numbers.
600 MB of eden -- those numbers I gave you -- should give very infrequent GC of eden space.
The less often eden collects, the better -- it means more time for objects to die.
* Promoting this week: Captive Minecraft 4, Winter Realm. Aka: Vertical Vanilla Viewing. Clicky!
* My channel with Mystcraft, and general Minecraft Let's Plays: http://www.youtube.com/user/Keybounce.
* See all my video series: http://www.minecraftforum.net/forums/minecraft-editions/minecraft-editions-show-your/2865421-keybounces-list-of-creation-threads
(In regard to a mod that gives realistic animal genetics):
Would you really rather have bees that make diamonds and oil with magical genetic blocks?
... did I really ask that?
I'm just about to update my server to 1.4.5 from 1.4.2... do I need to retool my COG config from 1.4.2 at all or can I just drop it in for 1.4.5 and everything should work as per before. I read in the changelog you split the config into 2 files... so I'm just wonderin' (and a little worried) I'll have to rework my config.
Thanks!
-Pitch
8 cores
To be honest it doesn't seem to matter how much memory I allocate, the server only ever uses a maximum of 512mb at any given time, I give it 2G or 4G or 8G or 16G and it always runs at exactly the same performance.
I am entering unknown territory here, I don't know what any of this stuff does, but i'll throw it in my bat and see if I get improved performance.
EDIT: Wow, whatever this stuff does, it significantly increased server performance. It now runs at 10-20% load rather than 75% load, recovers much faster, and rarely goes into the red anymore.
I would like to continue this conversation, but I have fixed the COG portion of my performance issues and don't want to be offtopic here in the COG thread, so could you please PM me your reply
I really want to try this repopulate thing, but COG continues to tell me that I do not have permission to use the command. I am opped and I also tried it in creative mode, is there anything special in the config I have to do to be able to use the command?
If you still want me to do this I will, however, I figured out some of the performance issues already. While COG does have a performance hit on the server (especially with ores from other dimensions), it was not the root of the problem. It turns out the version of ExtraBiomesXL was conflicting with COG and causing my headache. I have since updated ExtraBiomesXL and performance has gotten _much_ better. With ExtraBiomesXL disabled and COG enabled performance is stable and recovery time is quick.
I appreciate all of your help Jroush. I hope I didn't waste any of your time.
Debugging commands require a world reference, so they can only be executed by players at the moment. You will be able to use the commands directly from the server console in the next version.
Ah, I remember that bug. It was something in vanilla minecraft that ExtraBiomesXL triggered, causing runaway chunk generation. I believe it was fixed a while ago (1.4.4?). I'm glad the problem has been resolved; let me know if you have any other issues.