How to Optimize a 10Gbps Dedicated Server for Better Network Performance

Introduction

A 10Gbps dedicated server provides significantly more network capacity than a standard 1Gbps server, but having a 10Gbps network port does not automatically guarantee 10Gbps of real-world application throughput.

At 10Gbps, network performance depends on several components working together, including the network interface card (NIC), PCIe bus, CPU, Linux networking stack, TCP configuration, interrupt distribution, NIC queues, network path, and the remote endpoint.

This guide explains how to optimize and validate a Linux dedicated server with a 10Gbps network connection. You will learn how to:

  • Verify your NIC and physical link
  • Check NIC offloading features
  • Configure and evaluate MTU settings
  • Tune Linux TCP settings when appropriate
  • Configure RSS and inspect IRQ distribution
  • Monitor packet drops and NIC errors
  • Benchmark network throughput with iperf3
  • Identify CPU and network bottlenecks
  • Troubleshoot speeds below the expected 10Gbps range
⚠️
Important: Replace <interface> in the commands below with your actual network interface name, such as eth0, ens18, eno1, or another name assigned by your operating system.

Step 1: Verify Your Hardware and Network Link

Before modifying Linux networking settings, establish what hardware and connectivity you actually have.

1. Check CPU and Memory

2
Bash lscpu free -h

Look at:

  • CPU model
  • Number of CPU cores
  • Number of threads
  • NUMA topology
  • Available RAM

A modern multi-core CPU can generally provide enough processing capacity for many 10GbE workloads, but the exact requirement depends heavily on packet size, encryption, routing, virtualization, and the application generating the traffic.

Do not assume that a specific CPU core count guarantees 10Gbps performance.

2. Identify the Network Interface

3
Bash ip -br link

Example output:.

4
PlanText lo UNKNOWN 127.0.0.1/8 eno1 UP 192.0.2.10/24

In this example, the physical network interface is eno1.

You can also inspect the PCI devices:.

5
Bash lspci -nn | grep -i ethernet

For more information about the NIC:.

6
Bash lspci -nnk | grep -A3 -i ethernet

This can show the NIC model and the Linux driver currently being used.

3. Check the Negotiated Link Speed

Use ethtool:

7
Bash sudo ethtool <interface>

Look for:

8
PlanText Speed: 10000Mb/s Duplex: Full

A correctly negotiated 10GbE link should report approximately:

9
PlanText Speed: 10000Mb/s Duplex: Full

If the server reports 1000Mb/s, you do not currently have a 10Gbps negotiated link, regardless of what your hosting plan or network port is advertised as supporting.

Common reasons for a 1Gbps link include:

  • Incorrect switch configuration
  • Unsupported cable or transceiver
  • Incorrect SFP+/SFP28 module
  • Port configured for the wrong speed
  • Faulty cable
  • NIC configuration
  • Provider-side configuration

Resolve the physical/link issue before performing Linux TCP tuning.

Step 2: Install the Network Diagnostic Tools

On Ubuntu or Debian:

10
Bash sudo apt update sudo apt install ethtool iproute2 iperf3 sysstat

These packages provide several useful utilities:

Tool Purpose
ip Interface and routing configuration
ethtool NIC configuration and statistics
iperf3 Network throughput testing
mpstat Per-CPU utilization
ss Socket and TCP statistics

Step 3: Check NIC Capabilities and Offloading

Modern network cards can perform some packet-processing operations in hardware or through optimized kernel/NIC paths.

Check the available offloading features:

11
Bash sudo ethtool -k <interface>

You may see features such as:

  • TCP Segmentation Offload (TSO)
  • Generic Segmentation Offload (GSO)
  • Generic Receive Offload (GRO)
  • RX checksum offload
  • TX checksum offload

For example:

12
Plantext tcp-segmentation-offload: on generic-segmentation-offload: on generic-receive-offload: on

Should You Disable Offloading?

Usually, no.

For general-purpose 10Gbps server workloads, offloading features can reduce CPU overhead and improve throughput.

Do not apply generic advice such as:

13
Bash sudo ethtool -K <interface> tso off gro off gso off

unless you have a specific reason to test those settings.

