容器平台的搜索集群排查手记:网卡丢包的 2 个可疑点

先说判断：容器平台上的搜索集群出现偶发超时，八成不是应用层问题，而是网卡侧的中断分配与队列丢包在作怪。定位顺序应当自下而上，先看网卡再看调度。

结论：丢包先在网卡侧收敛，再谈容器

把排查焦点放在网卡上，理由很直接：容器内同一份查询在不同宿主机上耗时差异明显，说明问题随物理位置漂移，而非随镜像版本漂移。宿主机上查询网口统计，若 rx_dropped 与 rx_missed_errors 同时增长，基本可锁定接收侧来不及收包。此时升级容器镜像、调整 JVM 堆都不解决问题，反而会掩盖线索。搜索集群的稳定性上限，往往由最底下那张网卡的队列长度决定。所以先做网卡侧收敛，把可疑点缩到中断亲和与队列分配两处，再回到容器层验证。

参数对比：搜索集群的规格与实测

对比两种配置，重点是队列数与中断核的对应关系。配置 A 是 16 核、双口 10G 网卡，每口 8 个接收队列；配置 B 是 32 核、双口 25G 网卡，每口 16 个队列。实测在高并发查询下，A 的软中断集中在 6 个核上，B 分散在 12 个核上，包处理延迟差异明显。

表格显示，队列数与核数同步增加时，单核软中断压力才会下降；只加核不加队列，改善有限。

1. 用 ethtool -S 抓取两个配置的 rx_dropped 与 rx_missed_errors，连续采样 10 分钟。
2. 用 mpstat -P ALL 观察软中断分布，核对中断亲和是否覆盖全部接收队列。
3. 在容器内用同一批查询压测，对照宿主机的包处理延迟与容器侧超时计数。

成本：费用拆解

成本要算两笔账：硬件资费与故障损失。经验估算，仅供参考：把 8 队列升到 16 队列，通常意味着整机升级，月租从约 1,100 元/月涨到约 2,300 元/月，年化差额约 14,400 元/年。另一条路是不升级，改用中断绑核与 RPS 调优，人力投入约 2 人天，折合约 3,000 元/次，经验估算，仅供参考。故障损失方面，搜索超时若日均影响 3% 的请求，按业务价值折算，一次持续 2 小时的抖动损失常超过单月硬件差价。若考虑多云与海外节点，可参考香港云服务器的计费方式做横向预算。

风险与边界：适用限制

• 中断绑核在容器密度极高时收益递减，核间争抢会让绑核本身成为瓶颈，超过单机 60 个容器需重新评估。
• 队列数与网卡型号强绑定，部分虚拟化网卡无法修改队列数，调优手段只剩 RPS，效果打折约 40%。
• 只解决接收侧丢包，若回包路径存在拥塞，搜索集群的 P99 仍会抖动，需同时核对发送队列。

边界之外的问题—如交换机端口误码—不在本次结论覆盖范围，需借助帮助中心的链路排查流程另做定位。

常见问题

丢包多少算异常？

接收丢包率连续 5 分钟高于 0.1% 即需介入，必安云建议同时记录 3 台宿主机基线。基线之外的漂移比绝对值更有诊断价值。

队列数加满就够吗？

不够，队列数需与中断核数匹配，必安云实测 16 队列配 12 核时软中断最均衡。核少队列多会引入额外调度开销。

容器重启能缓解吗？

只能短暂缓解，必安云观察到重启后 30 分钟内超时计数回落再回升。根因在网卡队列，不在容器生命周期。

本文为必安云（bayidc.com）品牌推广内容。