[Task] Profile sysbench CPU/Memory/Mutex contention and analyze bottlenecks

[XuPeng-SH]

Performance Task: Profile current sysbench workload (CPU/Memory/Mutex)

Is there an existing issue for performance?

• I have checked existing issues.

Environment

• Branch: main
• Deployment: dev standalone / multi-CN as applicable

Details of Performance

建立一个专用的 sysbench profiling 任务，聚焦当前问题场景下的 CPU、Memory、Mutex 瓶颈：

• 覆盖 go runtime CPU profile、heap、mutex profile；
• 形成可复现、可对比的采集流程；
• 输出 top/火焰图等可定位结论，给出优化方向。

Reproduction Steps (sysbench)

1. 以低干扰方式启动 MO（示例）：

   ./mo-service -debug-http=:6060 -block-profile-rate=100 -mutex-profile-fraction=100 -launch ./etc/launch/launch.toml

2. 确认实际运行的 sysbench 脚本参数（threads、duration、events、sql）
3. 压测时采集 profile（至少持续 30s）：

   curl -s "http://127.0.0.1:6060/debug/pprof/profile?seconds=30" > cpu.pprof
   curl -s http://127.0.0.1:6060/debug/pprof/heap > heap.pprof
   curl -s http://127.0.0.1:6060/debug/pprof/mutex > mutex.pprof
   curl -s http://127.0.0.1:6060/debug/pprof/block > block.pprof
   curl -s http://127.0.0.1:6060/debug/pprof/goroutine > goroutine.pprof

4. 多轮采集：压测前、压测中、压测后。
5. 分析（示例）：

   go tool pprof -top cpu.pprof
   go tool pprof -web cpu.pprof  # 如安装 graphviz
   go tool pprof -top heap.pprof
   go tool pprof -top mutex.pprof
   go tool pprof -top block.pprof

Expected Analysis Output

• CPU: 确认是否存在明显热点算子、锁、序列化/反序列化或调度路径；
• Memory: 定位高分配点，确认是否有持续增长（可疑泄漏）或短时暴涨；
• Mutex: 定位高竞争对象及其调用链，给出是否为代码路径、并发参数或引擎交互导致。

Acceptance

• 采集步骤对同一 workload 可复现
• 形成每类 profile 的结论与可落地优化建议
• 输出下一步修复建议清单（含优先级）

[VioletQwQ-0]

point_select

配置

• binary：main commit 2a008285e + closeTxn 修复 perf(txn): drop redundant client.mu lock in closeTxn success path #25490
• workload：oltp_point_select.lua，10 tables × 1M rows，1000vu，120s
• FileService SHARED cache：memory 8GB + disk 50GB（工作集 1-2GB 全在内存）
• GOMEMLIMIT=40000MiB，mo-srv-129 standalone

TPS / p95

模式	TPS	p95
--db-ps-mode=disable	64,861	84ms
--db-ps-mode=auto (prepared)	139,218	35ms

Profile（auto 1000vu，8GB cache）

CPU（53 核满载）：Syscall6 5.19% + sync.Mutex.Lock 2.65% + gcmarknewobject 2.48% + context.value 2.27% + prometheus.observe 2.19%。无单点热点（cache 命中，无 lz4/memmove/crc32）。

Mutex（总等待 617562s）：sync.Mutex.Unlock 88.75% + runtime.unlock 10.98% + RWMutex.Unlock 31.38% cum。调用链 frontend.handleConn → doComQuery → executeStmtWithTxn，139k QPS 下 frontend 路径分布式锁（Session.mu/Routine/planCache 等），非单把锁，架构层天花板。

Block（总阻塞 377106s）：selectgo 61.17% + sync.Mutex.Lock 30.91% + fdMutex.rwlock 5.57%。

子项结论