Offloading changes can affect CPU utilization and throughput, and the optimal configuration depends on the NIC, driver, kernel, workload, and application.

Check Before Changing

Record your current settings:

14
Bash sudo ethtool -k > ~/ethtool-offload-before.txt

This gives you a reference point if you later perform controlled testing.

Step 4: Configure and Test MTU

MTU stands for Maximum Transmission Unit and defines the maximum IP packet payload that can normally be transmitted without fragmentation at the IP layer.

The most common Ethernet MTU is:

1500

Some private networks support jumbo frames, commonly:

9000

MTU 1500 vs MTU 9000

MTU 1500

Advantages:

  • Broad compatibility
  • Standard choice for Internet-facing traffic
  • Works across most public network paths

MTU 9000

Potential Advantages:

  • Fewer packets for large transfers
  • Lower packet-processing overhead in some workloads
  • Useful for controlled private networks
  • Common in storage and backend networks

However, jumbo frames require compatible configuration throughout the relevant path.

That means the NIC, switch, router, destination system, and other Layer 2/Layer 3 components involved in the path must support the required MTU.

For a public Internet-facing dedicated server, MTU 1500 is generally the safer default unless your provider explicitly supports a larger MTU end-to-end.

Test a Jumbo-Frame Path

For IPv4, an ICMP payload of 8972 bytes plus the 20-byte IPv4 header and 8-byte ICMP header corresponds to a 9000-byte IP packet.

You can test with:

15
Bash ping -M do -s 8972 <destination_ip>

If the destination and path support the requested packet size without fragmentation, the test should succeed.

This test should be performed against a destination where jumbo frames are actually expected to work, such as a server on the same private network or a provider-supported network path.

A successful test to one destination does not mean that every Internet destination supports MTU 9000.

Temporarily Change the MTU

To test MTU 9000:

16
Bash sudo ip link set dev <interface> mtu 9000

Verify:

17
Bash ip link show <interface>

You should see:

18
Plantext mtu 9000

If connectivity breaks, restore the previous value:

19
Plantext sudo ip link set dev <interface> mtu 1500

Make MTU Configuration Persistent

The exact configuration depends on how your Linux distribution manages networking.

For Ubuntu systems using Netplan, a configuration can look similar to:

20
Plantext network: version: 2 ethernets: eno1: mtu: 9000

Apply the configuration:

21
Bash sudo netplan apply
⚠️
Important: Do not copy this blindly into production. Preserve your existing IP address, routes, gateway, DNS, and other Netplan configuration.

For Internet-facing production servers, keep MTU 1500 unless you have verified that a larger MTU is supported throughout the required path.

Step 5: Linux TCP Performance Tuning

TCP performance is influenced by several variables, including:.

  • Round-trip time
  • Packet loss
  • Congestion control
  • TCP receive/send buffers
  • CPU performance
  • NIC behavior
  • Network path characteristics

There is no single TCP configuration that is optimal for every 10Gbps dedicated server..

The correct approach is to establish a baseline, make one controlled change, and test again.

1. Check the Current Congestion Control Algorithm

Run:

22
Bash sysctl net.ipv4.tcp_congestion_control

Check the algorithms available on your kernel:

23
Bash sysctl net.ipv4.tcp_available_congestion_control

Common options include:

  • CUBIC
  • BBR

CUBIC

CUBIC is widely deployed and is the default congestion-control algorithm on many Linux distributions.

It is a strong general-purpose choice.

BBR

BBR uses measurements of bandwidth and round-trip time to control sending behavior rather than relying solely on traditional loss-based congestion control.

It can be useful on some high-latency or loss-sensitive Internet paths, but enabling BBR does not automatically increase the throughput of every 10Gbps server.

The best algorithm depends on the characteristics of the network path and workload.

Step 6: TCP Buffer Configuration

TCP socket buffers can affect high-bandwidth, high-latency connections.

First inspect the current values:

24
Bash sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem

You can also inspect the core socket limits:

25
Bash sysctl net.core.rmem_max sysctl net.core.wmem_max

A server with a very high bandwidth-delay product may require larger buffers than a low-latency connection.

For example, a 10Gbps connection with very low latency behaves very differently from a 10Gbps connection across a high-latency geographic path.

