Server Consolidation with Pyvorin

Server consolidation fails in one of two ways: it removes machines that were doing real work, or it keeps machines that stopped doing real work years ago. A runtime compiler helps with the second failure only, and only if you measure before you remove. The sequence is fixed — measure the workload, establish the redundancy floor, consolidate the surplus, then verify the latency after the change — and this page walks through it with a labelled illustrative model whose every assumption is stated. All savings figures below are class C: modelled, not measured, and never a customer result.

What consolidation actually is

Consolidation means raising utilisation by running the same workload on fewer machines. It is the fixed-capacity version of the cloud-bill problem: where an autoscaling group converts freed time into money, a datacentre or reserved fleet converts freed time into machines you can decommission, redeploy or simply not replace at end of life. The conversion is slower and lumpier — hardware retires on procurement cycles, not on billing cycles — but the first step, knowing how much headroom you truly have, is identical.

Headroom is not a benchmark number. It is a measured utilisation profile: how busy each machine actually is across the business day, the month-end batch and the seasonal peak. Pyvorin's contribution is to shift that profile. Where the workload is CPU-bound pure-Python execution, the compiled path frees real CPU; where it is I/O- or library-bound, it frees nothing measurable. The plan must be built on measured headroom, not assumed headroom — the two are rarely the same number. Our published suite shows both shapes clearly — a 202.8x best case on a numeric integration kernel, a 0.05x worst case on overhead-dominated micro-workloads, and a median of 1.35x across 71 workloads. Consolidation planning must be built on your own measured position inside that distribution, not on any of those headline numbers.

Measure first

Three measurements come before any decommissioning decision.

The speedup, per workload. Run python -m pyvorin bench against the actual entrypoints on a machine that matches production. Compile time is reported separately from execution time, so judge amortisation against your real call frequency: a function compiled in 260 ms that serves a million calls a day costs nothing; the same function called twice a day costs more than it saves. Keep the raw JSON output — raw_times_ms, correct, fallback_count — as the record for the decision.

The utilisation profile. A week of machine-level CPU, memory and I/O data, captured at peak and off-peak. Memory matters more than people expect: a workload that halves its CPU time but keeps the same resident memory footprint frees compute capacity, not consolidatable capacity. If the binding constraint is RAM or disk, CPU speed does not move it. Watch concurrency as well as averages — a workload whose p99 latency depends on burst parallelism may consolidate its average CPU beautifully while its tail latency falls off a cliff on fewer machines.

The fallback share. Unsupported constructs divert to honest CPython fallback at runtime, and the fallback is recorded. A workload where 40% of calls land on the fallback under measurement will not consolidate as the headline speedup suggests. The support command shows per-function support tiers before you benchmark, so you can scope this quickly.

The redundancy floor

The machines you must never remove are the ones that absorb failure. The redundancy floor typically covers the loss of one node per failure domain, plus headroom for failover traffic and maintenance windows. Consolidation arithmetic starts above this floor, never below it.

This is the engineering-judgement moment, and it deserves to be stated plainly: the cheapest consolidation is the one that keeps N+2, not N+1, because the second spare is what lets you patch, drain and rebuild while the first spare carries load. Finance will prefer N+1 — it always does. The person who signs off on the decommission list should be the person who will be paged when a node dies during a patch window at 3 a.m. Consolidate below the safe floor and you have not saved money; you have borrowed it from an incident that has not happened yet.

An illustrative model

Assumptions, stated in full:

• A fleet of 30 application servers running a CPU-bound Python workload, assumed to cost £400 per month each to run — hardware amortisation, power, cooling, rack space and administration combined. That unit cost is an assumption; use your own fully-loaded figure.
• A measured 2.0x speedup on the dominant workload — an assumption, chosen to be ordinary. Your measured figure replaces it.
• Steady-state CPU utilisation before: 80% at peak, which is why the fleet is the size it is.
• After compilation, peak utilisation on the same 30 machines drops to a modelled 40%, because the accelerated workload now occupies half the CPU time.
• Target utilisation after consolidation: 80% again. The workload that 30 machines carried now needs a modelled 15.
• Redundancy floor: N+2 retained within the new fleet.
• Licence: Business at £399 per month.

