I’d say don’t even bother.
Irqbalance identifies the highest volume interrupt sources, and isolates them to a single unique cpu, so that load is spread as much as possible over an entire processor set, while minimizing cache miss rates for irq handlers.
The highest interrupt source here will be java
. It won’t be granular like “a single minecraft game thread”. Thus, irqbalance will isolate a particular Java process (one per server, if you run multiple). All the multiple threads the jar will run will be in that one CPU process anyway and Java will know to have garbage collection run on separate cores.
In short, where we want irqbalance to help…it can’t because it sees Java as the process to manage, not “chat thread” and “game loop thread”, etc.
Also don’t bother.
Preload is an ‘Adaptive Read-ahead Damon’, which is the equivalent to Windows Vista’s Superfetch. Effectively what it does is speeds up application load time by monitoring the software that is loaded and used day to day, the software used most often, and cache them in memory. If you have a lot of memory, you will notice things will improve.
You shouldn’t have a lot of memory. Your Java heap should be using up available memory. Memory dedicated to the heap/Minecraft is the single most significant way to improve your game’s performance (provided that you’re not so short on memory that other system services fail).
Memory used for preload is not even remotely as valuable as memory that Java can use to hold jar-related assets.
I’d say you can safely ignore both of these utilities.