New server questions need a little advice and ideas

[McBorg]

We are setting up a new server

we have run minecraft and tekkit in the past on vps servers using ubuntu but had a lot of trouble with bad vps service providers so we are starting a dedicated server

This server will be a tight community and will be running at least two or three tekkit servers

My questions are mainly about performance we will be running a xeon hyperthreded quad core @ a little over 3 ghz with about 12 gigs ram allocated to running tekkit maps

I want to limit the number of players on each map (server) to stop creating a big mess and give them room to do what they wish

I am a little unsure of how many servers to run and how many people to limit each server to

and should we consider switching to debian

Any discussion would be appreciated Thanks

[Jasonh]

Hi how many people are you thinking of running

and what mods? Anything disabled nukes quarries ?

I have run up to 5 on a ok vps

[zeus5966]

We use around 4 gigabytes for a max of 25-30 people. Id divide the gigabytes to 4 per map if it is possible with your provider. For each map using that amount of ram, id limit to like i said above 25-30

[Mattbazooka]

Would it be a good idea to run three servers (with the nether and end turned on) with the above configuration? And what plugins should we disable for performance? I will be helping McBorg set up the servers.

[Diabloz]

Lol 4G for 25-30 players? do you have almost all your tekkit mods disabled or what?

BTW go to some server OPs in the server section see their server slots in relation to their hardware and their disabled mods + plugins it should give you an idea of what you need to disable to avoid a lot of lag.

[zeus5966]

Lol I just realized what I said when I read our comment

Lol 4G for 25-30 players? do you have almost all your tekkit mods disabled or what?

BTW go to some server OPs in the server section see their server slots in relation to their hardware and their disabled mods + plugins it should give you an idea of what you need to disable to avoid a lot of lag.

Lol I just realized what I said when I read your comment. It was late and I wasn't thinking straight. I have ram for a max of 30 people on a vanilla server. This equates to low/no lag for anywhere under 10 people. Sorry about any confusion this has caused!

[imabigbot]

I see in another thread that this is going to be an Australian tekkit server is thi correct if so when will it be starting and who will be able to join

[John West]

I think it would be safe to say that you could allocate 5 people per 1.5 GBs of ram. So, for 4 GB's I would say you could run 10-13 people per server safely. Another thing you need to take into account is what mods you're going to leave enabled and plugins you plan on using. If you've got people running BC pipes all over the place and plopping down world anchors those numbers will change drastically.

[prenetic]

As for how many players you can have per server on that kind of hardware, I can't provide much assistance. I'm relatively new to Tekkit itself but have been designated by my group of friends as the ops guy so I'm trying to get up to speed.

Aside from resource allocation, there are some optimizations that can be made to the JVM at run-time that may increase performance. I'll include how I execute Tekkit below and explain the parameters with high-level detail:

java -d64 -server -showversion -Xmn3G -Xms8G -Xmx8G -Xss128K -XX:+AggressiveOpts -XX:MaxTenuringThreshold=31 -XX:ParallelGCThreads=8 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+UseBiasedLocking -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -jar tekkit.jar

 

-d64

Load the 64-bit JVM binary and libraries. This is to allow for more efficient resource management when dealing with large pools of resources, potentially spanning NUMA nodes. Do not specify this parameter if you are running your server with 2 GB of memory or less, you'll do more harm than good.

 

-server

Loads the server-optimized JVM binary. Depending on your version of Java the default may differ, which is why I explicitly specify this here.

 

-showversion

Shows which type and version of the JVM is used at run-time.

 

-Xmn

Size of the heap for the young generation (YG). Within this space is Eden which is where objects are newly created, and garbage collection (GC) will make passes through this heap often to mitigate what is tenured into the old generation (OG). Objects are promoted to YG1 and YG2, respectively, becoming survivors then ultimately tenured into the OG. The circumstances of these promotions are highly configurable however the defaults work well enough for most uses.

 