The modelled saving is £5,601 per month on those assumptions. Now watch how fragile it is. If the measured speedup is the suite median of 1.35x instead of 2.0x, peak utilisation falls to a modelled 59% and the same target utilisation needs 22 servers — the fleet cost falls from £12,000 to £8,800, and the modelled saving drops to around £2,800 per month before considering that a smaller fleet may also change the redundancy arithmetic. If memory, not CPU, binds, the fleet cannot shrink at all and the saving is zero until hardware refresh. If the workload is string-parsing-bound and measures at or below 1x, consolidation is off the table entirely. The arithmetic is simple; the inputs deserve respect.

How the freed capacity gets reclaimed

Headroom becomes money through one of three routes, in order of commitment. The cheapest is deferral: a fleet that no longer needs its next planned expansion simply does not buy it, and the saving arrives on the procurement calendar with zero risk. The middle route is redeployment: the freed machines absorb other workloads — the staging environment, the analytics cluster, the disaster-recovery replica — and the saving arrives as avoided purchases elsewhere in the budget. The most committed route is decommission: machines leave the rack, and power, cooling, rack space and administration fall with them. Decommissioning carries the highest reversal cost, so it earns its place only after a full quarter of observed headroom at peak.

Container density sits across all three routes. A node running at forty per cent CPU can host more workloads per machine without contention — but density raises the blast radius of a node failure, which is another argument for keeping the redundancy floor generous while the new equilibrium proves itself.

A consolidation checklist

The sequence, condensed for a change ticket:

• Benchmark every candidate workload on production-like hardware; record the JSON.
• Capture at least a week of machine-level CPU, memory and I/O, including the peak window.
• Compute peak server-equivalents of work, divide by the measured speedup, and size the new fleet at the target utilisation.
• Check the memory constraint independently of CPU; halved CPU with unchanged RAM consolidates nothing.
• Add the redundancy floor — N+2 unless a written risk decision says otherwise.
• Load-test the new fleet at peak before decommissioning anything.
• Quarantine the freed capacity for one quarter; reallocate only after the seasonal peak has passed clean.

Every step exists because someone, somewhere, skipped it and paid for the lesson in an incident review. The order is not ceremonial.

One organisational note: consolidation lands badly when it arrives as a surprise. Finance should see the model before the change — including the conservative row, which may say the saving is years away — and the platform team should own the new fleet size, not inherit it. A decommission list that everyone has signed is a formality; a decommission list that someone first saw during the change window is a future rollback.

After the change

Consolidation is a capacity change, not a compiler setting, so verify it like a capacity change. Re-run the latency checks at the new fleet size under production load, watch the fallback counters for the first weeks, and keep the decommissioned capacity earmarked for one full quarter before it is reallocated — the month-end batch that runs twice a year has a habit of appearing four weeks after you declare victory. Compile caches are invalidated by source, options and runtime changes, so a redeploy will recompile once; that one-time cost belongs in the plan, not in the incident log.

Finally, record the decision in the same place you record capacity decisions. The model's assumptions — measured speedup, utilisation figures, redundancy floor — are exactly the facts the next consolidation round, or the next hardware refresh, will need. A consolidation that ships with its numbers attached is a reusable asset; one that ships as folklore is a question your successor will re-answer expensively.

Where to go next

• Benchmarks — the measured distribution your consolidation plan borrows its speedup from.
• Benchmark methodology — which compiler path produced each published figure.
• How to benchmark a function — measure your entrypoints on production-like hardware.
• Unsupported code and the fallback path — how fallback events are recorded and why they matter to capacity maths.

Last reviewed 18 March 2026. All savings figures are class C (modelled) from the labelled illustrative model above; benchmark inputs are class B from the canonical 2026-09-13 artefact; the licence figure is class A from the published plan table. No customer infrastructure data was used.