Specifying a Bare-Metal Server, From RFQ to Rack

Specifying a bare-metal server should start with a profiling report, not a vendor's product page. Most procurement mistakes in this category trace back to the same root cause: somebody sized a machine off a spec sheet or a gut-feel rule of thumb instead of pulling actual telemetry from the workload that box will run. I've watched this happen at three different companies now, and it's never malicious, just rushed. This piece walks through what the measurement process looks like in practice: capturing real utilization data, writing an RFQ a vendor can price without guessing, and getting the thing racked and accepted without surprises. None of this is exotic. It's closer to bookkeeping than engineering. But bookkeeping is exactly what gets skipped when a team is under deadline pressure and just wants a PO cut. ## Why measured beats modeled Capacity planning models earn their keep on greenfield systems, the ones with no workload yet to observe. Once something is running, even on hardware that's badly matched to it, modeling should stop being your primary input. The workload itself, under real conditions, throwing off real numbers, tells you more than any spreadsheet will. Here's the failure mode, and I'd bet money you've seen a version of it. An application owner asks for "a server like the last one, but bigger." Whoever writes the RFQ pads CPU core count and RAM by 20 to 30 percent because that felt safe last time. Nobody checks whether the previous box was ever actually CPU-bound. Usually it wasn't. It was waiting on disk I/O or network latency, and all those extra cores sat idle while the real bottleneck went untouched. You end up paying for compute you don't need while starving the resource you do need, and the invoice doesn't tell you which is which. The fix is unglamorous. Run `top`, `vmstat`, `iostat`, and whatever APM tool your stack already has for at least one full business cycle, ideally two to four weeks so you catch batch jobs, month-end runs, and traffic spikes. Look at the CPU utilization distribution, not just peak or average; those two numbers alone will lie to you. A workload averaging 15 percent CPU but spiking to 95 percent for ninety seconds every hour needs a completely different chassis than one that sits at a steady 60 percent. The first wants burst headroom and probably benefits more from clock speed than core count. The second wants sustained throughput and scales better with more cores at a moderate clock. Memory tells its own story, and it's a story people misread constantly. Watch for swap activity, not committed memory. A server sitting at 90 percent memory utilization with zero swap is fine. The same number with active swapping means you're already undersized, and the application is degrading in ways your latency dashboard won't show you until a customer emails support. ## Turning telemetry into a spec Once you've got two to four weeks of real numbers, translating that into a hardware spec follows a rough sequence. Be conservative at each step, not generous. Start with CPU. Take peak sustained utilization, meaning sustained over minutes, not a one-second spike some monitoring agent happened to catch, and work backward to a core count and clock speed that keeps you under 70 to 80 percent at that peak. That headroom matters because a bare-metal box, unlike a cloud instance, doesn't resize on the fly at 2 a.m. when traffic doubles. Land near 100 percent on day one and you've got zero runway for growth over a service life that typically runs three to five years before refresh. Memory sizing has to account for peak resident set size, plus the OS, plus any caching layer, plus a buffer for growth. If your database's buffer pool wants 64GB and you're specced at 128GB, that headroom isn't waste. The filesystem cache puts it to work, and it buys you a year or two before someone's forced into a forklift upgrade nobody budgeted for. Storage is where profiling pays off hardest, because IOPS and throughput are different axes entirely, and vendors will happily sell you the wrong one if you let them. Small random reads, the kind an OLTP database throws off constantly, need IOPS: NVMe in a properly configured array. Sequential writes, like log ingestion or video transcoding, care about sustained throughput, and you can often get away with a cheaper tier of storage. Check `iostat -x` for your average I/O size and read/write ratio before you spec drives. Guess here and you end up either paying for NVMe performance you never touch, or buying spinning disks that choke on a queue depth your workload generates without even trying hard. Network is the most commonly under-specified piece, mostly because it's invisible right up until it isn't. If the workload does replication, backup, or serves high-throughput API traffic, pull actual peak network utilization in bytes per second, not connection count, and confirm the NIC and the switch port on the other end both support it. A 10Gb NIC plugged into a 1Gb switch port happens more than anyone wants to admit, and it happens because someone specced the server without ever calling the network team to ask what the rack actually supports. ## Writing an RFQ someone can actually quote An RFQ built on real numbers reads completely differently from one built on guesswork. Vendors notice immediately; their sales engineers have seen a thousand vague requests and they price around the ambiguity, not through it. "High-performance server for database workloads" forces a sales engineer to either guess at what you need or quote defensively high to avoid a support escalation six months out. That guesswork gets baked into your number whether or not you ever see it itemized. A specific RFQ, one stating sustained IOPS, peak concurrent connections, memory working set size, and expected growth across the refresh cycle, lets the vendor spec accurately and competitively. They're no longer covering for unknowns that were yours to resolve in the first place. Put your measured baseline in the document, in plain numbers. Actual peak CPU utilization, actual peak memory usage, actual IOPS and throughput, actual network utilization, plus whatever growth margin you want layered on top. This does two things at once. It gives the vendor's engineering team something concrete to size against instead of a product-line default config, and it creates a paper trail. If the delivered hardware underperforms relative to what got quoted, you've got a documented baseline to point to in the support call, rather than an argument over what "high-performance" was ever supposed to mean. Ask for the vendor's own benchmark data on the exact configuration you're being quoted, not marketing numbers for the CPU family or SSD generation in general. A CPU's published benchmarks assume a particular memory configuration, a particular count of populated DIMM channels, and often a thermal envelope your chassis may or may not hold under continuous load. The number on the spec sheet and the number your workload will see in production can diverge quite a bit, especially on dense multi-socket boxes where NUMA topology decides how memory bandwidth actually gets distributed across cores. ## Power, cooling, rack space: the parts nobody remembers until they don't fit Bare metal brings back constraints that cloud infrastructure hides completely, and they surface at the worst possible moment if nobody's checked them before the hardware ships. Power first. Confirm actual power draw under sustained peak load, not the idle number sitting on the spec sheet, against what your rack's PDU and the data center's circuit can actually deliver. Dense configs with multiple GPUs or a full complement of NVMe can pull enough current that a rack designed around older, lower-density gear hits its circuit limit before it ever runs out of rack units. If you're colocating, that conversation happens with the facility before delivery. Not after the box shows up and someone discovers the circuit was already provisioned to the edge. Cooling runs on the same logic, and it's easy to assume it's someone else's problem. A data center provisions cooling in aggregate across a room, but rack-level and row-level hot spots happen constantly when a few dense servers land in the same section and nobody's run the thermal math first. Ask the facility, your own or a colo provider, what the cooling capacity actually is at the specific rack location your server is going into. Not the building average. That number means nothing to the three servers sitting in row 12. Rack space sounds trivial until cable management and airflow clearance start eating into it. A 2U server needs the rack units the chassis occupies, sure, but also clearance for cable routing at the rear and unobstructed intake at the front. A rack that looks like it has room on paper turns out tight once the patch cables and power whips are actually run. ## Delivery is not the finish line The server hitting the loading dock is where acceptance testing starts, not where the process ends. Skip this step and a bad unit ships straight into production before anyone notices. Run a burn-in before it touches live traffic: memory testing with `memtest86+`, CPU stress with `stress-ng`, storage benchmarking with `fio` configured to mirror the actual I/O pattern you profiled earlier, not some generic default. This catches manufacturing defects and marginal components, a misseated DIMM, a drive reporting healthy SMART data while quietly underperforming its rated IOPS, before they turn into a 2 a.m. page. It's tedious, and it feels redundant given the vendor presumably tested the unit at the factory already. Do it anyway. Factory testing confirms the hardware functions. It says nothing about whether it performs to spec under your specific access pattern. Compare delivered performance against the RFQ's stated numbers before you sign off. If the vendor quoted a sustained IOPS figure or a memory bandwidth number, verify it yourself with a benchmark run. Discrepancies are far cheaper to fight over before the invoice clears and the box is racked into a dependency chain that fifteen other services now rely on. ## The discipline pays for itself None of this is complicated the way a distributed systems design problem is complicated. It's complicated the way a checklist under deadline pressure is complicated: every individual step is simple, and the whole thing still gets skipped because two weeks of measurement feels slower than just cutting the PO. That feeling is wrong, and it's costly in a way that only shows up later, usually in a postmortem nobody wants to write. A server sized off real telemetry costs less to over-provision and fails less often in ways that trace back to being undersized in the first place. It also hands you a documented baseline the second something needs escalating to a vendor. The RFQ turns into a technical document instead of a wish list, and the quote you get back reflects your actual workload instead of somebody's defensive guess. Measurement is what turns specifying hardware from a gamble into a discipline, and disciplines, unlike guesses, compound in your favor over time.