What happens
netclawd runs with Server GC, because Netclaw.Daemon builds on the Web SDK and nothing overrides the default. In a memory-limited container (we run these at a 1Gi cap) Server GC is the wrong trade: it reserves larger heap segments, keeps one heap per core, collects Gen2/LOH less eagerly, and is slow to hand memory back to the OS. The result is a higher peak RSS and a worse chance of riding out a transient spike before the cgroup OOM killer steps in.
Why
The daemon project uses Microsoft.NET.Sdk.Web, which turns ServerGarbageCollection on by default, and there's no override anywhere in the project tree:
|
<Project Sdk="Microsoft.NET.Sdk.Web"> |
netclawd is a single-tenant, low-concurrency process — one operator, a handful of sessions, a SignalR gateway and webhook listener. That's the workload Workstation GC is meant for. Server GC's throughput benefit (saturating many cores under heavy allocation churn) doesn't apply, and we pay its memory cost instead.
This showed up in practice: a daemon doing autonomous log-pulling spiked past its 1Gi limit and got SIGKILL'd (the entrypoint restarts the inner process, so the pod restart count stays 0 and it's easy to miss). The underlying allocation problem is the unbounded shell read in the companion issue; Server GC is what turns that spike into a kill instead of a hiccup.
Suggested direction
Switch the daemon to Workstation GC, ideally with background collection on:
<ServerGarbageCollection>false</ServerGarbageCollection>
<ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
(Equivalent to DOTNET_gcServer=0 as deployment env, but baking it into the binary keeps it consistent across every deployment.) Optionally pair with DOTNET_GCConserveMemory for the most constrained containers.
A PR doing exactly this is open alongside this issue. Worth a sanity check that no high-throughput self-hosted deployment is depending on Server GC; for the agent's actual concurrency profile, Workstation should be the better default.
What happens
netclawdruns with Server GC, becauseNetclaw.Daemonbuilds on the Web SDK and nothing overrides the default. In a memory-limited container (we run these at a 1Gi cap) Server GC is the wrong trade: it reserves larger heap segments, keeps one heap per core, collects Gen2/LOH less eagerly, and is slow to hand memory back to the OS. The result is a higher peak RSS and a worse chance of riding out a transient spike before the cgroup OOM killer steps in.Why
The daemon project uses
Microsoft.NET.Sdk.Web, which turnsServerGarbageCollectionon by default, and there's no override anywhere in the project tree:netclaw/src/Netclaw.Daemon/Netclaw.Daemon.csproj
Line 1 in 60601c6
netclawdis a single-tenant, low-concurrency process — one operator, a handful of sessions, a SignalR gateway and webhook listener. That's the workload Workstation GC is meant for. Server GC's throughput benefit (saturating many cores under heavy allocation churn) doesn't apply, and we pay its memory cost instead.This showed up in practice: a daemon doing autonomous log-pulling spiked past its 1Gi limit and got SIGKILL'd (the entrypoint restarts the inner process, so the pod restart count stays 0 and it's easy to miss). The underlying allocation problem is the unbounded shell read in the companion issue; Server GC is what turns that spike into a kill instead of a hiccup.
Suggested direction
Switch the daemon to Workstation GC, ideally with background collection on:
(Equivalent to
DOTNET_gcServer=0as deployment env, but baking it into the binary keeps it consistent across every deployment.) Optionally pair withDOTNET_GCConserveMemoryfor the most constrained containers.A PR doing exactly this is open alongside this issue. Worth a sanity check that no high-throughput self-hosted deployment is depending on Server GC; for the agent's actual concurrency profile, Workstation should be the better default.