Bare Metal Server Specs: CPU, RAM, NVMe and NIC Sizing

Bare metal server specs should match your workload’s peak demand, response-time target, and recovery needs. Choose CPU cores from processing demand, RAM from active memory use, NVMe drives from capacity and I/O needs, and network interface cards (NICs) from throughput and packet rate. Then test the complete server under realistic load.

A specification such as “32 cores, 128 GB RAM, NVMe, 10 Gb/s” leaves several questions unanswered. Which processor? How is the memory installed? How much disk space remains after mirroring? Does the network plan permit sustained traffic at the NIC’s rated speed?

We’ll work through those questions and show how to turn measurements into a practical server specification.

Component	Measure first	Ask for	Common buying error
Processor	Per-core load, processing time, concurrency	Exact model, physical cores, threads, sockets	Choosing by core count alone
RAM	Active memory, caches, peak process demand	Capacity, ECC support, DIMM layout	Treating all used memory as a shortage
NVMe	Data growth, I/O latency, daily writes	Drive model, usable capacity, endurance	Comparing only capacity and peak IOPS
NIC	Throughput, packet rate, transfer volume	NIC model, port speed, network terms	Treating port speed as guaranteed internet throughput

Start With Your Workload and Performance Target

Record normal load, peak load, and background jobs

Collect measurements across representative business cycles. Include busy periods, backups, imports, reports, and software releases. A quiet afternoon will not show what happens when a backup overlaps with peak traffic.

Separate concurrent users, open connections, and requests per second. Ten thousand mostly idle connections can create a different workload from a few hundred users running costly database queries.

For an existing application, measure each tier. For a new application, build a test that represents its expected data size and request mix. Record the assumptions so you can revise them after launch.

Set response-time, growth, and recovery targets

Define acceptable response time before choosing hardware. A p95 response time means 95% of measured requests finish at or below that duration. A p99 target covers 99% of requests and exposes more of the slow responses.

Then set a planning horizon and a recovery requirement. Will the server hold twelve months of data growth? Must a cluster carry the full workload while one node is offline?

Keep three allowances separate: capacity for growth, spare capacity for bursts, and capacity needed during failures. Avoid adding the same reserve more than once.

How Many CPU Cores Does a Bare Metal Server Need?

The required core count depends on how much work the application can process in parallel. A busy main thread may need better per-core performance. Many independent jobs may benefit from more cores.

Compare physical cores, threads, and vCPU labels

A socket holds a processor. A processor contains physical cores. Some cores support multiple hardware threads through simultaneous multithreading, or SMT.

For example, a processor with 16 physical cores and two threads per core exposes 32 logical processors. That does not give it the processing capacity of 32 physical cores.

If a provider lists vCPUs for a bare metal offer, ask how that label maps to physical cores and threads. Request the exact CPU model, generation, socket count, and enabled cores.

Match per-core performance and core count to the application

Clock speed alone cannot compare processors from different designs. Instructions completed per clock, cache behavior, memory access, and application code also affect performance.

Workload pattern	CPU priority	Test that matters
One busy game loop or application thread	Per-core performance	Tick time or request latency
Independent build jobs	Parallel processing capacity	Jobs completed within the required time
Many application requests	Per-core performance and concurrency	Throughput at the response-time target
Virtual machines	Aggregate demand and contention	Guest performance during peak host load

A useful early estimate is CPU time per task multiplied by tasks per second. If each task consumes 0.01 CPU-seconds and demand reaches 1,000 tasks per second, the workload consumes about ten CPU-seconds per second. It therefore needs roughly ten fully busy core equivalents on the measured system, before reserve capacity.

This estimate assumes the work can run in parallel. It is not a direct sizing conversion between different CPU models. Test the candidate processor and account for host services and background work.

Check NUMA, licensing, and socket count

Non-uniform memory access, or NUMA, means that memory access cost depends on where the processor and memory sit in the system. Access to local memory can differ from access across another NUMA node. Devices also connect through particular I/O paths.

Check topology when selecting a server for large databases, virtualization, or heavy network traffic. Two sockets can supply more total resources, but an application must use them effectively.

If software is licensed per core, compare the full software and hardware cost. Confirm the applicable licensing terms before selecting a higher core count.

How Much RAM Should You Specify?

Size RAM from the active workload, concurrent tasks, and host services. Total stored data alone does not determine memory demand.

Calculate memory from active use

Account for application processes, database buffers, caches, connection handling, and the operating system. For virtualization, include guest demand and the hypervisor’s own requirements.

Do not assume a high “used memory” figure means the server needs more RAM. Operating systems and databases use memory for caches. Check available memory, sustained swap activity, memory pressure, and application latency.

