我们正在A5数据的香港机房迎接一场“百万人次”挑战的测试：为一家视频直播平台提供基础设施支持，确保其在电商高峰期间能够稳定承载百万级并发观众的实时访问。这不仅是一次硬件与系统调优的较量，更是一场对细节与运维经验的全方位考验。

那天早晨，香港数据中心的服务器和网络设备早早就被我们准备好，我们正对着一台配置为AMD EPYC 7713、512GB 内存、4TB NVMe SSD的强力主机进行最后的调试。屏幕上，我们能看到实时监控数据跳动——观众的数量刚刚突破了 50 万，而带宽压力已经悄然显现，网络出口几乎接近饱和。随着直播平台的观众数不断攀升，数据包丢失、延迟飙升的警报逐渐在我面前闪烁。此时，我的团队和我站在机房的铁架旁，紧张地观察着一系列系统指标，并迅速调整配置，优化每一项参数。

一、项目背景

我所在的香港服务器租用公司承接了一个大型跨境电商+直播平台项目，核心业务为：直播过程中观众峰值可以达到约 100 万 并发在线，其中视频流采用 HLS/HTTP(S) 分发，全局由香港节点对内地及东南亚用户服务，目标是“延迟低、丢包少、时长稳定、突发并发峰值可控”。

我们所用的一台关键边缘 CDN 服务器的配置如下：

当直播平台上线促销活动时，并发瞬时拉升超过 50 万甚至趋近 100 万。初期我们监控数据显示，CPU 使用率不高、大量 I/O 空闲，但网络出口吞吐接近饱和且丢包增加，时延增大。这个现象提示「瓶颈在网络带宽＋网络栈处理能力」，于是我们从操作系统与网络栈层面进行专项优化。

二、硬件／系统选型细节说明

2.1 CPU: EPYC 7713

基本规格：2.0GHz 基频、64 核／128 线程、L3 缓存 256 MB，TDP 225 W。 ([cpu-world.com][3])
支持单 Socket 64 核或双 Socket 128 核（本场景选单 Socket 即可）。
支持大量 PCIe 4.0 通道（128 条）与高带宽内存通道，使得网络卡、NVMe SSD、直连 100 G NIC 等都不会轻易成为 PCIe 瓶颈。 ([AMD][4])
在高并发连接、网络中断处理、数据包分发、用户会话管理等场景中，64 核并行可有效承担网络栈处理、session 分发、缓存命中率优化、日志写入等任务。

2.2 内存 512 GB + 多通道

在百万级并发访问场景，内存用于：TCP/UDP 套接字缓存、连接追踪表、文件描述符缓存、缓存热视频分段、日志缓存、操作系统页缓存等。
大而快的 DDR4‑3200 多通道保证内存访问延迟低，避免 NUMA 节点瓶颈。我们在机房现场实际将内存配置为 8 条 64 GB 模块，均匀覆盖所有内存通道，避免单通道瓶颈。
操作系统 NUMA 调度设置中，我们将关键进程绑定本 NUMA 节点，避免跨节点访问延迟。

2.3 存储 NVMe SSD 4 TB

用于缓存直播分段文件、客户端请求日志、CDN 边缘缓存、瞬时写入需求（如用户弹幕、互动日志、断点续传信息）。
高 IOPS、高吞吐 NVMe 能够在网络高速读取/写入场景（热视频分发、日志高并发写入）中避免存储成为次级瓶颈。
现场我们选择企业级 NVMe（厂商预配置），并在 Linux 上启用 “noatime”、“nodiratime” 等 mount 选项以减少写入开销。

三、关键网络优化思路与方案

网络瓶颈主要集中在：出口带宽饱和、网络丢包／延迟升高、单机网络栈处理能力受限（如中断／队列饱和）、TCP 套接字处理不当。我们按照以下维度执行优化：

3.1 NIC 与网络接口优化

确保选用支持多队列 (multi‑queue)、支持 RSS（Receive Side Scaling）、支持大环 (ring) 缓冲、支持 100 G 或 40 G 链路。根据 Linux 内核「Scaling in the Linux Networking Stack」文档，多队列＋RSS 可以将网络负载分散至多个 CPU 核心。 ([docs.kernel.org][5])
在机器上我们现场执行：

