Server Debugger

El_Neuman

Ein Mod für Serverbesitzer. Er beantwortet die Frage "Warum laggt mein Server" - und wenn ein bestimmter Mod schuld ist, nennt er ihn beim Namen. Ein eigenständiger Mod, der keine Abhängigkeiten mit sich bringt. Wird nur auf dem Server installiert; Spieler müssen ihn nicht herunterladen.

Er wurde in der Annahme geschrieben, dass du kein Programmierer bist. Die folgenden Befehle werden mit einfachen Worten erklärt: was sie tun, warum und was sie anzeigen.

Allgemeine Informationen - was eigentlich passiert, wenn der "Server laggt"

Der Server macht in Sekundenbruchteilen einen "Tick" - er berechnet die Welt: Mobs, Lagerfeuer, Temperatur, alles auf einmal. Wenn ein Tick nicht 0,05 Sekunden, sondern beispielsweise 5 Sekunden dauert, ist das für die Spieler ein Freeze (Einfrieren): Mobs bleiben stehen, Blöcke können nicht platziert werden und alle werden "teleportiert".

Es gibt nur wenige Gründe für einen langen Tick, und sie erfordern unterschiedliche Behandlungen. Dieser Mod kann sie voneinander unterscheiden und genau zeigen, welchen du hast.

Zwei Dinge, die du wissen musst, um die Ausgabe des Mods zu verstehen:

Müll und Speicherbereinigung (GC - Garbage Collection). Das Spiel und die Mods erstellen ständig temporäre Objekte im Speicher. Wenn sich viele davon ansammeln, führt das System eine "Speicherbereinigung" (GC) durch: Es friert ein, geht den gesamten Speicher durch und wirft unnötige Dinge weg. Während die Bereinigung läuft, steht der Server still. Normalerweise dauert das Sekundenbruchteile und bleibt unbemerkt. Wenn sich jedoch Gigabytes an Speicher angesammelt haben, kann eine Bereinigung Sekunden dauern - und das ist ein Freeze.
Speicherleck (Memory Leak). Die Bereinigung wirft nur das weg, was niemand mehr braucht. Wenn ein Mod fälschlicherweise weiterhin bereits tote Mobs "hält" (die Referenz auf sie nicht freigibt), kann die Bereinigung sie nicht wegwerfen. Sie sammeln sich an. Der Speicherverbrauch steigt, die Bereinigungen werden immer länger und der Server laggt immer mehr. Das ist ein Speicherleck. Genau so eines habe ich auf meinem Server erwischt - ein Mod hielt Zehntausende von längst verschwundenen Mobs.

Wie unterscheidet sich Server Debugger von MemLeakInspector?

MemLeakInspector ist ein spezialisiertes Tool zur Speicheruntersuchung. Es zeigt, welche Objekte sich im Speicher befinden, ermöglicht die Analyse ihres Zustands und vergleicht Speicherschnappschüsse miteinander. Es ermittelt jedoch nicht automatisch die Ursache des Problems - du musst die Ergebnisse selbst interpretieren und nach dem Schuldigen suchen.

Server Debugger ist ein umfassendes Server-Diagnosetool. Es analysiert Einfrierungen des Main-Threads, Lags, GC-Pausen, Festplattenprobleme und Speicherlecks. Wenn ein Leck entdeckt wird, versucht es sofort, den schuldigen Mod zu ermitteln, was die Fehlersuche erheblich beschleunigt. Gleichzeitig bietet es keine tiefgreifende Analyse von Objekten im Speicher, temporäre Schnappschüsse oder ein detailliertes Dashboard zur Speichernutzung.

Mit anderen Worten: Server Debugger beantwortet die Frage "Welcher Mod verursacht das Problem?", während MemLeakInspector beantwortet "Welche Objekte befinden sich im Speicher und wie verändern sie sich im Laufe der Zeit". Diese Tools ersetzen einander nicht, sondern ergänzen sich hervorragend.

Was der Mod kann und was nicht

Erkennt zuverlässig und automatisch

