小镇做题家

摘要： 技术1：网卡接收数据 → 硬中断 → NAPI软中断（/proc/net/softnet_stat） → ring buffer(/proc/net/tcp 是否flow) → TCP buffer(slab && ss -tmi) → socket buffer → 应用 技术2：网卡接收数据 → 阅读全文

摘要： 好，这一条我完全按你的要求来，这次不再是“回答问题”，而是给你一份 100% 底层、100% 独立、可以直接作为内核/性能排障标准文档的说明。 下面内容满足你提的所有硬约束： IRQ / RX / RSS 完全独立 不互相引用、不互相推导 只讲内核与硬件真实路径 不给经验判断，只给可验证事实 不拿 阅读全文

摘要： 明白了，你希望做一个 完整、系统、实践可操作的文档，涵盖 IRQ affinity → RX 队列 → RSS，并且特别关注 如何严谨判断 CPU 100% 是否由 IRQ 引起。我会分成 概念、作用、查看方法、验证瓶颈、优化建议五个部分，并提供 可落地命令与示例。我会重点说明为什么 单看 mpst 阅读全文

摘要： 明白，我在原来的完整文档基础上，专门补充 ss -t -a -i 如何查看 TCP buffer 的详细信息，以及 offload 的查看方法和字段说明，保持原文档结构和内容，只做必要的补充和强化说明。 完整文档（补充版） 1️⃣ IRQ 绑核（硬中断 CPU affinity） 作用： 网卡接收数 阅读全文

摘要： 明白，我将根据你的要求生成最终完整表格版文档，特点如下： A 场景（不用 eBPF）：去掉“被删原因 / 历史变动”列，保留字段、说明、单位、shell 示例、判断标准、潜在影响 B 场景（用 eBPF）：保持原表格 软中断和硬中断触发条件 + 流程：完整列出来源、触发条件、shell / eBPF 阅读全文

摘要： 接收端延迟确认延迟 阅读全文

摘要： 明白了，你希望我把你之前的分析完全升级为真正“可直接写入事故报告”的全量、细节版文档，同时把 perf 部分做到可操作、逐条分析、覆盖调度、futex、run time、Go runtime 内部分析，绝对不删减任何知识点。我整理了一份 完整专业版文档，按照逻辑顺序、命令、表格、判断标准、K8S c 阅读全文

摘要： # Nginx Buffer 和 Cache 配置完全汇总 ## 一、Buffer 配置详解 ### 1. **请求 Buffer（客户端 → Nginx）** ```nginx # 缓存的内容：HTTP请求的请求体和请求头 client_body_buffer_size 16k; # 缓存客户端请 阅读全文

摘要： 明白，你希望我给出一个 100%详细、可执行、覆盖 CPU/内核/TCP/应用的排查流程，可以判断 HTTP 响应慢的原因（机器负载、网络不稳、业务阻塞），并且每一项都明确列出 观测指标、方法、命令、判断依据，特别强调对 业务进程延迟和网络延迟的影响。下面我整理成系统化指南。 HTTP 响应慢排查指 阅读全文

摘要： 功能当前实现情况是否真正实现 实时吞吐 libpcap 统计字节 ✅ 已实现 RTT 占位 10ms ❌ 未实现真实 RTT BDP throughput * RTT ❌ 因 RTT 固定，所以不准确 TCP Buffer /proc/sys/net/tcp_*mem ✅ 已实现 系统内存 Buff 阅读全文