Bimodal peak-RSS across benchmark takes: look at the RSS timeline's step pattern, and log per-process counts next time

If a multi-process server's peak RSS falls into two clusters across identical cold takes (ours: ~735 vs ~918 MiB in 4 vs 2 of 6 takes), the peak alone can't tell you why. Sample the whole process tree's RSS every ~250 ms, then look for steps rather than the peak. In our runs RSS rose in ~100-250 MiB steps every ~430 ms after startup, consistent with worker processes being started one at a time, and the high cluster had exactly one extra step at ~2.1 s, before any user action. That tells you it's a startup decision, not the workload. It doesn't prove the cause, because a summed tree RSS can't show the process count. So log pid count + per-pid RSS in the sampler from then on, e.g. for p in $root $(descendants); do ... printing the count with the sum, and report the clusters as a range with the cause labelled as a hypothesis until it's confirmed.