Speicherlecks. Wenn ein Mod fälschlicherweise tote Entitäten (Mobs) im Speicher ansammelt und nicht freigibt, wächst der Speicher und der Server laggt immer mehr. Der Mod findet dies und nennt den Schuldigen beim Namen (Befehl whodunit).
Verstehen, was den Lag überhaupt verursacht. Bei jedem Freeze sagt der Mod, wohin die Zeit geflossen ist: in die Speicherbereinigung, in zu langen Code, oder ob der Server einfach gewartet hat (Festplatte, Hardware). Er weist immer in die richtige Richtung - du musst nicht raten und an der falschen Stelle graben.
Wer löst die Speicherbereinigung manuell aus. Manchmal befiehlt ein Mod selbst "Müll jetzt bereinigen", und bei viel Speicher führt das zu einem Freeze. Der Befehl /sdebug gccallers zeigt, welcher Mod das tut (detailliert und mit einem Beispiel - im Abschnitt über Befehle unten).
Schlechte Einstellungen für die Speicherbereinigung. Der Befehl /sdebug env zeigt, ob der schnelle Bereinigungsmodus aktiviert ist, und wenn nicht, kann dies behoben werden (Ausgabebeispiel und wie man es repariert - siehe unten).

Hilft, nennt aber den Schuldigen nicht automatisch

"Schwerer Code" (Heavy Code). Stell dir vor: Ein Mod-Autor hat einen Fehler gemacht, und sein Mod berechnet jeden Tick unnötigerweise alle 5000 Beete auf dem Server neu, wie zum Beispiel der Mod Wild Farming. Der Speicher wächst nicht - der Code leistet einfach zu viel Arbeit. Das ist KEIN Speicherleck, und whodunit ist hier nutzlos.
Was der Mod tun wird: stalls (siehe unten) wird deutlich schreiben "Das ist schwerer Code, nicht Speicherbereinigung" - das heißt, er gibt die richtige Richtung an. Um den spezifischen Mod zu finden, gibt es profile (siehe unten) - er misst die Zeit nach Codeabschnitten. Aber er betrachtet nicht alle Mods nacheinander, sondern nur die in den Einstellungen angegebenen (oder ähnliche). Hier gilt also nicht "Klicken - Namen erhalten" wie bei einem Leck: Du musst dem Debugger möglicherweise einen Hinweis geben, wo er suchen soll. Es gibt Hilfe, aber keinen Automatismus; du musst die verdächtigen Mods durchgehen.

Kann gar nicht

Lags durch Festplatte, Netzwerk oder schwache Hosting-Hardware. Der Mod wird sagen "Die Ursache liegt nicht im Mod-Code" - aber er kann es nicht reparieren. Das ist eine Sache für den Hoster.
Spieler-Lags (niedrige FPS, ruckelndes Bild). Der Mod ist rein serverseitig; den Client sieht er überhaupt nicht.
"Schwer, aber richtig". Wenn dieselben 5000 Beete ehrlich berechnet werden müssen und es keinen Fehler im Code gibt, zeigt der Mod, dass die Zeit dorthin fließt, aber das ist kein Bug mehr, sondern eine Frage des Mod-Designs. Dies wird nicht durch Debugging behoben, sondern durch eine Überarbeitung des Mods (oder Verringerung der Serverlast).

In einem Satz

Ein Speicherleck wird er selbst finden und den Schuldigen benennen. Bei allem anderen wird er dir die richtige Richtung weisen ("es ist der Code", "es ist die Festplatte", "es ist die Speicherbereinigung"), aber danach musst du selbst überlegen.

Womit man anfangen sollte

/sdebug stalls - Analyse der letzten Freezes

Wann eingeben: Als Erstes, sobald der Server laggt oder kürzlich gelaggt hat. Dies ist der Einstiegspunkt für jede Untersuchung - er wird dir sagen, in welche Richtung du weitergraben musst. Auf einem frisch gestarteten, ruhigen Server wird er leer angezeigt (es gab noch keine Freezes) - das ist normal.

Der Mod fängt Freezes selbst ab und speichert deren Analyse. Dieser Befehl zeigt die letzten an (standardmäßig 5). Jeder Freeze ist ein Block, und die letzte Zeile darin ist das Urteil im Klartext, wohin die Zeit geflossen ist. Beispiel:

