在 K8s 环境下使用 Doris 时遇到了一个诡异的查询闪崩问题。经过多轮基础排查，发现问题与计算复杂度无关，而是与**“结果集回传 / 数据扫描传输”**的瞬间吞吐量强相关，特来求助。
【1. 环境信息】
部署方式： Kubernetes (通过 doris-operator 部署)
集群规模： 1 FE, 1 BE
硬件规格： AMD Ryzen 9 9950X (16C/32T)，BE 分配 80G 内存
表情况： Doris 内部原生表（dwd_ship_downpay_df，约 3000 万行）
【2. 问题现象（极其稳定）】
当执行纯扫表返回大量数据的查询时（例如 SELECT * FROM dwd_ship_downpay_df），查询会极其稳定地在 0.6 秒左右瞬间断连并报错。
报错信息： ERROR 1105 (HY000): errCode = 2, detailMessage = (doris-be-0...)[CANCELLED]Source frontend is not running or restarted
BE 曾出现的底层日志： Fail to find stream_id=9
【3. 核心排查线索（复现场景极其明确）】
小数据量瞬间成功： SELECT COUNT(*) 耗时仅 0.05 秒。LIMIT 10 等小结果集查询毫无问题，说明表未损坏，FE 与 BE 基础通信正常。
临界值“时好时坏”： 当执行 LIMIT 100000（十万行级别）时，连续执行多次，有时会成功，有时会报上述的 0.6 秒闪崩错误。
全量数据“必死”： 执行 SELECT * 必然在 0.6 秒触发 CANCELLED。这说明完全是瞬间大量数据从 BE 涌向 FE（或客户端）时，触发了内部通信的微秒级拥堵、丢包或连接重置。
【4. 我们已排除了以下因素】
不是包大小硬限制： 已将 FE 和 BE 的 brpc_max_body_size 均修改为 1GB (1073741824)。
不是外部网关问题： 直接进入 doris-fe-0 容器内部使用本地 mysql 客户端执行，依然爆出同样错误，证明与 K8s Ingress / LoadBalancer 无关。
当前特殊配置： 为了适配 9950X，当前 be.conf 配置了极高的 brpc_num_threads = 512，fe.conf 配置了 thrift_server_max_worker_threads = 4096。
【5. 求助方向与自查建议】
结合 LIMIT 100000 会偶发成功的现象，我们高度怀疑是极高的 bRPC 线程并发，在瞬间回传海量数据时，打爆了 K8s CNI（如 Flannel/Calico）的缓冲区，或是触发了底层协议的瓶颈。
为了尽快定位问题，我们希望能得到官方大佬的以下指导：
导致该现象的潜在根因： 除了 K8s 宿主机的网卡 nf_conntrack 溢出静默丢包外，是否容易触发 bRPC 底层 HTTP/2 的 Flow Control Window 耗尽？或者是 FE 的 JVM 在瞬间接收大数据时触发了极限 GC 假死？
需要我们提供哪些日志/指标？ 为了协助排查，我们需要在 0.6 秒断连的瞬间，重点抓取哪些模块的 DEBUG 日志？是否需要提供特定端口的 tcpdump 抓包，或者是 /brpc_vars 里的核心指标数据？
我们应该自查哪些其他配置？ 除了建议调低 brpc_num_threads 之外，我们在 OS 层面（如 tcp_rmem / tcp_wmem / somaxconn）或 Doris Session 变量层面，还有哪些可以自查并调整的参数？
期待您的回复与指点，万分感谢！
