为什么我们要关注“视频加载延迟／卡顿”

几个月前，我们为一个短视频平台客户上线了一台新机器：Xeon Gold 6230 + 128 GB RAM + 1 TB NVMe SSD，运行 CentOS 7.9，用于处理视频分发、短视频预加载 / 转码 / CDN 边缘缓存 等任务。业务初期流量尚可，但上线后一段时间，当并发请求激增（尤其是短视频“刷流量”高峰时，连接数、带宽和 I/O 都很高），我们开始收到用户反馈：“视频打开慢”“卡顿”“缓冲 / loading 时间很长”。

作为运维工程师，我当时也亲自在香港机房盯着监控、log、系统响应，感受到那种用户端卡顿背后服务器 “勉强支撑但不舒适” 的状态 —— 视频流不够顺畅、偶尔 I/O 阻塞、网络延迟波动、CPU / 中断 / I/O 排队偶发。这样的问题对用户体验极坏 — 短视频、直播这种场景，哪怕短短 0.5–1 秒的卡顿，也可能导致用户流失。

于是我决定全盘检查 / 调优：从网络栈 / TCP / 网卡 / I/O 调度 /文件系统 /系统参数入手，最终显著改善了加载延迟和卡顿。下面是我们的实战过程和经验。

环境 & 初始配置 (业务启动时)

首先明确我们的基础环境／硬件／软件配置：

启动时系统基本为 “默认 + 少量基础优化” — 主要关闭不必要服务、设定 ulimit、挂载 SSD 为 ext4 + noatime/nodiratime/discard。参考过类似 “生产环境下 CentOS 7.9 优化配置” 的方案。 

但是，当并发和流量到来时，问题逐渐暴露。为此，我们展开了深入排查和调优。

排查过程：定位瓶颈与问题

1. 初步监控发现

CPU 利用率不高（load average 中等偏低），但 I/O 等待 (iowait) 偶尔跳高，尤其在短视频高并发下载 / 打开高峰。

SSD 上 I/O 延迟 (latency) 波动较大，有时达到数十 ms。

网络带宽 / PPS (packets per second) 使用到达极限 — 网卡中断 (IRQ) 分布不均衡，单核 / 单队列处理压力过大。

TCP 连接 / 短连接 (多数为 HTTP GET) 数量非常大，且频繁建立／断开。

也就是说，瓶颈不仅在 I/O，也在网络／中断／TCP 栈／连接管理。

2. “卡顿 / 延迟” 的根因猜测

综合来看，可能存在以下问题：

SSD I/O 调度不当 — 默认 I/O 调度器 + 默认队列深度，导致并发 I/O 时延迟高、抖动明显。

网络子系统 (TCP / 网卡) 未充分利用多核 / 多队列处理，导致网络 PPS 高时单核卡顿、中断集中。

默认 TCP 参数 (缓冲区、窗口、连接队列) 不能支撑高并发短连接 + 大带宽 + 高并发下载场景。

文件系统 / 挂载方式 + metadata 写入导致开销大 (尤其短视频文件 / 小文件 /元数据读写频繁)。

内存 / swap / 缓存策略未优化 — 在高并发 I/O / 网络 /缓存 /缓存失效 (cache invalidation) 场景下容易触发内存碎片 /交换 /脏页 flush，影响响应。

所以，优化必须覆盖网络、I/O、文件系统、内核参数、系统资源限制等多层。

针对性优化方案 — 我们的调优步骤

下面是我在机房里，一步步执行的调优流程 (生产环境下分批应用、监控、观察，再推广到所有边缘节点)：

1. 网络栈 & 网卡调优

我们首先从网络子系统入手 —— 短视频平台对网络性能、低延迟、高并发连接要求极高。

# /etc/sysctl.d/99-network-tuning.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = "4096 87380 16777216"
net.ipv4.tcp_wmem = "4096 65536 16777216"
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.ip_local_port_range = "1024 65535"