ServerDebugger: FREEZE 
  Dauer            : 5084 ms
  GC pause         : 5008 ms  (99%)
  ...
  URTEIL : GC-PAUSE. Der Server hat Müll bereinigt. Auf Lecks prüfen: /sdebug leak

Oder, wenn nicht der Müll schuld ist, sondern der Code:

  URTEIL : DER PROZESS HAT TATSÄCHLICH GERECHNET, GC hat nichts damit zu tun => heißer Code.
            Aktivieren Sie /sdebug profile on, um herauszufinden, welcher.

Wichtig und ehrlich: stalls benennt von sich aus keinen bestimmten Mod. Er gibt nur die Richtung vor - "es ist Speicherbereinigung" / "es ist Code" / "es ist Warten auf die Festplatte". Wer genau schuld ist, finden die folgenden Befehle, jeder für seine eigene Richtung. Wohin nach dem Urteil:Urteil "GC-PAUSE" -> Das ist der Speicher. Gehe zum Abschnitt "Über Lecks" unten (leak und whodunit) und prüfe auch gc.
Urteil "heißer Code" -> Gehe zu profile / top.
Urteil "Warten auf Festplatte / Lock" -> Das ist meistens Hosting-Hardware, kann nicht mit Code repariert werden.

/sdebug env - Allgemeiner Serverstatus

Wann eingeben: Jederzeit, direkt nach stalls für einen allgemeinen Überblick. Der Server sollte einfach laufen, es muss keine Bereinigung gestartet werden - der Befehl liest den aktuellen Status.

Zeigt einen Block wie diesen an (unnötiges entfernt):

ServerDebugger: Umgebung 
  ProcessorCount       : 24
  Server GC            : False        <- diese Zeile ist wichtig
  Pause time %         : 18.5         <- und diese
  Memory load          : 6400 MB / 16000 MB

Was man lesen sollte:

Server GC - ob der schnelle Modus für die Speicherbereinigung aktiviert ist. False = langsamer Single-Thread, die Bereinigung bremst stärker, als sie müsste. Das ist eine "schlechte Servereinstellung". Wie man das behebt - im Abschnitt "Speicherbereinigung beschleunigen" ganz am Ende der README. Nach der Reparatur wird die Zeile zu True.
Pause time % - welcher Anteil der Zeit für die Speicherbereinigung aufgewendet wird. Einstellige Prozentsätze sind normal. 15% und höher (wie 18.5 im Beispiel) - die Bereinigung ist genau dein Problem.
Memory load - wie viel Speicher belegt ist. Wenn er nahe am Limit ist, kann der Speicher selbst zur Ursache werden.

Über Lecks - zwei Befehle der Reihe nach

Wenn stalls das Urteil "GC-PAUSE" zeigte, ist es höchstwahrscheinlich ein Leck. Wird in zwei Schritten gefunden: Zuerst prüft /sdebug leak, ob überhaupt eines vorhanden ist, dann nennt /sdebug whodunit den Schuldigen. Werden genau in dieser Reihenfolge verwendet.

/sdebug leak - SCHRITT 1: Gibt es überhaupt ein Leck?

Wann eingeben: Wenn der Serverspeicher im Laufe der Zeit wächst und Lags zunehmen - und unbedingt, nachdem der Server eine Weile gelaufen ist (ein bis zwei Stunden nach dem Start oder nach einer Ingame-Nacht, wenn viele Mobs vorbeigezogen sind). Auf einem frisch gestarteten Server hat sich das Leck noch nicht angesammelt, und der Test wird leer ausfallen.

Der Befehl führt eine manuelle Speicherbereinigung durch (der Server friert für ein paar Sekunden ein) und zählt, wie viele tote Mobs sie überlebt haben.

"Überlebt" = sollten verschwunden sein, aber jemand hält sie, und die Bereinigung konnte sie nicht wegwerfen. Die Logik ist einfach: Lebende Mobs werden von der Bereinigung nicht berührt, aber wenn ein längst verschwundener Mob die Bereinigung "überlebt" hat, bedeutet das, dass er illegal gehalten wird, und das ist ein Leck.

Was er zeigt: den Prozentsatz der Überlebenden.