Do Not Blindly Set Huge Buffers

Avoid treating values such as 16MB or 64MB as universal requirements.

Linux TCP autotuning can dynamically adjust socket buffers within the configured limits.

If testing demonstrates that buffer limits are constraining throughput, you can create a dedicated configuration file.

26
Bash sudo nano /etc/sysctl.d/99-10gbps-network.conf sysctl net.core.wmem_max

A conservative starting point could be:

27
Plantext net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216

Apply:

27
Bash sudo sysctl --system

Then verify:

28
Bash sysctl net.core.rmem_max sysctl net.core.wmem_max sysctl net.ipv4.tcp_rmem sysctl net.ipv4.tcp_wmem

Treat these values as a test baseline, not a guarantee that they are optimal for every system.

Step 7: RSS, NIC Queues and IRQ Distribution

At 10Gbps, packet processing can place significant load on the CPU.

Modern NICs use multiple receive and transmit queues to distribute network processing across CPU cores.

This is where Receive-Side Scaling (RSS) becomes important.

The Linux networking scaling documentation describes how multi-queue NICs can distribute traffic across multiple hardware queues and CPUs.

1. Inspect NIC Queue Configuration

29
Bash sudo ethtool -l <interface>

This shows the maximum and currently configured channel counts supported by the NIC.

Depending on the hardware, you may see:

30
Plantext Pre-set maximums: RX: ... TX: ... Combined: 8 Current hardware settings: RX: ... TX: ... Combined: 8

2. Configure the Number of Combined Queues

If the NIC supports multiple combined queues, you can change the configuration.

For example:

31
Bash sudo ethtool -L <interface> combined 8

Then verify:

32
Bash sudo ethtool -l <interface>

Do not assume that the maximum number of queues is always the best setting.

The optimal value depends on:

  • CPU topology
  • NIC model
  • Traffic pattern
  • NUMA topology
  • Number of network interfaces
  • Workload
  • Interrupt processing overhead

A controlled benchmark is better than blindly selecting the maximum.

Step 8: Inspect IRQ Distribution

Check NIC-related interrupts:

33
Bash grep -i <interface> /proc/interrupts

You can also inspect the complete interrupt table:

34
Bash cat /proc/interrupts

If network interrupts are concentrated on one CPU while other CPUs remain mostly idle, CPU distribution may be limiting network performance.

Check irqbalance

On many general-purpose Linux servers, irqbalance can help distribute hardware interrupts.

Check its status:

35
Bash systemctl status irqbalance

If installed and enabled:

36
Bash systemctl is-enabled irqbalance

For general-purpose workloads, automatic balancing is often preferable to manually pinning interrupts.

Advanced environments may benefit from manually controlling IRQ affinity, particularly on systems with multiple NUMA nodes or dedicated performance requirements.

However, manual IRQ tuning should be based on measurements rather than applied as a generic optimization.

Step 9: Check NIC Ring Buffers and Interrupt Coalescing

Some NICs expose additional performance parameters through ethtool.

1. Inspect Ring-Buffer Settings

Bash sudo ethtool -g <interface>

You may see maximum and current RX/TX ring sizes. Larger ring buffers can sometimes help absorb traffic bursts, but increasing them is not automatically beneficial.

2. Inspect Interrupt Coalescing

Bash sudo ethtool -c <interface>

Interrupt coalescing controls how the NIC groups packets before generating interrupts. This creates a trade-off:

  • More interrupts: Can reduce latency but increase CPU overhead.
  • More coalescing: Can reduce CPU overhead but may increase latency.

Because the correct settings depend on workload and NIC hardware, test changes individually.

Step 10: Verify Network Health Before Benchmarking

Before running a throughput benchmark, make sure the NIC is not already reporting errors or drops.

1. Check Interface Statistics

Bash ip -s link show <interface>

Pay attention to:

  • RX errors
  • TX errors
  • RX dropped packets
  • TX dropped packets
  • Overruns

2. Check Hardware NIC Statistics

Bash sudo ethtool -S <interface>

NIC vendors expose different statistics, so the exact field names vary. You can search for common error or drop counters:

Bash sudo ethtool -S <interface> | grep -Ei 'drop|error|miss|overrun'

