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.