Um null herum - es gibt kein Leck. Damit sind wir mit den Lecks hier fertig, suche die Ursache für die Lags woanders (siehe stalls, env).
80% und höher - es gibt ein Leck. Gehe zu Schritt 2 - /sdebug whodunit.

/sdebug whodunit - SCHRITT 2: Wer ist schuld am Leck?

Wann eingeben: Direkt nachdem /sdebug leak einen hohen Prozentsatz gezeigt hat (Leck bestätigt). Vorher hat es keinen Sinn - wenn es kein Leck gibt, gibt es auch keinen Grund, nach dem Schuldigen zu suchen.

Dieser Befehl macht auch Folgendes:

Führt eine manuelle Speicherbereinigung durch (der Server kann für ein paar Sekunden einfrieren).
Findet alle toten Mobs, die noch von jemandem gehalten werden.
Verfolgt, wer genau sie hält, und über welchen Mod diese Referenz verläuft.
Gibt eine Liste aus: welcher Mod wie viele tote Objekte hält, mit Dateinamen und Ort im Code.

Es muss vorab nichts konfiguriert werden. Das Ergebnis sieht so aus:

  WER HÄLT DAS LECK 
  verfolgt 14203 Objekte zum Halter in 8 s
    gehaltene Objekte, nach Mods
 14203 <- Rust and Rustbound Creatures
     Datei : RustboundCreatures.dll 
     Typ : RustCreaturesReworked.BowtornTuning 
     Feld : MoveSpeedBaselines 18 <- Anderer Mod 3 <- Vanilla / Engine

Die erste Zeile ist der Hauptschuldige. Dann entscheidest du: Mod löschen, aktualisieren oder dem Autor von dem Problem schreiben.

/sdebug entities - Gesamtzahl der lebenden Mobs in der Welt

Wann eingeben: Jederzeit, wenn du verstehen willst, ob es wirklich viele Mobs in der Welt gibt, oder ob sie nur im Speicher "hängen". Nützlich zusammen mit /sdebug leak - zusammen unterscheiden sie ein Leck von einem echten Ansturm.

Zeigt, wie viele Entitäten das Spiel selbst als geladen betrachtet, aufgeschlüsselt nach Art und nach den am stärksten "bevölkerten" Bereichen der Karte.

Warum: Um ein Leck von einem echten Ansturm zu unterscheiden. Wenn der Befehl 80.000 Mobs anzeigt - dann sind sie wirklich in der Welt, etwas hat das Spawn-Limit durchbrochen. Wenn er 200 anzeigt und /sdebug leak gleichzeitig Tausende von "toten" findet - bedeutet das, dass die Mobs längst verschwunden sind, aber im Speicher hängen. Das ist ein Leck.

Sonstiges

/sdebug threshold [ms] - ab welcher Dauer ein Freeze in das Log aufgenommen wird (Standard ist 500 ms = eine halbe Sekunde).
/sdebug lang [Code] - Ausgabesprache (siehe unten).
/sdebug reset - Gesammelte Statistiken löschen.

Mod-Konfiguration

Beim ersten Start wird die Datei ModConfig/ServerDebuggerConfig.json erstellt:

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

Language - Standard-Ausgabesprache.
StallThresholdMs - ab welcher Dauer (in Millisekunden) ein Freeze es wert ist, im Log aufgezeichnet zu werden. 500 = eine halbe Sekunde.
WatchedModMarkers - ein Hinweis für /sdebug profile und /sdebug findroot, auf welche Mods standardmäßig geachtet werden soll. Die Werte xskills, xlib usw. hier sind nur ein Beispiel (der Mod wurde ursprünglich beim Debuggen dieser Mods geschrieben). Dies ist keine Abhängigkeit: ServerDebugger selbst hängt überhaupt nicht von xskills/xlib ab und funktioniert auf jedem Server mit beliebigen Mods. Wenn du möchtest - lösche sie und trage deine eigenen ein, oder lass es wie es ist. Die Hauptbefehle (whodunit, leak, entities, stalls, gc, gccallers, env) ignorieren diese Liste und funktionieren immer. Ein normaler Benutzer muss dies nicht anfassen.

Sprache

Ausgabesprache im laufenden Betrieb ändern:

/sdebug lang de

