Server Debugger

Every fraction of a second, the server does a "tick" - calculating the world: mobs, campfires, temperature, everything at once. If one tick takes not 0.05 seconds, but, say, 5 seconds - this is a freeze for the players: mobs freeze, blocks cannot be placed, and everyone "teleports".

There are only a few reasons for a long tick, and they require different treatments. This mod can distinguish them from each other and show exactly which one you have.

Two things you need to know to understand the mod's output:

• Garbage and Garbage Collection (GC). The game and mods constantly create temporary objects in memory. When a lot of them accumulate, the system initiates a "garbage collection" (GC): it freezes, goes through all the memory, and throws away the unnecessary stuff. While the collection is running, the server is paused. Usually, this takes fractions of a second and goes unnoticed. But if gigabytes of memory have accumulated, a single collection can take seconds - and that's a freeze.
• Memory leak. Garbage collection only throws away what is no longer needed by anyone. If a mod mistakenly continues to "hold" already dead mobs (does not release the reference to them) - garbage collection cannot throw them away. They accumulate. Memory usage grows, garbage collections become longer, and the server lags more and more. This is a leak. This is exactly the kind I caught on my server - a mod was holding tens of thousands of long-disappeared mobs.

MemLeakInspector is a specialized tool for memory investigation. It shows what objects are in memory, allows you to analyze their state, and compare memory snapshots with each other. However, it does not automatically determine the cause of the problem - you have to interpret the results and look for the culprit yourself.

Server Debugger is a comprehensive server diagnostic tool. It analyzes main-thread freezes, lags, GC pauses, disk issues, and memory leaks. When a leak is detected, it immediately tries to identify the offending mod, which significantly speeds up finding the problem. At the same time, it does not provide deep analysis of objects in memory, temporal snapshots, or a detailed memory usage dashboard.

In other words, Server Debugger answers the question "which mod is causing the problem?", while MemLeakInspector answers "what objects are in memory and how do they change over time". These tools do not replace each other, but work perfectly together.

Catches confidently and automatically

• Memory leaks. When a mod mistakenly accumulates dead entities (mobs) in memory and doesn't release them - memory grows, and the server lags more and more. The mod finds this and calls out the culprit by name (command whodunit). 
• Understand what causes the lag in the first place. For every freeze, the mod tells you where the time went: to garbage collection, to excessively long code, or if the server was simply waiting (disk, hardware). It will always point you in the right direction - you won't have to guess and dig in the wrong place.
• Who manually triggers garbage collection. Sometimes a mod itself orders to "clean up garbage now", and with a large amount of memory, this causes a freeze. The /sdebug gccallers command shows which mod is doing this (in detail and with an example in the commands section below).
• Poor garbage collection settings. The /sdebug env command will show if the fast garbage collection mode is enabled, and if not, this can be fixed (output example and how to fix it are below).

Helps, but won't name the culprit automatically

• "Heavy code". Imagine: a mod author made a mistake, and their mod unnecessarily recalculates all 5000 garden beds on the server every tick, like the Wild Farming mod for example.  The memory doesn't grow - the code is just doing too much work. This is NOT a leak, and whodunit is useless here.
  
  What the mod will do: stalls (see below) will clearly write "this is heavy code, not garbage collection" - meaning it will give you the right direction. And to find the specific mod, there is profile (see below) - it measures time by code segments. But it doesn't look at all mods in a row, only at those specified in the settings (or similar to them). So here it is not a "click - get a name" situation like with a leak: you might have to give the debugger a hint on where to look. There is help, but no automation; you will have to go through the suspicious mods.

Cannot do at all

• Lags due to disk, network, or weak hosting hardware. The mod will say "the cause is not in the mod code" - but it won't be able to fix it. This is an issue for the host.
• Player-side lags (low FPS, stuttering screen). The mod is purely server-side; it does not see the client at all.
• "Heavy, but correct". If those same 5000 garden beds honestly need to be calculated and there is no error in the code, the mod will show that time is being spent there, but this is no longer a bug, but rather a question of how the mod is designed. This is cured not by debugging, but by reworking the mod (or reducing the load on the server).

In one sentence

It will find a memory leak and name the culprit itself. For everything else, it will point you in the right direction ("it's the code", "it's the disk", "it's garbage collection"), but from there on, you will have to figure it out yourself.

On the first launch, the ModConfig/ServerDebuggerConfig.json file is created:

{
  "Language": "en",
  "StallThresholdMs": 500,
  "WatchedModMarkers": [ "xskills", "xlib", "xleveling", "xeffects" ]
}

• Language - default output language.
• StallThresholdMs - from what duration (in milliseconds) a freeze is considered worthy of being recorded in the log. 500 = half a second.
• WatchedModMarkers - a hint for /sdebug profile and /sdebug findroot on which mods to watch by default. The values xskills, xlib etc. here are just an example (the mod was originally written while debugging these mods). This is not a dependency: ServerDebugger itself does not depend on xskills/xlib at all and works on any server with any mods. If you want - erase them and enter your own, or leave it as it is. The main commands (whodunit, leak, entities, stalls, gc, gccallers, env) ignore this list and always work. A regular user doesn't need to touch it.

Change output language on the fly:

/sdebug lang en

The selection is saved. Without a code, the command will show the current language and a list of available ones.

To add your own language: copy assets/serverdebugger/lang/en.json to a file with your code (for example aaa.json) and translate the values. Placeholders {0}, {1} and commands /debug ... should not be touched - only the text around them. The file will be picked up automatically. If any string is missing in your file - the English one will be substituted, so you can translate gradually.

Technical words (names of collection reasons like AllocSmall, code location names in the findroot output) are intentionally not translated - they are identifiers, they need to be seen as they are.