Peacecraft Modded Server
whats up guys havent been able to login for a couple days says end of stream or connection refused ?
is it my problem or the server down hard ?
dont know, but ill look into it
ok, server is up. we keep running out of available memory on the hardware, thats whats causing a lot of the problems
Two things that TV and I have noticed:
1. The console prints out a lot of error messages, plus messages about mods leaking worlds, which could cause memory issues.
2. Your ftbstartup.sh is FULL of arguments that probably aren't necessary, and it should be cleaned up. Where did you get it? Also, it seems to be set to use 8GB memory instead of 16GB
From what I have been told, the leaking worlds message is mainly a debug message of sorts, and doesn't really mean much.... However, I do believe that they do eventually cause the Java Heap Space issue we have. The .sh we use is taken from some other server, and then modified to suit our needs, although I'll admit I personally don't know what all of the arguments do. Aarchel is the one that picked which ones we ended up using, and I've never given myself the chance to look through it( mostly being lazy
The error messages I think are mostly due to mod incompatability problems (some of them are hardcoded to use certain block, and item ID ranges, so we had to futz with things to make it all line up right). That being said, some things are out of my hands, error-wise (IC2 enet and the like), mostly because its not my code to change, so we just have to live with a few oddities here and there..... And that stupid hashmap iterator error; I have NO idea where thats coming from. The current theory is that the map files for the overworld are somehow damaged, and is throwing those.
Finally, I've cut the server back to 8 gigs from 16, because when we were running 16 gigs, the rest of the server stuff was starting to experience a ton of problems with loading times, and other lag issues. If we can nail down what is using how much memory, perhaps I can kick our server back up to 16 gigs.
Most of the java arguments relate to how and when garbage collection runs. Ideally, they are meant to put it off for as long as possible and then clear it all at once, which normally results in a somewhat longer than normal bit of lag and then the server should run as fast as it can until memory fills up again. Before we started using that script we were having constant lag of 5-10 seconds per block. Things improved dramatically after we changed to it. However it may not be optimal anymore, as that script was made specifically for a single update and was not needed before then. If we dump most of the stuff having to do with garbage collection and add one new switch the .sh could look something like this:
java -server -Xincgc -XX:PermSize=1G -Xms8G -Xmx8G -XX:UseSSE=4 -XX:ParallelGCThreads=2 -cp ftbserver.jar -jar ftbserver.jar
Obviously, memory amounts need to change and the jar is named differently but this is the most bare bones the FTB server should be running.
Ultimately the problem lies in the fact that all mods affect performance, and the more mods you have the more baseline performance is impacted. Then you add the players and whatever they do to the world and it just blows up exponentially. Unfortunately a modded server requires more tweaking than a vanilla/bukkit server to keep it going. The other problem is that the world is so old now, it's been through at least 10 updates now and even had some pretty bad chunk resets. Some of the mods we run have changed nearly their entire codebase from 1.4-1.4.7 and the back-end issues that have arisen due to them are increasingly more complex to work out. In the long run I don't think this world will last beyond 1.4.7. Having gone through configuring a new server for our vacation, I can say that the differences between 1.4.7 and 1.5.2 make it highly unlikely that we will even be able to keep the current world. I don't even want to think about 1.6.x., Forge modding gets even more difficult then.
What we really need to do is run some real profiling to see where the bottlenecks are, but the tools for 1.4.7 are no longer maintained and the last available versions do not work with the version of forge required by the pack so we are unable to dig deeper. The only other way is to use a java profiler, but I haven't found one that I can understand the output of. Another possibility would be to use a different JVM, like the Oracle JRockit JVM, which I've heard is pretty good for modded minecraft and is well documented. However, that means changing it on the server and I can't do that, and don't know if it may affect anything else so I haven't really looked into it much.
As far as the leaking worlds message goes, the Forge developers themselves have stated that it is there only to inform modders that worlds are not unloading properly, or persisting after all players have left them. It's purpose is to inform them that their code may be screwing up somewhere if it triggers that message unintentionally. However, the FTB Server runs some mods that will cause this message to appear due to their normal functionality so it is meaningless for us. Also, there is literally nothing we can do about it one way or the other even if it is happening in error.
I honestly don't see how modders are "okay" with this patched together compatibility mess of a modding environment. IMHO, modding APIs should be written to provide anything a mod maker would need with only very little need to touch raw Minecraft classes/code and without the need to manually specify block IDs. This would make mod maintaining WAY easier, and would be possible if modding APIs were written better, if you can even call them proper "APIs" with how they work.
As of 1.6 Forge no longer needs to use base code at all, up until then it was necessary only to control when certain bits of code were run but the new launcher changed that so Forge stopped doing any base edits.
As an API Forge is written by the people who use it. It only contains functionality that someone has written the code for, if it does not have the ability to do what a modder wants/needs then it is up to them to make a Pull Request to implement it. Though there are cases where things don't get implemented because they are already possible in another way.
Block ID's are Mojang's design choice, and a crappy one at that, but there it is. There have been many discussions about creating a system to automatically manage Block/Item/Biome/Enchantment ID's but they all fall apart because none of them can solve the problem of modders not using the system. If even one installed mod does not use the system or uses it improperly it crashes, or at worst runs with terrible conflicts. So unfortunately, at least for the time being, we are stuck with either manually editing the configs, or using a preconfigured pack so people don't have to. I'll be the first one to say that manual configuration blows. I spent 9 hours configuring the Minecraft Server Edit and I were playing on while on vacation to resolve ID conflicts, and despite that there are still ID issues that make no sense as they are not conflicting with anything, but still don't work, not to mention some broken world gen. On the other hand it made playing very interesting, as half the resources we commonly need to get started were exceedingly rare because they did not generate in world. There were also issues with certain mods not being available/compatible complicating things, but in the end it was still a lot of fun.
As far as making mod maintenance easier goes, as long as a mod using Forge is compiled to srgnames, it stays nearly entirely compatible through most minor updates 1.5, 1.5.1, 1.5.2. However Major updates like 1.5 to 1.6 tends to break that though sometimes things are still very close. The real problem is that Mojang has no API of their own and is slower than a snail in implementing one, despite saying that they support Minecraft Modding. Honestly, for the most part Forge/FML are excellent pieces of code and have negligible performance impact. However the same cannot be said of every modder that uses them.