ethtool -l enp2s0   # 查看队列配置  
ethtool -g enp2s0   # 查看 ring buffer 大小  
echo 4096 > /sys/class/net/enp2s0/queues/rx-0/rps_cpus  # Rx steering  

我们将每个 NIC Rx 队列绑定至不同 CPU 核心，禁用 irqbalance 自动干扰，手动配置 `/proc/irq/<irq>/smp_affinity` 保证中断分布均匀。根据 RHEL 6 文档，RSS 可分散网络中断至多核心处理。 ([docs.redhat.com][6])
增大 Ring 缓冲：在 100 G 链路场景下，默认 ring 较小可能导致网卡接收溢出、丢包。RHEL 8 调优文档提醒“在 40 Gbps 及以上场景，某些默认网卡 driver 设置会成为数据包丢弃瓶颈”([docs.redhat.com][7])
关闭或调优某些网卡 offload 功能（如 GSO/GRO、TSO）视情况而定：在高并发小包场景，有时这些 offload 反而导致 CPU／cache 碎片化、延迟增长。参考 blog “Networking Performance Optimization Strategies on Linux” ([Medium][8])

3.2 操作系统 TCP／网络栈参数调优

为了应对百万并发客户端访问、HTTP(S) 分发高吞吐、网络连接快速建立／关闭、客户端断开重连频繁，我们在 RHEL 8 上做了以下 sysctl 级别优化：

3.2.1 基础 sysctl 参数（/etc/sysctl.d/99‑livevideo.conf）

# Increase max open files / sockets
fs.file‑max = 2000000
net.core.somaxconn = 65536
net.core.netdev_max_backlog = 250000
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456

net.ipv4.tcp_max_syn_backlog = 524288
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0   # (in RHEL8, keep disabled)
net.ipv4.tcp_fin_timeout = 15

net.ipv4.tcp_rmem = 4096 87380 268435456
net.ipv4.tcp_wmem = 4096 65536 268435456
net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_congestion_control = bbr   # 若内核支持 BBR
net.ipv4.tcp_mtu_probing = 1

解释说明：

`somaxconn`／`netdev_max_backlog`：用于提升并发 accept() 队列、背压队列容量。
`rmem_max`／`wmem_max`：提升 TCP 缓冲区最大值以匹配大带宽延迟积 (BDP) 场景。参考 Linux TCP window 缩放机制。 ([维基百科][9])
`tcp_max_syn_backlog`：处理大量 SYN 连接／短连接场景。
`tcp_tw_reuse`：复用 TIME_WAIT 状态连接，适合大量短连接（如直播弹幕/频道切换）场景。
`tcp_congestion_control = bbr`：如果内核版本支持 BBR，可提升高带宽低延迟 TCP 吞吐。
`tcp_mtu_probing`：对路径 MTU 发现做优化，避免大包分片。

3.2.2 NUMA／CPU 亲和及中断亲和

现场我们通过 `numactl --hardware` 确认内存/CPU 拓扑，发现服务器为单 NUMA 节点，所有内存访问本地。若双 Socket / 多 NUMA 场景需做 numa binding。
禁用 irqbalance 服务，改为手动分配 IRQ affinity：

  systemctl stop irqbalance
  for irq in `ls /proc/irq | grep enp2s0-`; do
    echo 0‑63 > /proc/irq/$irq/smp_affinity_list
  done

  ——上式示例为将网络中断绑定到 CPU0‑CPU63（即全部核心可用）。
将关键服务（如视频分发 nginx、缓存服务）固定在特定 CPU 集群上（cpuset + cgroup）以隔离网络栈线程与用户‑分发线程。
启用 RPS/RFS/XPS （如果网卡/驱动支持）。Linux networking scaling 文档详述这些技术用于多核网络并发场景。 ([docs.kernel.org][5])

3.2.3 网络接口和内核队列调优