A few counters may increase normally depending on the NIC and driver, so do not assume that every non-zero value represents a problem. The important thing is to observe whether relevant error or drop counters are increasing during the test.

3. Check Socket Statistics

Bash ss -s

This provides a quick overview of TCP and other socket states.

Step 11: Benchmark 10Gbps Throughput with iperf3

A web-based speed test is not the best tool for validating the raw capacity of a dedicated server's 10GbE connection.

Public speed tests can be affected by:

  • Test-server capacity
  • Geographic distance
  • Routing
  • Peering
  • Internet congestion
  • Browser or application overhead
  • TCP behavior

For controlled testing, use iperf3 between two suitable servers.

Ideally, the second server should have:

  • A 10Gbps or faster network connection
  • Sufficient CPU capacity
  • Low packet loss
  • A network path capable of supporting the desired throughput

1. Start the iperf3 Server

On Server A:

Bash iperf3 -s

By default, the server listens on TCP port 5201. Make sure your firewall permits that port between the two test systems.

2. Run a Baseline Test

From Server B:

Bash iperf3 -c <SERVER_A_IP>

This gives you a baseline using a single TCP stream. Do not immediately conclude that the server is underperforming if the result is below 10Gbps. A single TCP flow can be affected by RTT, packet loss, TCP behavior, CPU processing, and other factors.

3. Test Multiple TCP Streams

Run:

Bash iperf3 -c <SERVER_A_IP> -P 8

The -P 8 option creates eight parallel streams. Multiple streams can help determine whether a single TCP flow is limiting throughput.

If a single stream reaches 3Gbps but eight streams reach 9Gbps+, the network interface itself may not be the bottleneck. The result suggests that TCP flow characteristics or per-flow processing are affecting the single-stream result.

4. Test the Reverse Direction

Run:

Bash iperf3 -c <SERVER_A_IP> -R -P 8

The -R option reverses the direction of the test. Testing both directions is important because network paths can be asymmetric.

For example:

PlanText Server A → Server B: 9.5 Gbps Server B → Server A: 7.8 Gbps

A difference like this requires further investigation rather than assuming the NIC is faulty.

5. Run a Sustained Test

Use a longer test to identify performance changes over time:

Bash iperf3 -c <SERVER_A_IP> -P 8 -t 30

For deeper testing, you can use:

Bash iperf3 -c <SERVER_A_IP> -P 8 -t 60

A sustained test can reveal:

  • CPU saturation
  • Packet drops
  • Thermal effects
  • Network instability
  • Performance degradation over time

Step 12: Monitor CPU During the Benchmark

While iperf3 is running, open another terminal.

Run:

Bash mpstat -P ALL 1

This displays CPU utilization per logical CPU.

Look for situations such as:

PlanText CPU0 100% CPU1 10% CPU2 8% CPU3 7%

If one CPU is heavily saturated while the others remain relatively idle, investigate:

  • RSS queue configuration
  • IRQ distribution
  • NIC driver behavior
  • CPU affinity
  • Single-flow limitations

Also monitor general system load:

Bash top

And network statistics:

Bash sar -n DEV 1

This lets you correlate throughput with CPU and interface activity.

Step 13: Understanding Your iperf3 Results

A 10Gbps Ethernet link will not necessarily report exactly 10.000Gbps of TCP application throughput.

There is protocol overhead and additional processing between the physical Ethernet link and the application.

A result such as:

PlanText 9.2 Gbps

may be perfectly reasonable depending on the test environment.

Likewise, a result such as:

PlanText 6.0 Gbps

does not automatically mean that the server is incorrectly configured.

Always investigate:

  • Is the link negotiated at 10Gbps?
  • Is the remote server capable of the required throughput?
  • Is there packet loss?
  • What is the RTT?
  • Is CPU utilization high?
  • Are IRQs distributed appropriately?
  • Does increasing parallel streams improve throughput?
  • Is the network path itself capable of 10Gbps?

Step 14: Troubleshooting Common 10Gbps Performance Problems

Problem 1: The Server Only Shows 1Gbps

Check:

Bash sudo ethtool <interface>

If you see:

PlanText Speed: 1000Mb/s

