明白，你希望我給出一個 100%詳細、可執行、覆蓋 CPU/內核/TCP/應用的排查流程，可以判斷 HTTP 響應慢的原因（機器負載、網絡不穩、業務阻塞），並且每一項都明確列出 觀測指標、方法、命令、判斷依據，特別強調對 業務進程延遲和網絡延遲的影響。下面我整理成系統化指南。

HTTP 響應慢排查指南（CPU / TCP / 網絡 / 應用）

1️⃣ 採集 TCP 棧函數耗時（內核態耗時分析）

目的：量化 TCP/IP 內核處理耗時，判斷 CPU 對網絡延遲影響

方法 A：ftrace function_graph（內核自帶）

# 1. 開啓 function_graph tracer
echo function_graph > /sys/kernel/debug/tracing/current_tracer

# 2. 設置 TCP 棧關鍵函數過濾
echo tcp_v4_do_rcv > /sys/kernel/debug/tracing/set_ftrace_filter
echo tcp_rcv_established >> /sys/kernel/debug/tracing/set_ftrace_filter
echo tcp_sendmsg >> /sys/kernel/debug/tracing/set_ftrace_filter
echo tcp_cleanup_rbuf >> /sys/kernel/debug/tracing/set_ftrace_filter
echo tcp_ack >> /sys/kernel/debug/tracing/set_ftrace_filter

# 3. 開啓 tracing
echo 1 > /sys/kernel/debug/tracing/tracing_on

# 4. 發起 HTTP 請求進行採樣
curl -s http://yourserver/endpoint

# 5. 查看 trace 輸出
cat /sys/kernel/debug/tracing/trace_pipe

觀察指標及判斷：

方法 B：perf record / perf report（採樣分析）

# 採樣系統內核態 CPU
perf record -e cycles:k -a -g sleep 10
perf report

• 檢查 tcp_sendmsg, tcp_cleanup_rbuf, tcp_v4_do_rcv 等函數耗時
• 判斷依據：

• 內核函數佔比高 → CPU 內核成為瓶頸 → HTTP 響應慢由機器負載導致
• 函數耗時低 → TCP 內核處理正常 → 延遲可能由網絡或業務邏輯導致

2️⃣ 採集 CPU 各核使用率

目的：判斷 CPU 是否成為網絡延遲或業務延遲瓶頸

方法

# 每秒採集各核使用率
mpstat -P ALL 1

# 關鍵字段：
# %usr  -> 用户態佔用，應用邏輯處理佔 CPU 時間
# %sys  -> 內核態佔用，內核 TCP/IP 處理耗時
# %soft -> 軟中斷佔用，網絡處理相關
# %iowait -> I/O 等待，磁盤/網絡 I/O 阻塞
# %idle -> 空閒

判斷 TCP 網絡延遲影響

判斷業務延遲影響

3️⃣ 採集 TCP 隊列、RTT、cwnd、重傳

目的：量化網絡狀況對 HTTP 響應延遲的影響

方法

# 每秒採集
ss -ti

關鍵字段説明：

分析邏輯

1. 隊列堆積 + %sys/%soft 高 → CPU/內核瓶頸 → 網絡延遲
2. RTT 高 + retrans 多 + CPU 不高 → 網絡不穩 → 網絡延遲
3. Send-Q 高 + %usr 高 → 應用處理慢 → 業務延遲

4️⃣ 採集應用 handler latency / 線程狀態

目的：判斷業務邏輯是否導致 HTTP 響應慢

方法 A：Web 服務器慢日誌

• Nginx：

log_format latency '$remote_addr $request_time $upstream_response_time';
access_log /var/log/nginx/access.log latency;

• Go HTTP：

start := time.Now()
// handle request
elapsed := time.Since(start)
log.Printf("handler latency: %v", elapsed)

方法 B：線程阻塞狀態

5️⃣ 軟/硬中斷影響觀察（網絡延遲）

# 軟中斷統計
cat /proc/softirqs | grep NET_RX
cat /proc/softirqs | grep NET_TX

# NIC 中斷
cat /proc/interrupts

判斷依據：

• NET_RX / NET_TX 佔用高 → CPU 內核成為網絡處理瓶頸 → HTTP 響應延遲
• 中斷在單核集中 → 處理能力受限 → 網絡延遲增加

6️⃣ 綜合判斷邏輯

HTTP 響應慢
    |
    |-- TCP 棧函數耗時佔內核CPU高 + TCP 隊列堆積 → 機器負載瓶頸
    |-- RTT 高 / retrans 多 + CPU 不高 → 網絡不穩
    |-- Send-Q 堆積 + 用户態 handler latency 高 → 業務邏輯阻塞

7️⃣ 建議觀測流程

1. 每秒採集 CPU 各核 (mpstat -P ALL 1)
2. 每秒採集 TCP 隊列/RTT/cwnd/retrans (ss -ti)
3. Trace TCP 棧函數耗時 (ftrace 或 perf)
4. 採集應用 handler latency / 線程阻塞 (strace / pprof / jstack)
5. 觀察軟/硬中斷 NET_RX/NET_TX (/proc/softirqs / /proc/interrupts)
6. 結合表格判斷延遲來源

💡 總結

• 網絡延遲來源：內核 TCP 棧處理慢（機器負載） 或 網絡擁塞/丟包（RTT/retrans）
• 業務延遲來源：應用處理慢 / 阻塞 (%usr 高 + handler latency 高 + Send-Q 堆積)
• CPU 使用率與延遲關係：

• %sys/%soft 高 → 網絡延遲
• %usr 高 → 業務延遲
• %iowait 高 → I/O 阻塞延遲

如果你需要，我可以幫你寫一個 完整自動化採集腳本：

• 每秒採集：

• TCP 棧函數耗時
• CPU 各核 us/sy/soft/iowait
• TCP 隊列 / RTT / cwnd / retrans
• 應用 handler latency

• 輸出 CSV
• 自動標記延遲來源（機器負載 / 網絡 / 業務阻塞）