benchmarking: large-memory glutton workloads (--mem-targetLarge mem bench

[Lucky Abolorunke (Oneimu)]

What the PR does, in plain terms

Before this PR, our benchmark actor (glutton) was a tiny program using only a few megabytes of memory. Every performance number on our dashboard—how long suspend takes, how long resume takes—was measured against actors that are nearly empty. Real agent workloads aren't empty; they hold hundreds of megabytes to gigabytes of memory.

This PR teaches glutton to act like a large application:

• Active Memory Allocation: You pass it a single flag—--mem-target=1Gi—and it allocates that much memory and actively keeps dirtying/rewriting it the way a busy application would.
• Exercising Real Snapshots: Memory that is merely reserved but never touched is invisible to snapshotting. Memory that is actively dirtied is what suspend actually has to save and resume has to reload, meaning the benchmark now exercises the underlying machinery realistically.
• Permanent Benchmark Suites: It wires the flag through deployment scripts and adds four permanent benchmark suites: 1GB and 2GB actors, on both gVisor and microVM. These run regularly so the dashboard builds historical data at realistic sizes.

How it helps the optimization goal

Our benchmarks already break down every suspend/resume lifecycle into granular phases: pause, snapshot, compress, upload, download, and restore. With tiny actors, all of those phases finished too quickly to reveal bottlenecks or measure whether a change actually helped.

With large actors, each phase has a measurable cost, giving us three key advantages:

1. A "Before" Baseline: We now know what a 2GB actor's suspend actually costs, phase by phase, on each runtime. You cannot demonstrate an improvement without a solid baseline to compare against.
2. Phase-Specific Attribution: Wins land in the exact right column. When someone optimizes the durable-dir tar format, the tar phase should shrink and nothing else. When someone adds snapshot caching, the download phase should shrink and nothing else. The breakdown at scale turns "this should be faster" into "this phase went from X to Y."
3. Continuous Regression Detection: The dashboard history acts as an objective referee over time. If a future change quietly degrades 2GB restores, the trend line catches it immediately.

[Benjamin Elder (BenTheElder)]

nit: if we're doing this sort of check, we should ensure time.Duration is not negative either (ticker will panic on negative)

[Max Smythe (maxsmythe)]

I like the idea of patterns of memory usage and we definitely need a memory benchmark. I wonder about using flags to configure it, which may not be super flexible.

What do you think about adding the ability to invoke this behavior via HTTP/proto api?

substrate/internal/proto/glutton/glutton.proto

Lines 68 to 76 in ecca2ca

	message WriteRAMRequest {
	// name of the array to be written to
	string key = 1;
	// size of bytes to be written
	int32 size = 2;
	WriteMode write_mode = 3;
	}

Advantages:

• No need to customize launch flags
• Can easily run heterogenous/changing workloads throughout the fleet, using user classes and workload shapes.
• Can control the pacing of the behavior

Disadvantages

• Every behavioral change requires a network request
• More complex behaviors are hard to model (though flags have this problem too, some kind of scripting solution would be needed)

[Max Smythe (maxsmythe)]

Also we would need to have something that drives suspend/resume/etc. and gathers the latency measurements