Die Auswahl wird gespeichert. Ohne einen Code zeigt der Befehl die aktuelle Sprache und eine Liste der verfügbaren an.

Eigene Sprache hinzufügen: Kopiere assets/serverdebugger/lang/en.json in eine Datei mit deinem Code (z.B. de.json) und übersetze die Werte. Die Platzhalter {0}, {1} und Befehle /sdebug ... dürfen nicht angetastet werden - nur der Text darum herum. Die Datei wird automatisch übernommen. Wenn eine Zeile in deiner Datei fehlt, wird die englische ersetzt, sodass du schrittweise übersetzen kannst.

Technische Wörter (Namen von Bereinigungsgründen wie AllocSmall, Code-Ortsnamen in der findroot-Ausgabe) werden absichtlich nicht übersetzt - sie sind Identifikatoren, sie müssen so gesehen werden, wie sie sind.

Speicherbereinigung beschleunigen (wenn env Server GC : False zeigte)

Dies ist genau das "Wie man das behebt", das in der Beschreibung von /sdebug env erwähnt wird. Wenn der Befehl Server GC : False auf einem leistungsstarken Server zeigte - läuft die Speicherbereinigung in einem einzelnen Thread, langsam, und die Pausen sind länger als sie sein könnten. Es wird durch Bearbeiten einer Konfigurationsdatei geheilt.

Was zu tun ist

Finde über den Hosting-Dateimanager die Datei VintagestoryServer.runtimeconfig.json (befindet sich neben dem Server selbst).
Mache zuerst eine Kopie davon - falls etwas schief geht, kannst du es wiederherstellen.
Öffne die Datei. Darin befindet sich ein Abschnitt namens configProperties. Füge vier Zeilen hinzu (vergiss das Komma am Ende der vorherigen Zeile nicht):

"System.GC.Server": true,
"System.GC.Concurrent": true,
"System.GC.HeapCount": 6,
"System.GC.HeapHardLimitPercent": 30

Die gesamte Datei wird in etwa so aussehen:

{
  "runtimeOptions": {
    "tfm": "net10.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "10.0.0"
    },
    "configProperties": {
      "System.Reflection.Metadata.MetadataUpdater.IsSupported": false,
      "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization": false,
      "System.Runtime.TieredPGO": true,
      "System.GC.Server": true,
      "System.GC.Concurrent": true,
      "System.GC.HeapCount": 6,
      "System.GC.HeapHardLimitPercent": 30
    }
  }
}

Speichere die Datei und mache einen vollständigen Neustart des Servers - nicht "reload", sondern einen echten Neustart. Die Einstellung wird nur beim Start gelesen, sonst wird sie nicht angewendet.
Überprüfe: Gib /sdebug env ein. Die Zeile sollte zu Server GC : True werden und Pause time % merklich sinken.

Was diese Zeilen bedeuten (in einfachen Worten)

Server GC - aktiviert die schnelle Speicherbereinigung in mehreren Threads statt in einem. Das ist die Hauptsache.
Concurrent - ein Teil der Bereinigung läuft im Hintergrund ab, ohne den Server anzuhalten.
HeapCount - auf wie viele Kerne die Bereinigung verteilt werden soll. Wir setzen 6: schnell, aber nicht zu gierig nach Speicher (ohne ein Limit würde die Bereinigung viel mehr Speicher beanspruchen).
HeapHardLimitPercent - Speicher-Obergrenze für den Server, eine Absicherung gegen Aufblähen. Achtung: Auf einem billigen Host sieht das Spiel möglicherweise den Speicher der gesamten physischen Maschine, nicht nur deinen Anteil - dann wird der Prozentsatz davon berechnet, und 30% könnten mehr sein als dein Tarif-Limit. Wenn du dein RAM-Limit kennst und es klein ist - verringere diese Zahl (z. B. auf 12–15).

Was zu erwarten ist

Auf einem realen Server reduzierte diese Einstellung die Zeit in Pausen von 28% auf weniger als 1%, und Freezes durch Speicherbereinigung wurden fast unbemerkt. Dies repariert kein Leck (ein Leck muss separat über whodunit entfernt werden), aber es macht jede Speicherbereinigung um ein Vielfaches schneller.