Tenured objects take much longer to get rid of due to the fact they require a full GC for purging. Full GCs effectively halt thread execution for the duration of the sweep (very bad, we're trying to avoid this). If you're thinking "I'll just increase the size of the YG", I'm afraid it's not that easy. Simply making a larger heap for the YG doesn't help since after a certain point (approximately 3/8 of the total heap size) the YG too will require a full GC for purging objects. The reason for this is the JVM is expecting everything in the YG to fit into the OG under extreme conditions.

 

-Xms

Minimum total heap size, set the same as the maximum total heap size. While in some cases it makes more sense and is generally faster to initialize from the default (lower) minimum heap size, we're running a server that is expected to run for days, weeks, and if you're lucky (or just daring) even months. Since there is plenty of activity going on while the server loads up anyway it doesn't hurt to pre-allocate your heap at run-time. This approach mitigates the performance hit when heap size is allocated by doing it up front.

 

-Xmx

Maximum heap size, set to the same as the minimum total heap size. These two parameters should reflect each other, and reflect the total amount of memory you want the server to take up. In my example, my server is currently consuming 8 GB of memory.

 

-Xss

Thread stack size. This parameter would require a little more explanation but basically a thread stack size of 128 KB is usually enough for most applications, while the default of ~512 KB is rather generous. It makes sense to have a larger thread stack size from a design standpoint, to avoid problems where customers are running with defaults. Through configuring this you are effectively freeing up space for the game to use.

 

-XX:+AggressiveOpts

Enables various "aggressive" optimizations that have been newly introduced into the JVM. These may not be fully tested and as a result not implemented as default options. If you are experiencing unusual issues it may make sense to temporarily disable this, especially if you've recently updated your JVM.

 

-XX:MaxTenuringThreshold

This was a recommendation in one of the many white papers I read when researching JVM optimizations. While 31 is the default on most platforms I wanted a consistent experience and as such explicitly specified the parameter here. What this option does is dictates how much of the YG becomes tenured. Since it's not often something needs to be tenured in Minecraft, setting this to a value that would produce more objects in the OG only leads you to issues with full GCs sooner.

 

-XX:ParallelGCThreads

Specifies how many threads will be allocated to perform parallel GC. I typically set this to however many (real) threads are available on my system as parallel GC by default takes low priority and has self-control during passes. The more threads the better, as this will result in faster sweeps and causing fewer pauses in execution.

 

Note earlier I said I set this to however many real threads I have, this means if you're running HyperThreading then take the total thread count of your system and divide by 2. Prior to a hotfix pushed out by AMD and Microsoft I would have said the same for chips based on the Bulldozer architecture as two cores are stuffed into one module (sharing an FPU), however these issues have since been resolved and were largely related to inefficient scheduling.

 

-XX:+PrintGCDetails

This will show output similar to the following in your shell during run-time:

 

Healthy JVM, with periodic parallel GC sweeps:

221857.554: [GC 221857.554: [ParNew: 2682801K->131196K(2831168K), 0.0779745 secs

] 2682801K->131196K(8074048K), 0.0791959 secs] [Times: user=0.41 sys=0.02, real=

0.08 secs]

222458.547: [GC 222458.548: [ParNew: 2647804K->118481K(2831168K), 0.1040211 secs

] 2647804K->118481K(8074048K), 0.1049036 secs] [Times: user=0.56 sys=0.00, real=

0.11 secs]

 

Unhealthy JVM, OG full with survivor objects being tenured. CMS (which we'll configure later) is in full-effect to mitigate the potential for full GCs, which would halt execution for the duration (usually several seconds). Periodic full GCs only get worse with time. Note this condition was forced by performing a very large, resource-intensive operation which will simply need to play itself out:

99342.756: [GC[YG occupancy: 2634708 K (2831168 K)]99342.757: [Rescan (parallel)

, 1.6701548 secs]99344.427: [weak refs processing, 0.0000191 secs]99344.428: [s

crub string table, 0.0006000 secs] [1 CMS-remark: 5242863K(5242880K)] 7877571K(8

074048K), 1.6719729 secs] [Times: user=12.28 sys=0.00, real=1.67 secs]

99344.429: [CMS-concurrent-sweep-start]

99351.378: [CMS-concurrent-sweep: 6.949/6.949 secs] [Times: user=6.94 sys=0.00,

real=6.95 secs]

99351.381: [CMS-concurrent-reset-start]

99351.418: [CMS-concurrent-reset: 0.036/0.036 secs] [Times: user=0.03 sys=0.00,

real=0.04 secs]

99353.421: [GC [1 CMS-initial-mark: 5242863K(5242880K)] 7877609K(8074048K), 2.41

72356 secs] [Times: user=2.42 sys=0.00, real=2.42 secs]

99355.841: [CMS-concurrent-mark-start]

99394.986: [CMS-concurrent-mark: 39.144/39.144 secs] [Times: user=67.77 sys=1.79

, real=39.14 secs]

99394.987: [CMS-concurrent-preclean-start]

99395.037: [CMS-concurrent-preclean: 0.050/0.050 secs] [Times: user=0.05 sys=0.0

0, real=0.05 secs]

99395.038: [CMS-concurrent-abortable-preclean-start]

99395.038: [CMS-concurrent-abortable-preclean: 0.000/0.000 secs] [Times: user=0.

00 sys=0.00, real=0.00 secs]

In the event the heap is completely consumed and no objects can be purged, out of memory exceptions will begin to occur as survivor objects from the YG are tenured. Increasing resources available to the JVM may help, but ultimately these operations will have to run their course once the affected chunk(s) are loaded.

-XX:+PrintGCTimeStamps

Includes timestamps (seconds since initial execution) for GC.

-XX:SurvivorRatio

Specifies the ratio for the OG. In this instance the ratio for each survivor space and Eden is 1:8. Since there is Eden and two YG (YG1 and YG2) this roughly coincides with the magical 3/8 figure I included above when specifying YG heap size. This leaves the OG with 5/8 of the total heap. It's not at all efficient for this use case, but running a larger YG only puts you in a worse position.

-XX:TargetSurvivorRatio

This is merely a guideline for the JVM that states what percentage of the survivor spaces should be used after a sweep of the YG occurs. We're shooting for higher utilization in survivor spaces to mitigate what is being tenured in the OG.

-XX:+UseBiasedLocking

This is just a suggestion by Oracle, it's unlikely Minecraft will benefit from biased locking. The functionality is designed in such a way that this should only improve performance when it is required.

-XX:+UseConcMarkSweepGC

This specifies you wish to use the Concurrent Collector for sweeping the OG. This collector will allow for shorter pauses (what we want to avoid at all costs) when sweeping the OG at the expense of some overall performance. Think of it as your last-stand against full GCs.

-XX:+UseParNewGC

Specifies the Parallel Copying Collector should be used for sweeping the YG. Your other option is the default Copying Collector or the Parallel Scavenge Collector (a Throughput Collector), neither of which are ideal for this use case. This collector allows for excellent performance through high efficiency and low pause times by running multiple sweeps of the YG in parallel.

[darzavor]

I agree with John West. I have no experience with VPN servers. But on our simple notebook that we use as dedicated server (cleaned out Ubuntu, just minecraft server, nothing else is running). We only allocate 1Gb for 7 people.

Then the amount of mods, which restrictions on using those you put in place and which plugins you use can influence it heavily. I mean, we don't have to try DynMap plugin with every option enabled in our setup.

This server is 24/7 on and runs not exactly Tekkit, but a vanilla modded minecraft with great similarity to Tekkit (couple more mods).

To give you a better idea, we use the following plugins : Essentials, Group Manager, Vault, Residence, McMMO, MobArena and DeathChest.

[McBorg]

Thanks prenetic this is very helpful more than I can express I feel a lot more confident going into this setup now that I can preserve things from a better perspective

This explains some anomalies we had in our previous setup.

@ Imabigbot yes this is an Australian tekkit server keep up to data at www.tekkitservers.com.au

At this stage we will run with nukes quarries world anchor disabled the primary Tekkit server will be limited to 15-20 responsible players be allocated 4-6 gigs ram that leaves us plenty for shenanigans with hunger games and so on

[Nentify]

Remember to disable the teleport tether from additional pipes and the dimensional anchor if you're disabling the world anchor. ^^

[soulgriever]

Lol 4G for 25-30 players? do you have almost all your tekkit mods disabled or what?

BTW go to some server OPs in the server section see their server slots in relation to their hardware and their disabled mods + plugins it should give you an idea of what you need to disable to avoid a lot of lag.

you do know that parsonage ran on 4gb for a long time right? It handled the players the same whether it had 5 players online or 50. The Issues we had with lag was faulty or mis-configured on my part plugins. Just saying

We are setting up a new server

we have run minecraft and tekkit in the past on vps servers using ubuntu but had a lot of trouble with bad vps service providers so we are starting a dedicated server

This server will be a tight community and will be running at least two or three tekkit servers

My questions are mainly about performance we will be running a xeon hyperthreded quad core @ a little over 3 ghz with about 12 gigs ram allocated to running tekkit maps

I want to limit the number of players on each map (server) to stop creating a big mess and give them room to do what they wish

I am a little unsure of how many servers to run and how many people to limit each server to

and should we consider switching to debian

Any discussion would be appreciated Thanks

Now as far as your questions about the server Im sure you know that minecraft mp only supports single thread. However alot of the more resource intensive plugins have multithread support. So I wouldn't worry as much about the threads your cores have or the cache but rather the clock speed. I currently upgraded my servers hardware cause Im running a VPS an I am fighting my host because their trying to tell me its a faster machine overall an ya thats true but thats because my machine has more threads so the machine is faster but my minecraft server is slower because it has a slower clock speed on the processor's. Btw when I did that upgrade they switched my processors without asking so make sure you have the exact clock speed from your host ahead of time so they dont screw you over

[McBorg]

when I did that upgrade they switched my processors without asking so make sure you have the exact clock speed from your host ahead of time so they dont screw you over

That has happened to us as well without notice dropped from 4 cores to 1 screwed up the whole game

then switched to another provider after about 2 months he did an upgrade only after the upgrade we suddenly run into cpu lag took us a little while to find out what was happening.

We will be running hunger games periodically on the same system running under a different server so I am still brushing up on what runs on what core

Thanks for the input

[uradox]

One thing I will add from my recent experience setting up a dedicated Australian tekkit server is to monitor the data usage. As you would know, data in Australia isn't cheap and I initially found my server to be using quite a bit when it was 24 slots with Australians during the day and Americans during our evening. I would have paid a pretty fortune in excess data charges if I had not picked up on it and restricted access more.

[Jordan12]

We run an Australian sever with an average of 30 online at a time, with 50 online during the evenings, 90% are aussie, the other 10% is USA, and Europe.

We have used 1300GB this month (ending tomorrow)

[D3matt]

How fast is the processor? 4 cores means nothing if they're 1.86Ghz each. A slower quad-core will utterly collapse under 30 players all running a base full of machines.

E: Never mind, I'm an idiot.

[Jordan12]

Currently running a Xeon 1260 @ 2.4Ghz, we might be looking to upgrade our tekkit box and then use this one for a 1.4 survival when we move to the new datacenter

[D3matt]

You shouldn't need 2 separate boxes for that. Tekkit only uses one main thread, so running two servers at the same won't be competing for processor time.

[McBorg]

Provided you have enough memory I agree with D3matt we ran our backup vps with 25 players with just 0.7ghz x4 allocated for a month with 3 gig allocated to the tekkit server map I think disk access was starting to become an issue but a lot of people commented on how good the server was running with no lag.

I know that a lot of australian tekkit servers are not running on any where near the hardware that they claim either as I chatted with the admin from one so called Aussie tekkit server on my website I use quick chat with quick flag enabled as a chat room, the owner was flagged in the uk and the admin was in the philippines and he quotes the server specifications of the host server not the specifications of his vps.

So don't judge a tekkit server by it quoted specifications or what it plays like either we deliberately ran three tekkit servers into lagg and our quad core xeon was only at 4% load with no ill effects on a fourth server this was done in some early testing that was carried out to better understand the relationship between cpu, java, memory and tekkit.

I think a good tekkit server is 80-90 percent good "server guy admin" tekkit is not minecraft a tekkit server can go all wrong within seconds of an idiot getting his hands on something that he shouldn't I seen it happen when we shut our vps down we enabled creative mode to place signs telling people that we moved and within 20 seconds some idiot run the server into lag

I'm kicking another server in the guts soon I'm tekkit server name challenged I wanted an aussie name so I came up with spinifex :/ @ www.spnfx.com.au it's not up as yet no big rush I'm going to hone our signup prosess a little in an efort to eleviate the idiot player factor as much as possible still chasing that perfict sever I guess

[D3matt]

Er... That's not QUITE what I was saying, but sure. I'm actually extremely surprised you got tekkit to run with a 0.7Ghz processor at all. Although, there may be something with the host's allocations where it's actually just allocating 2.8Ghz split up however you use it in a maximum of 4 cores, I know processor allocation is a little bit fuzzy in VMWare, though I don't know how "fuzzy" it is in other hosts. (But there's a pretty good chance most commercial VPSes use VMWare in some form or another). I run a tekkit server on a windows 2003 box with 2x2.4GHz single-core xeons and it uses up a good 50% of both cores, at about a 70/30 distribution between threads. Which is very odd because Tekkit isn't supposed to be multithreaded...

[Vincent the gamer]

BlackList the server or Blacklist Until they pay the fee for accessing the server

[D3matt]

Why did you necro this to add something completely unrelated to the topic?

[Dr_Mannai]

lolz no idea i was like ummm, this is odd