prenetic

I said the 2nd thread would only benefit you if anything, there should be no penalty. The kernel knows how to schedule threads properly for systems with HTT (and now also Bulldozer-based processors).

Neither of those assumptions are true, and I'll address them in more detail below: Disabling Hyper-Threading Technology in theory should only mitigate overall performance. Either the execution pipeline is able to be optimized for more IPCs (instructions per cycle) or not. Worst-case scenario you end up with the same performance as a machine without HTT. The only time you'll likely run into issues is if you see 8 threads and think 8 cores, and allocate accordingly (effectively oversubscribing your CPU by 200%). A thread is not a core with HTT, two threads exist in one core so you have 4 cores. Disabling other cores also will not help you unless you intend on using the thermal headroom to overclock the remaining cores. While you're correct that Minecraft itself is single-threaded, its scheduler (as well as the scheduler in the kernel of your OS) is capable of handling multiple threads and will distribute load appropriately. If you're only using one core, then only one core should be working and heating up so disabling cores will only hinder your performance when you actually need it (say, when you're running a fullrender in dynmap). As for what's overloading your server, you'll have to dig deeper with any of the myriad of tools available to profile JVMs. Find out what is bogging you down and see if anyone else has a similar problem. We're also unaware of how you're invoking the JVM so that may be a place to start.

It's a library available through Java to manage console input. If you end up needing it I believe you can install it manually.

Try adding "--nojline" to the end of your execution string. e.g., "java -Xmx640m -Xms320m -jar Tekkit.jar nogui --nojline"

You will likely top out at approximately 200 clients for a stock Minecraft server with those specifications. Taking into account some of the overhead involved with the Bukkit API and subsequent modifications supplied with Tekkit you can safely estimate 170 clients (96 MiB/player) on a light-load server and 128 clients (128 MiB/player) on medium to high-load servers. There are far more knowledgeable people here with respect to which mods are must-haves and must-not-haves. I'll leave this question up to them. If you're concerned about resource constraints, this probably won't be too much of an issue. You can always keep an eye on it and adjust if necessary. As you stated, Java is a cross-platform language so any benefit from one OS to another would exist in the realm of operations. For example, filesystems (snapshotting, deduping, compression), integrated backup solutions, overall stability and ease of management (patching), integrated networking solutions (LACP, failover) to name a few points of interest. The Tekkit binary runs just fine on x64-based operating systems. If you intend on using more than 1 GiB of memory it is actually recommended you use the x64 JVM.

That sounds about right. One recommendation I will make is to set -Xms and -Xmx to be the same in the context of Minecraft. If you still need more memory for your Minecraft server you can also add the /3GB switch to your boot.ini file. There are plenty of tutorials online as to how you can go about doing this.

As for Windows Server 2008 Enterprise (x86) capable of utilizing 64 GiB of memory, that's true. It falls under the PAE exception I mentioned in my first post. Again, this does not apply to user processes.

Try working down from 4 GiB in 512 MiB increments (4096, 3584, 3072, 2560, etc.) until it works. You're running into virtual memory address space limitations. 4 GiB is the absolute maximum you will have success with as it is the upper ceiling, however the effective ceiling varies from machine to machine based on the operating system and configuration. From Wikipedia:

You pretty much answered your own question. You're running a 32-bit operating system which is only capable of addressing 4,294,967,296 bits (2^32), which comes out to 4 GiB of addressable memory in total. There are tricks such as PAE (Physical Address Extension) which allows the addressable memory of the operating system to extend beyond 4 GiB, however this does not apply to 32-bit processes. This is the same reason why 32-bit filesystems cannot (without unsupported modifications) contain entities greater than 4 GiB. tl;dr: The maximum you can address is 4 GiB. Give that a shot.

Have you tried starting the server without NetherOres to see how far you get? It looks as if the .jar itself may be corrupted; try moving it to your desktop temporarily and start it up again. 12:50:42 [WARNING] Failed to load mod class net/minecraft/server/mod_NetherOres. class in C:\Users\Family\Desktop\Tekkit Server\mods\mod_NetherOres.jar 12:50:42 [sEVERE] Zip file mod_NetherOres.jar failed to read properly 12:50:42 [iNFO] File mod_NetherOres.jar contained no mods 12:50:42 [sEVERE] A problem has occured during mod loading. Likely a corrupt jar is located in your mods directory

+1 to the above. Black magic demystified a bit, in the context of Minecraft.

When you start your server up, can you paste here the line that contains "Starting Minecraft server on"? It should look something like this: 01:01:25 [iNFO] Starting Minecraft server on *:25565 Binding your server to a network address will prevent you from connecting via localhost as the localhost interface runs in software on 127.0.0.1 and ::1 for IPv4 and IPv6, respectively. Nothing is actually transmitted over the wire.

Without logs I'm afraid I won't be of much help. My guess is if you were running into file locking issues in the first place this is just a symptom of the reciprocal.

Done. Hope that helps.

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.

Thanks for all your hard work mikeprimm!

A couple of nice built-in options to invoke at run-time will let you know what's going on with garbage collection within your JVM. I've used this data to finely-tune which GC methods are used as well as YG/OG sizes. -XX:+PrintGCDetails -XX:+PrintGCTimeStamps If you see a lot of full GCs it's likely your OG has been completely consumed and attempts to prune are failing due to resources in the YG becoming promoted and tenured, effectively undoing the work that was just done to clean up the OG. Best thing to do at that point is restart your server after tuning your GC configuration. This is assuming you're suffering from memory issues, of course.

A plugin I often use to get a quick feel for a world seed is called WorldBorder. If you're looking to utilize the built-in world generation algorithms for your server this may be a good place to start. You basically specify a seed (or delete your world files and restart the server to get a random seed), specify the world border and tell the plugin to "fill" in all blank chunks. With Dynmap installed as well the map will be automatically generated as chunks are created. http://dev.bukkit.org/server-mods/worldborder/

Some questions to help us get the right idea of what is going on: What is the address your friends are using to connect? What is the address you are using to connect? Where is the server located (e.g., on the same network as your workstation)?

I find it really depends on what you're doing. If you have a handful of people on who are playing the game and not making massive changes spanning multiple chunks and causing hundreds (or thousands) of block calculations then you can typically get by with very little resources so long as you restart every so often or configure more aggressive garbage-collection. I'm not sure what the nature of the differences are between vanilla/Bukkit and Tekkit but Tekkit screams with a few optimizations to the JVM at run-time, even when performing some crazy operations.

I personally don't leave it up to a mod or plugin to handle backing up critical world data (or any, for that matter). When I was running my server on Solaris I took advantage of the Time-Slider service to make frequent backups to any modified world files. I've since then migrated to a Windows Server 2008 R2 host I built which has both VSS (Volume Shadow Copies) and daily scheduled backups through wbadmin (to another array for full metal restores) configured. I'll never lose more than a day's worth of work and that is enough for me, however the configurations are pretty flexible if you need something more granular than that. The performance hit of either of these is negligible. VSS is faster since it invokes a snapshot in-place on the volume where wbadmin will perform a full or incremental backup to another volume.