investigate:

  • Switch port configuration
  • Cable
  • Transceiver
  • NIC capabilities
  • Provider configuration
  • Physical connectivity

This is a link-negotiation problem, not a TCP-tuning problem.

Problem 2: Single TCP Stream Is Slow

For example:

PlanText Single stream: 2.5 Gbps 8 streams: 9.4 Gbps

This indicates that the NIC and path may be capable of substantially higher aggregate throughput than a single TCP flow achieves.

Investigate:

  • RTT
  • Packet loss
  • TCP congestion control
  • TCP buffer limits
  • CPU processing
  • Per-flow limitations

Do not automatically increase every TCP sysctl value.

Problem 3: One CPU Core Reaches 100%

Check:

Bash mpstat -P ALL 1

Then inspect NIC queues:

Bash sudo ethtool -l <interface>

And interrupts:

Bash grep -i <interface> /proc/interrupts

If network processing is concentrated on a single CPU, investigate RSS and IRQ distribution.

Problem 4: RX Drops Increase During Testing

Check:

Bash ip -s link show <interface>

Then:

Bash sudo ethtool -S <interface>

Investigate:

  • NIC queue configuration
  • CPU saturation
  • Ring-buffer capacity
  • Driver issues
  • IRQ distribution
  • Packet-processing workload

If drops increase only under high packet-per-second workloads, the limiting factor may be packet processing rather than raw bandwidth.

Problem 5: Upload Is Faster Than Download

Run tests in both directions:

Bash iperf3 -c <SERVER_A_IP> -P 8

and:

Bash iperf3 -c <SERVER_A_IP> -R -P 8

If there is a large difference, investigate:

  • Routing
  • Peering
  • Provider traffic engineering
  • Packet loss
  • RX/TX NIC statistics
  • Remote endpoint performance

Do not immediately assume that Linux TCP tuning is responsible.

Step 15: A Practical 10Gbps Optimization Workflow

The safest way to optimize a production dedicated server is to change one variable at a time.

Use this workflow:

Step 1 — Establish the baseline

Record:

Bash sudo ethtool <interface> ip -s link show <interface> sudo ethtool -k <interface> sudo ethtool -l <interface> sysctl net.ipv4.tcp_congestion_control

Then run:

Bash iperf3 -c <SERVER_A_IP> iperf3 -c <SERVER_A_IP> -P 8 iperf3 -c <SERVER_A_IP> -R -P 8

Step 2 — Check CPU behavior

Run:

Bash mpstat -P ALL 1

during the test.

Step 3 — Check packet errors

Compare:

Bash ip -s link show <interface>

before and after the benchmark.

Step 4 — Inspect RSS and IRQ distribution

Bash sudo ethtool -l <interface> grep -i <interface> /proc/interrupts

Step 5 — Change one setting

For example, adjust RSS queue count.

Step 6 — Benchmark again

Run the same iperf3 test.

Step 7 — Keep the change only if it improves the workload

This prevents unnecessary tuning and makes troubleshooting much easier.

Part 16: Recommended 10Gbps Production Baseline

For a modern dedicated server with a 10Gbps network connection, a sensible baseline is:

Hardware

  • Modern multi-core CPU
  • Enterprise-grade 10GbE NIC
  • Appropriate PCIe connectivity for the NIC
  • Sufficient system memory
  • NVMe storage where the workload requires high disk throughput

Network

  • Confirmed 10,000Mb/s link
  • Full duplex
  • MTU 1500 for general Internet-facing traffic
  • Jumbo frames only where the complete required path supports them
  • RSS enabled where supported
  • Appropriate NIC offloading enabled
  • IRQ distribution verified

TCP

  • Use the Linux default congestion control initially
  • Measure before changing TCP parameters
  • Increase TCP buffer limits only when testing indicates they are useful
  • Evaluate BBR based on the actual network path rather than assuming it is faster

Validation

  • Test with iperf3
  • Test single and multiple streams
  • Test both directions
  • Run sustained tests
  • Monitor CPU usage
  • Monitor NIC errors and packet drops

Part 17: 10Gbps Dedicated Server Optimization Checklist

