一、性能优化最贵的不是调参是调错方向数据库跑得慢最常见的处理方式是凭经验调参。内存小就加shared_buffers慢查询多就加work_mem。但真实的生产事故里我见过太多这样的困惑内存加了一倍TPS 纹丝不动。原因很简单瓶颈不在你调的那个地方。Oracle DBA 靠 AWR 报告定位瓶颈。金仓也有对标的武器KWR全称 Kingbase Workload Repository工作负载知识库。这篇我在鲲鹏服务器上用 sysbench 给 KingbaseES 压出真实负载再用 KWR 报告做一次完整体检。先剧透一句结局有点反直觉但恰恰是这个反直觉的结局让我看清了性能诊断工具真正的价值。二、体检对象与工具被测的是 KingbaseES 企业版跑在 4 核 7GB 的鲲鹏 ECS 上。加压用 sysbench 1.0.20 的oltp_read_write混合负载读写比大约 7:3用它的 pgsql 驱动直连金仓 54321 端口造了一个 10 张表、每张 10 万行、约 330MB 的sbench库。诊断靠sys_kwr扩展版本 1.8.m1。它就是金仓版的 AWR按固定间隔给数据库拍快照两个快照之间的差异就是一份性能报告。方法论不复杂。拍一张快照压 60 秒再拍一张生成报告。报告告诉我瓶颈在哪对症下药调完再压一轮做对比。三、开工前先踩了三个坑KWR 不是开箱即用的我连踩三个坑都值得记下来。第一个坑采集开关出厂默认全关。sys_kwr.enable、track_sql、track_instance、sys_stat_statements.track四个开关默认都是 off 或 none不打开快照就是空的报告自然没数据。而且打开之后必须重启实例采集进程才会真正建起那些内部统计表。我一开始只做了 reload快照始终缺表重启之后才正常。第二个坑多条ALTER SYSTEM不能塞进一个事务。我图省事把几条ALTER SYSTEM SET用分号连起来塞进一个ksql -c里执行直接报ALTER SYSTEM cannot run inside a transaction block。正确做法是用ksql -f执行脚本文件每条语句独立提交。第三个坑最深中文和 HTML 报告函数有 bug。我一开始调perf.kwr_report_text_cn()想直接出中文报告结果报错relation kwr_snap_db_sql_time does not exist。排查下来根因是报告函数内部引用了一个叫kwr_snap_db_sql_time的表但采集侧实际建的表叫kwr_snap_sql_time中间少了个db_。再往深挖一层通用入口perf.kwr_report()内部会先调kwr_create_wrapped_views()自动创建一批包装视图来补齐这个名字差异而中文版kwr_report_text_cn、文本版kwr_report_text、HTML 版kwr_report_html都漏掉了这个前置步骤于是直接撞上表不存在。解法就一句话别用那三个入口用通用入口perf.kwr_report(start_id, end_id, text, database)。它自洽可用一次生成了 1368 行完整报告零报错。四、基线体检一张报告看清全身打开采集、压测 60 秒、生成基线报告。这就是金仓 KWR 报告的真实模样。报告信息量很大捡最关键的三块说。先看负载分析。1.02 分钟的墙上时间里DB Time 高达 11.06 分钟约等于 10.8 个活跃会话正好对上 16 个压测线程。每秒 1515 个事务、29813 次执行机器在真忙。再看实例效率。Buffer Hit 99.58%缓冲命中率已经接近满分几乎所有数据块都能在内存里找到物理磁盘读极少。也就是说内存根本不是瓶颈。最后看 Top 前台等待事件这块是整份报告的题眼它直接告诉你数据库的时间花在了哪。等待事件占 DB Time类型DB CPU82.93%CPU 算力WALWriteLock9.88%WAL 写锁WALSync5.88%WAL 刷盘 IODataFileRead0.40%数据文件读答案就在这张表里。82.93% 的时间在烧 CPU其次是 WAL 写锁加刷盘合计约 15.7%而数据文件读只占 0.4%。这是一个典型的 CPU 密集型负载4 个核心被 16 个线程榨得干干净净。说实话如果没有这张报告我大概率会先去加shared_buffers。出厂只有 128MB直觉上太小了。但报告清清楚楚地摆在那命中率 99.58%加内存是无用功瓶颈在 CPU。五、对症下药虽然报告已经把话说得很明白CPU 才是那堵墙但我还是想验证两件事。一是那约 16% 的 WAL 等待调优能不能压下去。二是shared_buffers这些内存参数调到位之后到底有没有用。出厂参数确实保守。调优思路是跟着报告走不是拍脑袋。报告说 WAL 是第二瓶颈那就把wal_buffers从 4MB 加到 64MB缓解 WALWriteLockmax_wal_size从 1GB 加到 8GB拉长 checkpoint 间隔commit_delay从 0 调到 20用组提交合并 WALSync 的刷盘次数。顺带验证内存shared_buffers从 128MB 加到 1.5GBwork_mem从 4MB 加到 16MB。有一条底线全程没动synchronous_commit on。不靠牺牲数据持久性来刷分对比才算公平。改完重启参数生效同样的 60 秒压测再来一轮。六、结局反转指标基线调优后TPS每秒事务15151528物理读MB1339205Buffer Hit %99.5899.93DB CPU 占比82.93%82.64%这张表得掰开看因为它同时装着两个看起来矛盾的事实调优生效了和 TPS 没涨。先说生效的部分。shared_buffers从 128MB 加到 1.5GB 之后物理读从 1339MB 降到 205MB降了 85%缓冲命中率升到 99.93%WAL 缓冲等待也消失了。这些都是实打实的改善参数调对了地方也确实生效了。再说没涨的部分。TPS 从 1515 到 1528属于测量波动等于没动。为什么看 DB CPU 那一行调优前 82.93%调优后 82.64%始终压在 82% 以上。这是一个 CPU 密集型负载4 核的算力就是天花板。物理读降了 85% 又如何IO 本来就只占 0.4%从来不在关键路径上。相当于把一条没人走的车道拓宽了十倍堵车的还是 CPU 那条主干道。这也是我觉得 KWR 报告最值钱的地方。它不是一调就快的魔法它是帮你避免做无用功的尺子。第一份报告里它就写明白了命中率 99.58%瓶颈是 CPU 不是内存。假如我无视它一头扎进内存调优最后就会得到一个哭笑不得的结果物理读降了 85%性能一点没涨然后百思不得其解。真正能推高这个负载的方向报告其实也指了。要么加 CPU 核数4 核换 8 核、16 核。要么优化 SQL 逻辑降低单次执行的 CPU 消耗报告里 Plan Reused 只有 80%计划缓存这块还有文章可做。调内存此路不通。七、结论我用 sysbench 给金仓压出真实负载用 KWR 报告完成了一次完整体检。结局不是俗套的一调 TPS 涨三成而是更真实的一课。基线 1515调优后 1528几乎没变。但这不是失败恰恰是 KWR 报告的成功。它在压测的第一分钟就看清了这是 CPU 密集型负载命中率 99.58% 已经说明内存不缺。是它拦住我没把时间浪费在加内存求快这条死路上还把下一步指得明明白白该加的是 CPU不是内存。性能优化这行有句老话没有度量就没有优化。金仓的 KWR就是国产数据库递给 DBA 的那把尺子。它未必让你的库瞬间变快但它能让你每一次调优都调在刀刃上。这比什么都值钱。