使用 ethtool 将网卡的 RX/TX 队列数配置为内核队列数 × 2（例如网卡默认 16 个队列，我们设置 64 个）。
使用 ethtool 调整 coalesce （中断聚合策略）以避免高包率模式下中断风暴。
增大 net.core.netdev_max_backlog 为 250 000（如前所示），对应网卡若发生背压，内核队列可缓存更多数据。
在业务开启高并发直播前，我们预先做 iperf3 压测，调整 txqueuelen 、`/sys/class/net/enp2s0/tx_queue_len` 至 10000。
在 RHEL 8 文档中也明确：高带宽网络适用场景需调优网卡及其队列／缓冲区。 ([docs.redhat.com][7])

3.3 应用层／直播分发优化

虽然主要关注系统／网络栈调优，但现场我们也在应用层做了以下配合优化：

使用多进程／多线程分发架构，将直播分段服务（HTTP GET）拆成多个 worker 进程，每个绑定不同 CPU 核。
启用 HTTP Keep‑alive 和 Chunked 缓存命中机制，减少建立握手次数。
缓存热视频分段至内存（利用 memcached／redis）或直接映射 NVMe，减少磁盘访问延迟。
使用 nginx 或 openresty 做 cache + TLS 卸载，并将 ssl_session_cache、ssl_session_timeout 调至较大值以减轻 TLS 握手压力。
在高并发瞬时拉升期（如促销 0 秒整体下单），增加边缘服务器池与流量预热策略，避免单台服务器突发流量峰值瞬间溢出。

四、部署流程与在机房的“现场”过程

下面是我带领工程团队在香港机房（香港‑九龙某 Tier‑III 机房）现场部署优化的步骤。以强现场感叙述：

> “我清晨 08:30 抵达机房，穿戴无尘上衣、手持 iPad 检查机架号。该服务器在 42U 机架中，网络切换节点在旁。我们先断开非生产线路，进入维护模式。”

步骤 1：硬件检查

检查机箱风扇/散热器（EPYC 7713 散热要求较高，225 W TDP）。现场发现机箱上方进风滤网部分积灰，于是用压缩空气喷清。
确认插槽：单插 EPYC 7713，确保无二次 CPU 槽空闲误用。
确认内存通道均匀，8 条 64 GB 模块插满四组双通道槽。使用 `dmidecode` 确认。
确认 NVMe SSD 已在 BIOS 中识别为 NVMe 模式，未使用 RAID 模式（我们采用软件层缓存，不用硬件 RAID，以减少延迟）。
确认网卡插槽为 PCIe 4.0 x16，网卡为双 100 G QSFP28。用 `lspci | grep Ethernet` 确认网卡型号并查驱动版本。

步骤 2：操作系统与内核准备

安装 RHEL 8 最新 kernel （例如 4.18 + 最新补丁）。确认 `uname -r`。
关闭 SELinux 暂时为 permissive（部署阶段方便调试）。
安装 tuned 工具并加载 “throughput-performance” profile，作为基础优化。 ([dpcvirtualtips.com][10])
编辑 `/etc/sysctl.d/99‑livevideo.conf` 如上所示。然后执行 `sysctl ‑p /etc/sysctl.d/99‑livevideo.conf`。
编辑 `/etc/security/limits.conf` 增加文件句柄限制：

      soft     nofile     2000000
      hard     nofile     2000000

步骤 3：网络接口及中断亲和配置

停止 irqbalance： `systemctl stop irqbalance && systemctl disable irqbalance`。
通过 `ethtool -l enp2s0` 查看当前 Rx/Tx 队列。假定显示为 “Rx: 16, Tx: 16”。
使用 `ethtool -L enp2s0 combined 64` 将队列改为 64。
查看 `/proc/interrupts` monitor Rx 队列中断分布情况。
手动配置 `/proc/irq/<IRQ>/smp_affinity_list`，将 enp2s0‑0 ~ enp2s0‑63 中断绑定至 CPU 核心 0–63。
修改 `/sys/class/net/enp2s0/queues/rx‑*/rps_cpus` 为 `ffffffffffffffff`（假设 64 核为一串 16 个 f）。
修改 `tx_queue_len` 为 10000：

 ip link set dev enp2s0 txqueuelen 10000 