Also check how your monitoring tool counts shared memory. Adding every process’s reported memory can count shared pages more than once.

Illustrative RAM calculation:

• Application and database demand: 46 GiB.
• Separately accounted OS and supporting services: 10 GiB.
• Total demand: 56 GiB.
• Chosen unused-capacity allowance: 25%.

Required capacity = 56 ÷ 0.75 = 74.7 GiB.

Compare supported configurations above that requirement, then check the DIMM arrangement. The 25% allowance is an example, not a rule for every workload. Dividing by 0.75 leaves 25% of the final capacity unused; adding 25% to demand produces a different result.

Check ECC, memory channels, and DIMM layout

Error-correcting code (ECC) memory detects and corrects certain memory errors. Its operation depends on support across the processor, motherboard, and memory configuration.

Capacity and bandwidth are separate. Two servers with the same total RAM can have different memory performance because they populate different numbers of memory channels.

Ask for the number and size of DIMMs, their operating speed, and the populated channels. Follow the processor and server vendor’s supported layout. AMD publishes memory population guidance for its named processor platforms; use the guidance for the actual system being ordered.

Allow for supported upgrades

Check whether a future memory increase requires adding DIMMs or replacing existing ones. Confirm the supported maximum, maintenance window, and provider upgrade process.

A larger initial configuration can avoid a near-term migration, but unused RAM carries a cost. Base the purchase on a stated growth estimate.

How Do You Size NVMe Storage?

NVMe sizing has three separate parts: usable space, performance under your I/O pattern, and write endurance. A drive must meet all three.

Calculate usable capacity after RAID and growth

Add current data, projected growth, retained logs, temporary files, and snapshots. Then allow for filesystem overhead and required free space. Budget independent backups separately.

Drive labels commonly use decimal terabytes, or TB. Some operating-system tools report binary tebibytes, or TiB. One TB is about 0.91 TiB before other overhead. Keep units consistent throughout the calculation.

Drive layout	Capacity before formatting and other overhead
One 1.92 TB drive	1.92 TB
Two 1.92 TB drives in RAID 1	1.92 TB
Four 1.92 TB drives in RAID 10	3.84 TB

RAID 1 stores mirrored copies. RAID 10 combines mirrored pairs with striping. RAID 10’s ability to survive multiple failures depends on which drives fail.

RAID does not replace independent backups. It cannot protect against every deletion, software error, or server-level loss.

Consider this illustrative requirement:

Current data of 1.2 TB + expected growth of 0.6 TB + logs and temporary files of 0.2 TB = 2.0 TB.

To keep 20% free, the target becomes 2.0 ÷ 0.8 = 2.5 TB usable.

Two mirrored 1.92 TB drives fall short. Two mirrored 3.84 TB drives clear this capacity estimate, subject to overhead. Their performance and endurance still need checking.

Match IOPS, throughput, and latency to the workload

Input/output operations per second (IOPS) count storage operations. Throughput measures bytes transferred per second. Latency measures how long an operation takes.

A database that issues small random reads has different needs from a backup job writing large sequential blocks. Queue depth, the number of outstanding operations, also changes test results.

Compare drive results using the same block size, read/write mix, queue depth, and test conditions. A high peak IOPS figure does not establish low latency for your application.

For example, Micron’s 7600 technical specification lists different queue depths for its sequential and random performance tests. Read those conditions before comparing headline numbers.

Test sustained writes and performance during backups or array rebuilding. Also measure application response time, which includes more than storage delay.

Check write endurance and power-loss protection

Drive writes per day (DWPD) expresses daily writes relative to drive capacity over the rated period. Terabytes written (TBW) expresses a total write allowance. Both require the exact model’s rating and workload conditions.

Suppose each member of a two-drive mirror receives 2 TB of host writes per day. For a 3.84 TB drive:

Required DWPD = 2 ÷ 3.84 = about 0.52.

Each mirror member receives a copy of the writes. Do not divide the write volume between the two drives as though they were striped without mirroring. Include other writes that reach each drive, such as maintenance activity.

Compare host-write estimates with the vendor’s host-write rating. Internal NAND writes differ from host writes, so do not add an arbitrary internal-write multiplier to an already comparable rating.

Request documented power-loss protection and check drive health reporting. A calculated DWPD requirement does not predict an exact failure date.

Confirm PCIe links and drive compatibility

Check the drive’s PCIe generation and lane width against the server connection. Confirm the backplane, supported bays, firmware, and cooling.

M.2 and U.2 do not, by themselves, establish endurance or reliability. Compare exact drive models.

Device placement also matters. Dell’s NVMe and I/O topology guide shows how drive connections differ across named server configurations. Use the corresponding manual for your selected chassis.

Which NIC Speed and Network Plan Do You Need?