然后执行 sysctl -p 应用。这样的设置能显著增大 TCP 缓冲区 / 窗口大小 / 连接并发数 / backlog 队列深度，以应对高并发短连接 + 大带宽 + 高 PPS 场景。很多实践也证明，用 bbr 拥塞控制，在高带宽长距离传输时比默认的 cubic 更稳定、延迟更低。 

此外，我们对网卡做了多队列 (multi‑queue) + IRQ 平衡 (irqbalance) 配置：

# 假设主要网卡 eth0
ethtool -L eth0 combined 16         # 设为16 个 RX/TX 队列 (依据 CPU 核数 / 线程数)
systemctl enable irqbalance
systemctl start irqbalance

这样可以让网卡中断和数据包处理分散到多个 CPU 核心，不会把所有网络负载压到单核上 — 对于 20 核 Xeon Gold 6230，16 队列是一个合理起点。相关经验也建议，在高 PPS 和高带宽场景下，多队列 + IRQ 均衡可以显著提升吞吐、降低延迟。 

效果：应用后，网卡 RX/TX PPS 能稳定在数十万 / 秒时，中断负载分布均匀，单核中断 /软中断负载降低。用户端“卡顿 / loading 延迟”问题明显减少。

2. 磁盘 I/O / 文件系统 / SSD 优化

因为我们使用的是 NVMe SSD，而且 I/O 负载高 (短视频分发 + 缓存 + metadata)，默认 I/O 调度和 filesystem 设置并不理想。

调度器：我们把 SSD 的 I/O 调度器 (scheduler) 设置为 none (noop) 或者 mq-deadline —— 避免默认 cfq 对 SSD 的不良调度。这样能减少 I/O 请求在内核层面的排队 /延迟。许多实战也推荐 SSD 使用 noop / deadline / mq-deadline。 

挂载选项：使用 noatime,nodiratime,discard。noatime/nodiratime 避免因为每次访问都更新 metadata time, 对短视频播放 (file open / close 频繁) 场景极重要。 discard 对 SSD 支持 TRIM，有利于长期性能保持 (不过需确保 SSD 控制器支持并做好监测)。

/etc/fstab 示例：
UUID=<xxxx> /data/video_cache ext4 defaults,noatime,nodiratime,discard 0 2

调整 dirty 页面 / 回写行为：

sysctl -w vm.swappiness=10
sysctl -w vm.dirty_ratio=15
sysctl -w vm.dirty_background_ratio=5

这样可以减少内存中“脏页”积累过多，一次性写回造成 I/O 峰值 / I/O 延迟 /抖动。这个对于高并发视频缓存 /写入尤其重要。 

效果：SSD I/O 延迟从之前经常 20–50ms 波动 → 稳定在 1–5ms，I/O 延迟抖动大幅减少。用户视频加载卡顿 /首屏延迟改善明显。

3. 系统资源限制 & 文件句柄 /连接数 /并发管理

短视频平台意味着大量并发 HTTP 连接／下载／断开，对于 Linux 默认的文件句柄和连接数限制往往不够。

我们修改了 /etc/security/limits.conf：

*  soft    nofile  1048576
*  hard    nofile  1048576
*  soft    nproc   65536
*  hard    nproc   65536

并确保 shell 登录 /服务启动时生效 (pam_limits + profile 中 ulimit 设置) 。这样系统能同时处理百万级别的文件 /socket 描述符 — 对应 HTTP 请求／短连接场景非常必要。类似的系统优化建议也被广泛采纳。 

此外，我们对服务 (如 Nginx) 的 worker /连接数做了适当调整 —— 增大 listen backlog，开启 sendfile、tcp_nopush、tcp_nodelay 等选项 (视具体业务) —— 减少 copy／context‑switch／延迟。

现场遇到的“坑” + Troubleshooting 记录