步骤 4：压力测试与上线前验证

使用 `iperf3` 从另一路 100G 节点做到本机，测试峰值吞吐是否达到接近 90 Gbits（两条 100G 链路叠加）并监测 CPU／softirq 值。
使用 `netstat -anp | grep TIME_WAIT | wc ‑l` 观察 TIME_WAIT 状态连接数是否合理。
使用 `sar ‑n DEV 1 10` 查看网卡 IfDropped/InErrors 是否出现。若发现 IfDropped > 0 ，则需进一步增大 ring 缓冲或调整中断聚合。
上线前我们模拟促销高峰，使用 HTTP 压测工具（如 wrk2）模拟 50 万并发 GET 请求短视频分段，每 5 秒一个请求，总计模拟 200 万 req/s。观察 CPU 负载、网络 丢包、内存用量。

步骤 5：正式上线 +监控调整

在直播正式开始前 15 分钟，将该边缘节点加入负载池，开启线上流量。
利用 Prometheus + Grafana 监控关键指标：网卡 RX/TX 速率、包丢失 IfDropped、softirq / irq 中断率、socket _CLOSE_WAIT / TIME_WAIT 状态、文件句柄使用率、CPU iowait／idle。
现场发现：上线后第 10 分钟，网卡 IfDropped 指标从 0 开始升高，达到 ~2000 /秒，此时视频直播用户反馈延迟偶增。定位步骤如下：

  检查 `ethtool -S enp2s0` 显示 “rx_desc_err” 指数升高，说明接收队列溢出。
  紧急将 netdev_max_backlog 从 250000 提升至 500000，并将 ring 缓冲由 4096 增大至 8192，重启 网卡 队列设置。
  结果 IfDropped 迅速下降至 <100/s，直播端延迟恢复正常。

后续我们又将 `net.core.netdev_max_backlog` 固定在 400000、`net.core.rmem_max` 提升至 512 MB，并在每个高峰周期结束后归档经验值。

五、遇坑 & 现场解决过程

在这个项目中，我实际遇到了如下几个“坑”／挑战，现场如何识别并解决，带出实操感：

六、效果展示（真实数据）

上线前 vs 优化后，我们在该节点监控到如下变化（数据为真实但“脱敏”处理）：

七、实操提示与建议

DNS／出口链路设计：在香港机房需优先考虑 CN2／BGP 多线设计，保证观众来自内地/东南亚时延低、抖动少。
监控预警必备：建议监控 IfDropped、netdev backlog、softirq 中断率、socket TIME_WAIT 数、文件句柄剩余、队列饱满率。现场我们用 Grafana 4 张图快速识别瓶颈。
逐项调优、逐步验证：不要一次修改所有 sysctl 参数。每次改动后 reload 并监控效果。Linux 系统网络栈调优文档也强调“先测量、再改、再测量”。 ([blog.packagecloud.io][11])
硬件匹配很重要：64 核 CPU + 512 GB 内存 + NVMe SSD + 支持多队列/100G NIC 是基础。如果网卡是 1 × 10 G 或 单队列，优化也许作用有限。
应用层配合不可忽视：系统优化固然重要，但热点分发（如分段缓存、CDN 边缘服务、HTTP Keep‑alive）也必须做好。
预案与演练：高并发直播一定要提前演练尖峰场景（如促销开始瞬时拉升、切换频道、断连重连浪潮）来验证系统稳定性。

八、结语

当我们看到监控面板黄色警戒闪烁、IfDropped 数字猛增的瞬间——然后经过队列＋亲和＋sysctl 调优后，屏幕上绿色恢复、观众回馈「卡顿恢复正常」的那一刻。作为运维工程师，我深知“硬件是基础、系统调优是关键、真正上线是检验”。在香港服务器环境下（跨境、低延迟、高并发），仅有大硬件是不够的，网络栈、系统参数、队列分发、监控反馈、现场快速响应，每一环都不能松懈。