closeTxn 锁竞争（#25489 + PR #25490）：closeTxn 第一次 client.mu.Lock 是废锁——markAllActiveTxnAborted 只发 abortC channel 信号不碰锁，每条 autocommit 关闭 txn 都白排一次队。删除后 mutex 等待 -80%、p95 -18%。详见 #25489。

plan DeepCopy（P0 第二项）：planCache 用 SQL 文本做 key，--db-ps-mode=disable 下随机 id 字面量导致命中率 0，每条 SQL 重新 build plan + DeepCopy。auto/prepared 命中后 sql/plan cum 12.79%→0.61%。非 MO bug，优化方向是 SQL normalize（feature）。

SQLFlusher trace 分配（#25505）：trace/ETL 导出路径 SQLFlusher.FlushBuffer 每次新建 10MB buffer（DefaultWriterBufferSize），30s 分配 156GB，CPU 0.006% 但推高 GC。sync.Pool 和按 buf.Len() 预分配两方案均 TPS 退化（-18%/-20%），放弃。详见 #25505。

Profile 位置

• mo-srv-129：/data/mo-prof/pprof/{1000vu_bigcache_disable,1000vu_bigcache_auto}/

[VioletQwQ-0]

read_write 摸底

配置

• binary：main commit 2a008285e + closeTxn 修复 perf(txn): drop redundant client.mu lock in closeTxn success path #25490
• workload：oltp_read_write.lua，10 tables × 1M rows，6 档 vuser，120s
• FileService SHARED cache：memory 8GB + disk 50GB
• GOMEMLIMIT=40000MiB，mo-srv-129 standalone

TPS

vusers	TPS	备注
1	17.8
10	193
50	542
100	622
500	799	饱和点
1000	2,278	8GB cache（大 cache 对写路径也提升 ~2.9x）

read_write 比 point_select 早饱和（500vu 撞墙），写路径瓶颈更重。

Profile（1000vu）

CPU：Syscall6 13.33% + memmove 11.53% + lz4.decodeBlock 5.08% + GC ~16%（scanSpan 7.56% + tryDeferToSpanScan 5.20% + fpTracebackPartialExpand 3.25%）。写 + raft + trace 产生大量垃圾，GC 压力高于 point_select。

Mutex（总等待 9292s）：runtime.unlock 82.52% + sync.Mutex.Unlock 14.56% + RWMutex.Unlock 12.18% cum。和 point_select 不同——read_write 锁竞争主导是 runtime 内部锁（GC/调度），非应用层 sync.Mutex。

Block（总阻塞 18722 hrs，point_select 的 54 倍）：selectgo 92.99% + fdMutex.rwlock 5.61% + txn/rpc.handleTxnRequest 45.61% cum（事务 RPC worker 等待）+ morpc.remoteBackend.writeLoop 1.72%。

Alloc（1580GB/30s）：SQLFlusher 156GB + reflect.unsafe_New 111GB + dragonboat raft 74GB + plan.DeepCopyExpr 58GB + time.newTimer 30GB。

子项结论

SQLFlusher trace 分配（#25505）：read_write 1000vu 下 SQLFlusher 156GB alloc，跨 workload 复现（point_select auto 151GB）。详见 #25505。

handleTxnRequest block（8539 hrs / 45.61%）：line-level 归因确认是 worker pool 空闲等待，非瓶颈。block 全在 server.go:305 的 select 等 s.queue 来请求（8539 hrs），实际处理 req.exec() 仅 535s（0.002%）。多 worker goroutine 累计空闲，不是排队等待，无 runnable starvation，不建 issue。

内存泄漏检测（8GB cache，1000vu，压测前/中/后 heap）

时间点	inuse 大头
压测前	fifocache 154MB + txn/trace 92MB + logtail 38MB
压测中峰值	vector.NewVec 586MB + Vector.Unmarshal 134MB + HandleRowsDelete 122MB
压测后 30s	fifocache 154MB + txn/trace 92MB + logtail 64MB

