Single-Socket Server Based on the AMD EPYC 9005: Why One Processor Is Better Than Two
Why Single-Socket Servers Have Become Relevant
As long as processors offered 16 or 24 cores, foregoing a second socket meant sacrificing half the computing power per node. This also affected the network: the same capacity was achieved using twice as many nodes, each of which took up a couple of access ports, while the 10- or 25-Gbps interface was under a load of only a few gigabits.
The issue was resolved by increasing core density. A single EPYC 9005 socket contains up to 192 cores and 12 DDR5 channels, with one module per channel—that’s more than a dual-socket configuration from two generations ago could provide. In the 2026 generation, Cloudflare’s 12 DDR5-6400 modules, each with 64 GB, deliver 614 GB/s per socket, a 33.3% increase over the previous generation, with the requirement that all channels have the same capacity and rank.
Cost of Operating the Server Fleet
Let’s do some simple calculations. A manual operation lasting twenty minutes once a week on each of the two hundred nodes amounts to 66 hours per week. That’s more than one and a half engineer-hours per procedure. The break-even point for automation isn’t reached at 100,000 servers, but rather when the operation begins to repeat every week. This is the view shared by both corporate data centers and service providers like ITGLOBAL.COM, which operates its own server farm and sells it as a service.
Troubleshooting takes up an engineer’s time. A server failure—which starts from scratch every time—turns into a complex process of sifting through details, and the engineer has to spend a lot of time searching for causes instead of working on application fault tolerance.
How a Single Socket Improves Things
NUMA (Non-Uniform Memory Access) means that each processor has its own local memory, and the path to a neighboring processor’s memory goes through the inter-socket interconnect and returns via the same route.
Memory. A faulty slot is identified by the controller in any server. The difference lies in what happens next: in a dual-socket node, a floating error branches out—to a module, a specific processor’s controller, or the load path between domains. With a single socket, all channels share a single host, and the layout of one module per channel makes the “channel equals module” mapping unambiguous.
PCIe lanes. The card delivers its advertised speed when it is processed by cores in the same domain. Hence the set of rules: the slot is selected based on the processor; the card’s queues and application threads are bound to the cores of its domain; the operating system’s load balancer is restricted; and after any card rearrangement, the binding is rechecked. In a single-socket server, the issue disappears along with the hardware itself. For DPI, anti-DDoS, and any workloads where packets are processed at line speed, this is the difference between predictable processing times and hunting for the source of latency.
Maintaining a Single-Socket Server in a Data Center: A Quick Guide for Engineers
The length of the engineer’s guide is as much a characteristic of the platform as the number of components. One processor, one heatsink, one air duct, identical memory modules: fewer steps, fewer opportunities to mix up positions and accidentally damage a neighboring component. The warehouse maintains a short list of spare parts and a single replacement procedure for the entire fleet.
Drives, fans, and power supplies with a 1+1 redundancy configuration can be hot-swapped without a maintenance window. Downtime is still required for memory and the processor, but it’s predictable: since the components are identical, a known portion of the fleet’s capacity goes down, rather than that single server on which half the services rely.
Server Fleet Monitoring: One Socket as a Unit of Comparison
One socket equals one server, so all node metrics describe a single computing domain, and the graph for one node can be interpreted alongside any other without qualification.
A hundred identical nodes define their own normal range, and anomalies fall outside that range without the need for new thresholds or rules. The range is then broken down by load profiles: the hypervisor, relational database, and Kubernetes nodes provide their own metrics—how many virtual machines a node hosts at a given oversubscription rate, how many transactions until memory is exhausted, and how many pods until network capacity is exhausted. After that, the infrastructure is planned based on these figures: for the next project, the same number of nodes of the same type is allocated.
Single-socket platforms in distributed DDoS protection services
Traffic filtering represents an extreme use case: points of presence around the world, no permanent staff on-site, and packets must be processed within a predictable timeframe. Let’s examine this issue using the example of successful practices by global giants.
Cloudflare, a major cloud provider, operates in over 330 cities. In 2020, they changed their approach: 48 cores on a single AMD EPYC 7642 instead of 48 cores across two Intel Xeon Platinum 6162 processors, with a 25% lower TDP per core and a base frequency of 2.4 GHz versus 1.9 GHz. Compared to a dual-socket setup, lab tests showed up to 36% more requests, L3 cache misses reduced by approximately 50%, up to twice the Requests per Watt performance, and p99 latency in NGINX reduced by up to 50%—this refers to the time it takes to process a request on the server. In production, the platform delivered a 23% increase in requests per percent of CPU utilization and a 28% increase in requests per watt. They have maintained this architecture for six consecutive generations.
StormWall, eight points of presence, and over 8,000 Gbps of filtering capacity. The network covers Miami, Los Angeles, Frankfurt, Hong Kong, Singapore, Dubai, Sofia, and Jakarta; Brazil, India, and Kazakhstan will be added in 2026. The team develops its own filtering software suite, and an instance of it runs on a single-socket AMD platform: one filtering server per point of presence, a single memory domain for state tables, and fully remote maintenance.
Both services utilize processor performance without incurring overhead from NUMA operations and manage the infrastructure identically: a node is taken offline, diagnosed remotely, and repaired by replacing a component.
Template-based server deployment and diagnostics: Redfish, IPMI, PXE, and UEFI
| Interface | What it covers | Role in the template |
|---|---|---|
| Redfish | Inventory, telemetry, node configuration, and events via HTTP in JSON; role-based model | The node is configured via code, not manually in the web interface |
| IPMI | power, console, compatibility with legacy tools | Single-command operations from a script |
| PXE | network boot image | the point where deployment becomes templated |
| UEFI with Secure Boot | Verification that the correct image is loaded, firmware version check | trusted base for the template |
A node intended for a hypervisor receives its BIOS settings, partitioning, and image; a node intended for a relational database receives different power-saving settings and a different image. The operator selects a template; then Ansible, running on top of Redfish, configures the parameters; PXE delivers the image; inventory and serial numbers are sent to the ITAM system in the same run; and telemetry is captured by monitoring. There are as many templates as there are roles, not as many as there are nodes.
The diagnostic loop is built from standard interfaces: the management channel provides access to the operating system, PXE delivers the test image, and the results are sent to a ticket in a machine-readable format.
The same interfaces close the diagnostic loop, and a simple node makes the loop more cost-effective: the diagnostic image does not need to distinguish which half of the server is at fault.
Node Failure: What the On-Duty Technician Sees and What They Do
| What failed | How it appears from the outside | What the on-duty technician does |
|---|---|---|
| Storage device | The drive is no longer detected in the bay; errors are increasing or a predictive indicator is triggered | Checks the serial number, illuminates the bay, performs a hot swap, verifies that the volume has returned to normal |
| Fan | RPMs outside the threshold, event logged | replaces the module without shutting down the system, verifies that temperatures have returned to normal |
| Power Supply | Logged event; the unit is operating on a paired power supply with 1+1 redundancy | Switches to the hot standby unit, verifies that redundancy has been restored |
| Memory module | Correctable errors are accumulating on a single channel, or an uncorrectable error has occurred | Schedules a maintenance window for correctable errors; takes the node offline immediately for an uncorrectable error; replaces one module and checks the counter after a test run |
| Network card | Link, error and drop counters on the port | Checks the transceiver and cable; replaces the card during the maintenance window; does not rebuild flow associations |
| Overheating and throttling | Temperatures near the threshold; frequency below nominal under normal load | Checks the air duct, filters, and inlet temperature; compares with neighboring servers in the rack |
| Processor | Memory, power supply, and storage devices have been ruled out; the failure repeats on the diagnostic image | Removes the module, installs a processor from spare parts, and restores the load after a clean boot |
| The unit fails POST | No response from the operating system; error code or event in the controller log | Dump the log, restart with the diagnostic image, and escalate with evidence |
The first three lines describe a chassis feature: hot-swap capability is also available on dual-socket platforms, and it is tested separately. The difference becomes apparent below. Whereas a dual-socket server requires determining which half is at fault and which lines serve the card, this issue does not arise with a single-socket server.
The procedure is the same for any line. Document the evidence: the controller log, serial number and part number, and the time of the event. Replace the component. Verify via telemetry that the metric has returned to baseline. Update the record in the ITAM system; for Russian projects, this is SimpleOne ITAM. Restore the workload. Skipping this last step is the most common reason why, six months later, no one knows what kind of drive is in the bay.
When 192 cores per socket aren’t enough: two and four sockets
The dividing line is based on the indivisible workload. As long as a monolithic application fits within 192 cores, 12 memory channels, and 3 TB with 256 GB modules, a second socket will only complicate matters rather than boost performance.
As soon as the monolithic application requires more cores or more memory within a single operating system instance, the discussion shifts to two sockets; for very large workloads, it moves directly to four-socket platforms based on Intel Xeon. To give you an idea of the scale: The Dell PowerEdge R860 contains four fourth-generation Intel Xeon SP processors, each with 60 cores, 64 memory slots, and up to 16 TB per node. Such a server addresses an entirely different class of tasks—large relational databases, in-memory analytics, and the consolidation of workloads that cannot be distributed across nodes. No single-socket platform can replace this, and the opposite claim would be false.
