{"id":25004,"date":"2026-10-18T11:09:59","date_gmt":"2026-10-18T11:09:59","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=25004"},"modified":"2026-10-18T11:11:09","modified_gmt":"2026-10-18T11:11:09","slug":"bare-metal-server-specs","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/zh\/bare-metal-server-specs\/","title":{"rendered":"Bare Metal Server Specs: CPU, RAM, NVMe and NIC Sizing"},"content":{"rendered":"

Bare metal server specs should match your workload\u2019s 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.<\/span><\/p>\n

A specification such as \u201c32 cores, 128 GB RAM, NVMe, 10 Gb\/s\u201d 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\u2019s rated speed?<\/span><\/p>\n

We\u2019ll work through those questions and show how to turn measurements into a practical server specification.<\/span><\/p>\n\n\n\n\n\n\n\n\n
Component<\/b><\/th>\nMeasure first<\/b><\/th>\nAsk for<\/b><\/th>\nCommon buying error<\/b><\/th>\n<\/tr>\n<\/thead>\n
\u4e2d\u592e\u5904\u7406\u5668<\/span><\/td>\nPer-core load, processing time, concurrency<\/span><\/td>\nExact model, physical cores, threads, sockets<\/span><\/td>\nChoosing by core count alone<\/span><\/td>\n<\/tr>\n
\u5185\u5b58<\/span><\/td>\nActive memory, caches, peak process demand<\/span><\/td>\nCapacity, ECC support, DIMM layout<\/span><\/td>\nTreating all used memory as a shortage<\/span><\/td>\n<\/tr>\n
NVMe<\/span><\/td>\nData growth, I\/O latency, daily writes<\/span><\/td>\nDrive model, usable capacity, endurance<\/span><\/td>\nComparing only capacity and peak IOPS<\/span><\/td>\n<\/tr>\n
NIC<\/span><\/td>\nThroughput, packet rate, transfer volume<\/span><\/td>\nNIC model, port speed, network terms<\/span><\/td>\nTreating port speed as guaranteed internet throughput<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Start With Your Workload and Performance Target<\/span><\/h2>\n

Record normal load, peak load, and background jobs<\/span><\/h3>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

Set response-time, growth, and recovery targets<\/span><\/h3>\n

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.<\/span><\/p>\n

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?<\/span><\/p>\n

Keep three allowances separate: capacity for growth, spare capacity for bursts, and capacity needed during failures. Avoid adding the same reserve more than once.<\/span><\/p>\n

How Many CPU Cores Does a Bare Metal Server Need?<\/span><\/h2>\n

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.<\/span><\/p>\n

Compare physical cores, threads, and vCPU labels<\/span><\/h3>\n

A socket holds a processor. A processor contains physical cores. Some cores support multiple hardware threads through simultaneous multithreading, or SMT.<\/span><\/p>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

Match per-core performance and core count to the application<\/span><\/h3>\n

Clock speed alone cannot compare processors from different designs. Instructions completed per clock, cache behavior, memory access, and application code also affect performance.<\/span><\/p>\n\n\n\n\n\n\n\n\n
Workload pattern<\/b><\/th>\nCPU priority<\/b><\/th>\nTest that matters<\/b><\/th>\n<\/tr>\n<\/thead>\n
One busy game loop or application thread<\/span><\/td>\nPer-core performance<\/span><\/td>\nTick time or request latency<\/span><\/td>\n<\/tr>\n
Independent build jobs<\/span><\/td>\nParallel processing capacity<\/span><\/td>\nJobs completed within the required time<\/span><\/td>\n<\/tr>\n
Many application requests<\/span><\/td>\nPer-core performance and concurrency<\/span><\/td>\nThroughput at the response-time target<\/span><\/td>\n<\/tr>\n
Virtual machines<\/span><\/td>\nAggregate demand and contention<\/span><\/td>\nGuest performance during peak host load<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

Check NUMA, licensing, and socket count<\/span><\/h3>\n

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.<\/span><\/p>\n

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.<\/span><\/p>\n

If software is licensed per core, compare the full software and hardware cost. Confirm the applicable licensing terms before selecting a higher core count.<\/span><\/p>\n

How Much RAM Should You Specify?<\/span><\/h2>\n

Size RAM from the active workload, concurrent tasks, and host services. Total stored data alone does not determine memory demand.<\/span><\/p>\n

Calculate memory from active use<\/span><\/h3>\n

Account for application processes, database buffers, caches, connection handling, and the operating system. For virtualization, include guest demand and the hypervisor\u2019s own requirements.<\/span><\/p>\n

Do not assume a high \u201cused memory\u201d 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.<\/span><\/p>\n

Also check how your monitoring tool counts shared memory. Adding every process\u2019s reported memory can count shared pages more than once.<\/span><\/p>\n

Illustrative RAM calculation:<\/b><\/p>\n