Choose the NIC from peak traffic, packet rate, recovery traffic, and network availability requirements. Then confirm that the provider’s service supports that demand.

Separate port speed, throughput, and traffic allowance

A 10 Gigabit Ethernet (10 GbE) interface has a nominal rate of 10 gigabits per second. Dividing by eight gives 1.25 gigabytes per second before overhead.

Actual application throughput depends on protocol overhead, CPU processing, storage, packet loss, and the path to the remote endpoint.

Check four different terms in the quote:

1. NIC speed: the hardware interface’s capability.
2. Configured port rate: the link or rate limit applied to the service.
3. Committed bandwidth: the capacity covered by the provider’s stated terms.
4. Transfer allowance: the permitted data volume over the billing period.

Monthly volume can matter even when peak speed fits. An average outbound rate of 100 Mb/s sustained for 30 days transfers about 32.4 TB in decimal units. Billing treatment and included traffic still depend on the service terms.

Calculate application, replication, and backup traffic

For direct video delivery, multiply concurrent viewers by delivered bitrate.

Illustrative example: 800 viewers × 6 Mb/s = 4.8 Gb/s of payload.

With a chosen 80% utilization target, 4.8 ÷ 0.8 = 6 Gb/s, before any protocol overhead not included in the bitrate. A 10 GbE connection is a candidate, provided testing and the traffic plan support it.

If a content delivery network serves the viewers, size the origin from actual origin traffic. Do not apply the full viewer total directly to the origin server.

For APIs, start with requests per second × average response bytes × 8. Add request traffic and protocol overhead where needed. Calculate database replication and backups separately, then check whether they share a network limit.

A restore window creates another requirement. Moving 2 TB in one hour needs about 4.44 Gb/s of payload throughput, before overhead. Source storage, destination writes, and recovery processing can lengthen the actual restore.

Compare 1, 10, 25, and 100 GbE

NIC class	When to consider it	What must also fit
1 GbE	Measured demand and recovery transfers fit within the available capacity	Provider rate limits and burst demand
10 GbE	Application traffic or data movement exceeds practical 1 GbE capacity	CPU, storage, switch, and network service
25 GbE	Higher aggregate traffic or shorter transfer windows require more capacity	PCIe connection, optics, queues, and peer links
100 GbE	Measured storage or compute-cluster traffic requires this class of link	The full host and network path

These are decision categories, not guaranteed workload limits. A user count alone cannot establish the correct NIC speed.

Check packet rate, queues, and failover

Small packets require more packet-processing work per gigabit than large packets. VPNs, proxies, and games can therefore reach CPU or queue limits before filling the link.

Receive-side scaling (RSS) helps distribute received traffic across hardware queues. Check NIC and driver support. The Linux networking documentation explains how queue and CPU placement affect packet processing.

Two bonded 10 GbE ports do not automatically give one connection 20 Gb/s. Ordinary LACP arrangements distribute flows across member links; an individual flow generally remains on one member. Check the bonding mode and switch behavior against the Linux bonding documentation.

For availability, also check switch and path redundancy. Two ports connected to one switch still share that switch as a failure point. Size the surviving path for the required workload.

Special features such as SR-IOV for virtualization or RDMA for supported data-transfer workloads require matching software and platform support. Include them only when the application needs them.

Match the Specification to Your Workload

Use the application’s behavior to set priorities. Generic packages cannot establish how many users or virtual machines a server will support.

Workload	Sizing priority	Evidence to collect
Databases	Active data, concurrent queries, commit latency, daily writes	Query response time, memory pressure, storage latency
Virtualization and containers	Guest demand, host services, contention, failover	Peak guest and host metrics, reduced-capacity tests
Games	Main-loop performance, instance count, memory, packet rate	Tick time, per-core load, packet loss
Streaming and media	Delivery bitrate, storage reads, transcoding	Active streams, codec settings, encoder throughput
Web applications and APIs	Request cost, caching, response size	Requests per second, p95/p99 latency, errors
VPNs and proxies	Encryption, connection handling, packet processing	Throughput at actual packet sizes and cipher settings

For media workloads, separate passthrough delivery from transcoding. Re-encoding video changes the processing requirement and may call for GPU acceleration.

AI workloads may also need separate GPU memory and accelerator-interconnect sizing. A CPU, RAM, NVMe, and NIC checklist alone cannot establish whether a model will fit or meet its response-time target.

Test the Complete Server Before Production

Confirm the delivered hardware

Compare the running system with the quote. On Linux, these read-only tools can help:

Tool	What to inspect
lscpu	Processor model, sockets, cores, threads, NUMA layout
free -h	Memory totals and current availability
lsblk	Block devices, sizes, and mount layout
lspci	PCIe devices, including storage and network controllers
ethtool	Selected interface’s reported link and driver details
nvme-cli of smartctl	Supported drive identity and health information