Before putting a high-bandwidth dedicated server into production, verify the following:

  • NIC is correctly identified
  • NIC driver is loaded correctly
  • Link is negotiated at 10,000Mb/s
  • Duplex is Full
  • Cable/transceiver is appropriate for the link
  • MTU has been verified
  • Jumbo frames are used only where supported end-to-end
  • TSO/GSO/GRO and checksum offloading have been reviewed
  • RSS queues have been inspected
  • IRQ distribution has been checked
  • NIC ring-buffer settings have been reviewed where necessary
  • TCP congestion control has been checked
  • TCP buffers have been measured before tuning
  • Interface drops and errors have been checked
  • NIC hardware statistics have been checked
  • iperf3 baseline test has been completed
  • Multiple-stream testing has been completed
  • Reverse-direction testing has been completed
  • Sustained throughput testing has been completed
  • CPU utilization has been monitored during testing

Final Thoughts

Optimizing a 10Gbps dedicated server is not about applying a predefined collection of Linux commands. The most reliable approach is to measure first, change one variable, benchmark again, and keep only changes that produce a measurable improvement.

Start with the physical link and NIC. Then verify MTU, offloading, RSS, IRQ distribution, and TCP behavior. Finally, validate the complete configuration using controlled iperf3 tests while monitoring CPU utilization and NIC statistics. This approach gives you a much clearer picture of whether the bottleneck is the server, NIC, operating system, CPU, TCP stack, or upstream network.

For high-performance workloads, the goal is not simply to make a server display "10Gbps." The goal is to build a network configuration that can deliver consistent, measurable, and reliable throughput under the workload your application actually generates.

Need a server that actually delivers true 10Gbps network performance?

Whether you are running high-traffic media streaming, massive database clusters, or intensive data routing, check out Servers99 for high-performance Dedicated Servers. Equipped with unmetered 10Gbps dedicated ports and enterprise-grade hardware, they are built to handle massive network throughput without bottlenecks.


📚 Read Next: Network & Performance Guides

👉 How to Optimize 10Gbps Dedicated Servers for Max Performance
👉 How to Install & Configure Squid Proxy on Linux

Frequently Asked Questions

No. A 10Gbps port represents the link capacity. Actual application throughput depends on the server hardware, NIC, operating system, protocol overhead, network path, remote endpoint, latency, packet loss, and application workload.

For controlled testing, use iperf3 between two capable servers. Test single and multiple TCP streams and test both directions.

For example:

Bash iperf3 -c <SERVER_IP> -P 8 -t 30

For the reverse direction:

Bash iperf3 -c <SERVER_IP> -R -P 8 -t 30

Not universally.

MTU 9000 can reduce packet-processing overhead for large transfers on controlled networks, but it requires end-to-end support. MTU 1500 remains the safer default for most public Internet-facing dedicated servers.

No.

BBR can improve performance on some network paths, particularly where latency and packet loss affect throughput, but the result depends on the workload and network conditions.

Benchmark CUBIC and BBR rather than assuming one is universally superior.

There is no universal CPU-core requirement.

The CPU required to sustain 10Gbps depends on packet size, NIC offloading, encryption, routing, virtualization, application workload, kernel behavior, and other factors.

A server forwarding large packets with hardware offloading may require substantially less CPU than a server performing intensive encryption or processing very high packet-per-second traffic.

A single TCP flow may be limited by RTT, congestion control, packet loss, TCP window behavior, CPU processing, or other characteristics of the path.

Compare a single-stream test with multiple streams:

Bash iperf3 -c <SERVER_IP>

versus:

Bash iperf3 -c <SERVER_IP> -P 8

If aggregate throughput increases significantly with multiple streams, investigate the characteristics of the individual TCP flow before assuming the NIC is the problem.

Potentially, yes.

DDoS mitigation can introduce additional network processing and routing paths. The impact depends on the mitigation architecture, traffic type, provider network, and available mitigation capacity.

For production workloads, verify the provider's actual network and mitigation architecture rather than evaluating a 10Gbps server solely by its advertised port speed.

Copyright Servers99. All Rights Reserved

Uptime Status DMCA.com Protection Status Listed on WHTop.com
Visa card
master card
amex card
bitcoin
usdt