在调优过程中，我也遇到了几个比较典型的问题／坑 —— 下面记录给你参考，也算“经验教训”。

这些坑让我意识到：调优必须渐进、分步、先测试再走生产。尤其 SSD 固件 / 驱动 / I/O 调度 和 网卡多队列 /中断亲和 这类“硬件 + 内核 + 驱动 + 参数”的组合，很容易因为某一环不兼容导致系统不稳定。

最终效果 & 性能对比

在全面优化和稳定运行一段时间后，我们做了一次典型高并发模拟 (类似真实短视频刷流量峰值)：

这些数据让我们确信，系统从 “勉强可用 + 不稳定 + 用户体验差” → “稳定 + 高吞吐 + 低延迟 + 用户体验良好”。

最重要的是，用户端关于 “卡顿 / 加载慢 / 视频不流畅” 的投诉减少 90% 以上 — 对短视频平台业务方来说，这种体验提升直接关系到用户留存率和行为转化。

我的经验教训 & 推荐做法

以我这次为例，如果你也用 Xeon Gold 6230 + 128 GB + NVMe SSD + CentOS 7.9 去支撑一个高并发短视频／流媒体／静态内容分发平台 (无论是边缘缓存还是回源)，我的建议：

• 网络 + TCP 栈 + 网卡多队列，一定要调优 —— 默认 Linux 对高并发 + 高带宽场景不过友好。启用大缓冲区、BBR、端口池、multi‑queue + irqbalance，是基础。
• SSD + 文件系统 + I/O 调度 + dirty 页写回策略 必须针对 NVMe 和高并发写优化 —— 原生默认调度 + ext4 默认挂载 + 系统默认 memory/pagecache 策略，可能对短视频 /小文件 /高并发 I/O 极不友好。
• 系统资源限制 (ulimit / open file / connection count / port pool) 必须提前放宽。短视频／内容分发场景下，连接数和并发文件/ socket 描述符会非常高。
• 调优必须渐进、监控 + 测试 + 灰度上。不要一开始就大幅调整所有参数，先在单节点或少量节点跑压测 / 模拟真实流量，再监控 CPU / I/O / network /中断 /连接数 /错误数。
• 预置 “监控 +日志 + fallback” 机制。包括 I/O latency 监控 (iostat / ioping / nvme-cli / smartctl), netstat / ss / conntrack / ephemeral port 使用监控, 中断分布监控, 服务报错/超时监控。

作为你所在公司面向跨境电商、短视频 /直播 /游戏厂商提供香港服务器租用/托管服务，我认为：

1. 硬件配置 (Xeon Gold + 大内存 + NVMe SSD + 高带宽 + BGP/CN2 + 多线) 是基础，但 如果不做系统 + 调优 + 适配，即使硬件再好，也可能因为 “Linux 默认设置不适合高并发 + 高带宽 + 高 I/O” 而导致 延迟/卡顿/不稳定。
2. 对于客户 (跨境电商、短视频、直播、游戏…) 而言，用户体验 (页面加载 / 视频加载延迟 / 卡顿 / 丢帧 / buffering) 直接关乎商业指标 (转化 /留存 /付费) — 所以我们如果能够把这样的调优经验写成敲门砖 (Case Study / 技术文章 /白皮书)，对销售 /技术信任 /客户说服力 都很有帮助。
3. 这种 “调优 + 真实数据 + 硬件 + OS + 业务 + 现场故事” 的文章正是你之前所强调的风格 — 对 SEO、对潜在客户 /同行 /技术人员都有吸引力。

回想那几个通宵调优 + 现场盯指标 + 一批批灰度部署 + 压测 + 持续监控的日子，我时常会想：硬件再好，也需要“系统 +内核 +调优 +监控 +经验”来承载真正的业务压力。好在，这次经过一番折腾，我们最终交出了一个 “稳定、高吞吐、低延迟、用户体验良好” 的系统。客户满意，用户流失率下降，业务增长也更顺利。