无明显泄漏：压测中峰值分配在压测后被 GC 回收，before/after 稳定占用持平。after 略高（bytes.growSlice 72MB）属后台 ETL/trace 正常波动。注：单次 1000vu 无法触发长时间泄漏（如 #25198 系列 CN 事务泄漏），需长时间多轮压测验证。

Profile 位置

• mo-srv-129：/data/mo-prof/pprof_rw/1000vu/（默认 cache 6 档 profile）+ /data/mo-prof/pprof/rw_leak/（8GB cache 泄漏检测）
• 火焰图见下方附件

[VioletQwQ-0]

阶段更新：clean point_select + SQLFlusher 跨 workload 复现

point_select clean rer跑

之前 point_select 表被 read_write 的 delete/tombstone 污染，IsRowDeleted 进入读取路径，影响了 point_select 归因。重新使用 clean 数据后结果提升：

模式	TPS	变化
--db-ps-mode=disable	67,439	+4%
--db-ps-mode=auto (prepared)	150,942	+8%

clean auto 1000vu：avg 6.61ms，p95 27.17ms，CPU profile 1602.14s/30s ≈ 53.4 cores（64 CPU 机器上不是完全打满）。

clean auto 1000vu 当前瓶颈

不是单一 closeTxn 锁。

CPU 侧：

• 网络返回 syscall：linux.Syscall6 95.06s / 5.93%，主要是结果包写回客户端。
• GC/分配：mallocgc 14.56% cum，gcBgMarkWorker 9.8% cum。
• 读路径：TableScan/readutil/blockio 有明显 cum 成本。

Mutex 侧：

• total wait：486.38hrs
• IsMOCtledSpan：338.65hrs / 69.63%
• trace.Start：308.91hrs / 63.51%
• txnClient.closeTxn：35.88hrs / 7.38%
• txnOperator.closeLocked：36.16hrs / 7.44%

这说明 #25490 之前的 closeTxn 废锁已经不是主导；clean auto 的最大锁等待来自 trace control 读路径的全局 mutex。该发现已建 #25539，但由于 trace 正在整体删除，#25539 已关闭，仅保留 profile 证据作为背景。

SQLFlusher 分配（#25505）跨 workload 复现

SQLFlusher.FlushBuffer 的固定 10MB buffer 分配在 clean point_select、read_only、insert 中都复现：

workload	total alloc	SQLFlusher.FlushBuffer	share
point_select clean auto 1000vu	4.62TB	223.18GB flat / 225.06GB cum	4.87%
read_only 500vu	7.65TB	~0.23TB cum	3.05%
read_only 1000vu	7.07TB	230.25GB flat / 236.91GB cum	3.27%
insert 500vu	8.67TB	~0.23TB cum	2.71%
insert 1000vu	9.09TB	232.46GB flat / 240.73GB cum	2.59%

line-level 均指向：

pkg/util/export/etl/content.go:196
sqlCsv := bytes.NewBuffer(make([]byte, 0, table.DefaultWriterBufferSize))

read_only/insert 1000vu 中，fmt.Sprintf 只有 4-6GB，conn.Exec 只有 2-3GB，说明主因是每次 flush 固定申请 10MB escape buffer。

下一步

1. [Performance] SQLFlusher trace/ETL path allocates heavily under high-concurrency sysbench workloads #25505 使用当前 patch 重跑 point_select clean auto 1000vu。验收：SQLFlusher.FlushBuffer 从 ~223GB 降到 GB 级或退出 top20，TPS/CPU 不回退。
2. 重跑必须使用 clean point_select 数据，不能复用跑过 read_write/delete 的表，避免 tombstone 污染 TPS/CPU/profile。
3. read_only/insert 结果可作为 [Performance] SQLFlusher trace/ETL path allocates heavily under high-concurrency sysbench workloads #25505 的跨 workload 证据，不直接混入 point_select patch 验收基线。