Mem Leak Inspector

<div style="font-family: Georgia, 'Times New Roman', serif; line-height: 1.7; color: #2a2520; max-width: 760px; margin: 0 auto;"> <p style="text-align: center;"><img src="https://i.imgur.com/GAefNoo.png" alt="image" /></p> <p style="font-size: 17px; text-align: center;">Mem Leak Inspector is a server-side diagnostics mod that tracks live object instances, snapshots heap state, diffs changes over time, highlights leaking chunks in-world, and exports everything to CSV, JSON, or an offline browser dashboard.</p> <p>It started as a simple "count the entities and tell me if the number keeps going up" tool for tracking down a stubborn memory leak on a modded server. That worked, so I added diffing between snapshots, then heatmaps, then thread monitoring, and by 1.1 the single-file architecture was holding things together with duct tape. Version 2.0 is a ground-up rewrite - same commands, same features, cleaner internals, and a proper test suite so things don't regress when I add the next thing.</p> <p style="color: #6b5d50; font-style: italic; text-align: center;">Server-side only. No client install required. Vintage Story 1.22+.</p> <hr style="border: none; border-top: 1px solid #c9bca8; margin: 28px 0;" /> <h2 style="color: #5a4a3a; margin-bottom: 8px; text-align: center;">What it does</h2> <p>The core workflow is: take a snapshot, do something, take another snapshot, diff them. The diff tells you which types grew and by how much. From there you can drill down:</p> <ul style="padding-left: 22px;"> <li><strong>Memory snapshots</strong> - capture live instance counts per type, estimated memory footprint, per-chunk density, and optional per-instance positions. Snapshots save to compressed JSON with configurable retention.</li> <li><strong>Snapshot diffing</strong> - compare any two snapshots to see which types grew, shrank, or appeared. <code>/mem diff before after</code> is the command you'll use most.</li> <li><strong>In-world heat overlay</strong> - <code>/mem showheat</code> sends chunk-level colored highlights to all online players showing where instance growth is concentrated. Red means something's accumulating there.</li> <li><strong>Type watchers</strong> - <code>/mem watch EntityItem 30</code> polls that type every 30 seconds and logs whether the count is stable, growing, or "LEAKING". <code>/mem alertwatch</code> does the same thing across all types with configurable spike thresholds.</li> <li><strong>Thread monitoring</strong> - see every OS-level thread's state, wait reason, and CPU time. The background logger builds a rolling history and exports ASCII graphs and CSV on stop.</li> <li><strong>.NET runtime counters</strong> - live sampling of allocation rate, GC heap size, working set, and collection counts. Export the full history as a wide CSV for charting in Excel or a notebook.</li> <li><strong>Tracking filters</strong> - regex-based allow/deny lists so you only track what matters. Exclude particle systems and transient effects that would otherwise dominate the counts.</li> <li><strong>Teleport to instance</strong> - <code>/mem tp &lt;id&gt;</code> jumps you to the world position of any tracked entity or block entity. Useful when you know <em>what</em> is leaking and need to see <em>where</em>.</li> </ul> <p>Everything exports to CSV or JSON. The included offline dashboard (a static HTML page) lets you drag-and-drop exported files for sorting, filtering, and charting without any server connection.</p> <hr style="border: none; border-top: 1px solid #c9bca8; margin: 28px 0;" /> <h2 style="color: #5a4a3a; margin-bottom: 8px; text-align: center;">Who it's for</h2> <p><strong>Server admins</strong> tracking down why memory usage climbs over a play session. Take periodic snapshots, diff them, and the growing types point you toward the problem - usually a mod spawning entities that never despawn, or block entities accumulating in chunks that should have been unloaded.</p> <p><strong>Mod developers</strong> profiling their own code. Watch a specific type while you test a feature, and the log tells you immediately if instances are leaking. The per-instance position tracking and teleport command let you inspect exactly where the leaked objects ended up.</p> <p><strong>Anyone debugging performance.</strong> The thread monitor and runtime counters catch problems that aren't visible in the entity count - threads stuck in unexpected states, GC pressure from allocation-heavy code paths, working-set growth that doesn't correlate with entity counts.</p> <hr style="border: none; border-top: 1px solid #c9bca8; margin: 28px 0;" /> <h2 style="color: #5a4a3a; margin-bottom: 8px; text-align: center;">Quick start</h2> <table style="border-collapse: collapse; margin: 8px auto;"> <tbody> <tr> <td style="padding: 4px 24px 4px 0;"><code>/mem snap before</code></td> <td>Take a baseline snapshot</td> </tr> <tr> <td style="padding: 4px 24px 4px 0;"><em>(do the thing you suspect leaks)</em></td> <td>&nbsp;</td> </tr> <tr> <td style="padding: 4px 24px 4px 0;"><code>/mem snap after</code></td> <td>Take a second snapshot</td> </tr> <tr> <td style="padding: 4px 24px 4px 0;"><code>/mem diff before after</code></td> <td>See what changed</td> </tr> <tr> <td style="padding: 4px 24px 4px 0;"><code>/mem showheat</code></td> <td>Highlight growth in-world</td> </tr> </tbody> </table> <p style="color: #6b5d50; font-style: italic; text-align: center;">All commands require the <code>controlserver</code> privilege. Use <code>/help mem</code> for the full list.</p> <hr style="border: none; border-top: 1px solid #c9bca8; margin: 28px 0;" /> <h2 style="color: #5a4a3a; margin-bottom: 8px; text-align: center;">Configuration</h2> <p>Settings live in <code>ModConfig/MemLeakInspectorConfig.json</code> and are split into sections - <code>Snapshots</code>, <code>Tracking</code>, <code>Alerts</code>, <code>Threads</code>, <code>Heat</code>, and <code>Runtime</code> - each with documented defaults. The config auto-migrates from the 1.x fl