Commands, options, package availability, and required privileges vary. Redact serial numbers and addresses before sharing output publicly.

Test realistic load and recovery conditions

Run representative application traffic with the expected data size. Record throughput, latency, errors, memory pressure, and storage behavior during the same test.

Use fio to examine storage behavior and iperf3 to examine a network path. Neither tool proves that the complete application meets its target.

Run write benchmarks and failure tests with disposable data in an isolated environment. Record hardware, firmware, OS, application versions, test settings, warm-up, duration, and repeat results.

If recovery matters to the service target, test it. Measure a restore and confirm that the remaining nodes or links can handle the workload during maintenance or failure.

Find the resource that needs to change

Observed problem	Check before buying hardware
One core stays busy while others are idle	Main-thread limits, locks, and per-core performance
Memory pressure and sustained swapping	Active demand, leaks, caches, and concurrent tasks
Storage latency rises under load	Queue depth, write mix, drive health, and rebuilding
Network throughput falls below expectations	Rate limits, loss, CPU load, peer limits, and routes
Packet drops increase	NIC queues, counters, interrupt load, and switch behavior
Recovery takes too long	Source reads, network transfer, destination writes, and recovery processing

Change the resource that limits the result. Extra RAM will not resolve a saturated application thread, and a faster NIC will not fix slow source storage.

Check These Details Before You Order

Ask for a written specification that includes:

• Exact CPU model, socket count, physical cores, and threads.
• RAM capacity, ECC support, DIMM count, and channel layout.
• Drive model, count, endurance, and power-loss protection.
• RAID method and usable storage after the chosen layout.
• NIC model, port speed, and public/private network limits.
• Traffic allowance, overage charges, and bandwidth terms.
• Remote console access and hardware replacement process.
• Upgrade options, lead times, and maintenance requirements.

Hardware redundancy is only part of application availability. Confirm how the application behaves during disk, server, switch, and network failures.

Veel gestelde vragen

How do I choose bare metal server specs?

Measure processing demand, active memory, storage activity, and network traffic during busy periods. Set response-time and recovery targets. Select hardware that meets those requirements with a stated allowance for growth, then test the complete application on the proposed configuration.

Do I need more CPU cores or higher per-core performance?

Choose from the application’s execution pattern. More cores help when work can run in parallel. Better per-core performance helps when one busy thread limits progress. Check per-core usage and application latency instead of relying only on total CPU utilization.

Is 64 GB of RAM enough for a bare metal server?

It depends on active memory demand, concurrent tasks, caches, and host services. Compare measured peak demand with available memory and the chosen reserve. A server running several virtual machines or a large active database can need substantially more memory than a small application server.

Does every bare metal server need NVMe storage?

No. NVMe can suit demanding I/O workloads, while SATA SSDs may meet less demanding requirements. HDDs can fit capacity-focused archives and backups. Choose from measured latency, throughput, capacity, endurance, and recovery needs rather than the storage label alone.

How much usable storage do two mirrored NVMe drives provide?

Two equal-capacity drives in a mirror provide approximately one drive’s capacity before formatting and other overhead. Two 3.84 TB drives therefore provide about 3.84 TB at the array level. Filesystem overhead, reserved space, and operational free space reduce the amount available for application data.

Is a 10 GbE NIC the same as 10 Gb/s internet bandwidth?

No. The NIC describes the local interface capability. Internet throughput also depends on the configured service, provider limits, routes, remote endpoint, and host performance. Confirm committed bandwidth, traffic allowance, and public versus private network rates in the quote.

Will two 10 GbE ports make one connection run at 20 Gb/s?

Ordinary LACP bonding generally keeps each flow on one member link. Multiple flows may use both links, depending on distribution and demand. One connection does not automatically receive their combined rate. Confirm the supported bonding design and test your actual traffic pattern.

Can I upgrade RAM, drives, or the NIC later?

Often, but the chassis, motherboard, available slots, and provider process set the limits. Some changes require replacement parts, downtime, or migration to another server. Ask which upgrades are supported and how long they take before placing the order.

Turn Your Measurements Into a Server Specification

A useful specification connects each component to a requirement: CPU to processing demand, RAM to active memory, drives to capacity and I/O behavior, and NICs to network demand. It also states what must happen during growth, maintenance, and recovery.

When you compare Atal Networks bare metal server options, share your workload, peak measurements, storage growth, and network requirements. Ask for the exact hardware, usable capacity, traffic terms, and upgrade path for your chosen location

Then use the same measurements as acceptance checks. That gives you a clear basis for deciding whether the selected server fits the job.