cluster-sim · google trace 2011-v2 · day-1 replay + production-band studies · seed 1

Twenty-one scoring functions, one very full cluster

A single greedy rule decides where every task lands in a warehouse-scale cluster: score each feasible machine, pick the argmax. This page compares 21 such scoring functions on the Google 2011 production trace — the classics, the heuristic AlphaEvolve discovered for Borg (Fig. 6 of that paper), nine designed variants, and the champion of our own evolutionary search — across four experimental regimes: a saturated snapshot, a priority-blind replay, a Borg-style preemptive replay, and the uncongested production band. Click a chip to hide or show a policy in every chart.

The policies

Every policy sees one pending task and one candidate machine at a time and returns a score; the task goes to the highest-scoring feasible machine (ties to the lowest index; 64 randomly sampled machines per decision, Borg-style). Grouped by the idea each family exploits; within a family, variants draw in lighter steps of the family hue with distinct dash patterns.

Notation

The metrics

Following “Evaluating job packing in warehouse-scale computing” (IEEE Cluster 2014): utilization alone barely separates policies, so packing quality is probed with counterfactuals — how small a cluster would do, how much more workload would fit, and how usable the leftover space is.

Experiment 1 · snapshot packing — peak instant, packed from scratch

The 155,199 tasks alive at day 1’s busiest instant (9 h in) demand 113% of cluster CPU and 95% of memory, so nothing can place everything — this is a stress test of who fits the most and what shape they leave the free space in. Bars are means/medians over 5 shuffled orders.

Experiment 2 · priority-blind replay — the same stream, scheduled live

723,984 tasks arrive over day 1 and the backlog drains as tasks finish. Tasks that fit nowhere wait in a single FIFO pending queue — no priorities, no preemption.

Cluster over time

Allocated CPU as % of capacity; day-1 arrivals plus the first day of drain-out.

Scheduling latency — arrival to placement

Strip spans p50 → p99; dots mark p50, p90, p99. Shorter and further left is better.

Experiment 3 · preemptive replay — production evicts batch

Same day-1 stream, Borg-style: pending tasks drain highest priority band first, and a production/monitoring task (priority ≥ 9) that fits nowhere may evict batch tasks (lowest priority, largest first, on the machine needing the least eviction). Victims re-queue and resume their remaining duration; production is never evicted.

Experiment 4 · the production band alone — a consolidation problem

Only priority ≥ 9 tasks, full 29 days, with the 6 near-machine-sized whale tasks excluded (any dimension > 0.9). The month’s production peak lands on day 3 at just 65% CPU / 52% memory — production is never latency-constrained here (every policy replays 1, 7, and 29 days with zero queueing), so the contest is purely about packing quality.

What the results say

Cross-experiment reading of the tables and charts above.

All numbers

Everything the charts show (and a few things they don’t), one row per policy.

Day-1 mixed workload — stress snapshot

Day-1 mixed workload — replay, without and with preemption

Production band, 29 days, whale-free — snapshot