[LightDB新功能]LightDB性能监测之PWR DB Time & DB Wait & DB Cpu
背景:
在一个确定的服务器环境里面,为使其吞吐量最大,一个比较理想的的评估模型是,以尽量少的CPU、带宽用量达成一个尽量最大的TPS,且同时维持一个可接受的平均业务时延。为达成此目标,我们通常需要分析代码路径各环节的时间开销,然后根据时间开销去分析瓶颈在哪里。数据库服务器性能调优,也可利用此模型。如果我们能准确测量各代码路径的开销,然后再进行统计分析,那么各个瓶颈就会尽收眼底,为之后的代码调整,内核相关参数调整提供数据参考。
适用版本:LightDB 23.2
功能描述:
在LightDB中,为准确测量各进程CPU用量,IO,竞态,IPC等相关开销耗时,我们在几乎不影响性能的基础上对内核做了适当的改造,改造完成之后,我们可以实时的查询各类IO事件,IPC事件,竞态等时间开销。
一个典型的sql执行周期里面,流程如下:
- 客户端将sql query通过BSD socket写入os kernel
- 客户端os kernel将sql query写入服务端os kernel
- 服务端os kernel接收完请求后,通知上层用户态进程来读
- 用户态进程读取完整的sql query后丢给解析器进行解析
- 解析器解释完之后,执行优化,重定向等相关处理
- sql query正式执行,期间可能会触发多次Lock,IO等相关事件
- sql query执行完成后,通过BSD socket 将结果写回server os kernel
- server os kernel将数据通过网络传递到客户端os kernel
- 客户端os kernel接收完数据后,通知客户端用户态进程来读
- 客户端用户态进程读取结果
其中:
- 1--10全程总耗时,我们称之为DBtime。
- 4--6过程中发生的因竞态,disk read/write, ipc request等相关事件导致当前业务进程阻碍的时间,我们称之为DB wait time, 记录其开销并以各自类别按行标记插入相关统计表。
- 1--3,7--9,属典型的network io,这一部分的优化原则上来讲完全可以独立进行,当前比较流行的思路RDMA,不在此文章讨论范围之内,有兴趣的同学可以参考如下地址进行学习:https://docs.nvidia.com/networking/pages/viewpage.action?pageId=34256560
- DB cpu = DB time - DB wait
在以往的实现中,我们已经包含了采集,出报告等相关功能及流程,新的功能也是建立在此基础之上,因此,在使用流程上与之前并无差别,详细的教程可参考如下教程:
一个常规的性能报告如下:(涉及DB wait, DB cpu, DB time)
另外,因相关统计数据我们是实时存入数据库中的,所以,在实时分析的时候,我们也是可以实时查看监测到的各项指标的。
比如,我们实时监测过去 n 秒状态,可通过如下SQL+watch -n 来实现:(这类似于linux top命令)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 | CREATE OR REPLACE FUNCTION lt_stat_cost_last_n( IN n integer , IN src_table TEXT = 'lt_stat_cost_1s' ) RETURNS TABLE ( bg_type_text TEXT, cost_type_text TEXT, evt_id_text TEXT, evt_sub_id_text TEXT, cost_in_us BIGINT , percent_of_bg_type NUMERIC , percent_of_total NUMERIC ) --SET search_path=@extschema@ AS $$ DECLARE born_end_time TIMESTAMP := NOW(); born_start_time TIMESTAMP := (born_end_time - (INTERVAL '1 SECOND' * n) ); __query TEXT ; __table TEXT ; BEGIN __table := CASE WHEN src_table = 'lt_stat_cost_1s' ::TEXT THEN 'lt_stat_cost_1s' WHEN src_table = 'lt_stat_cost_60s' ::TEXT THEN 'lt_stat_cost_60s' WHEN src_table = 'lt_stat_cost_600s' ::TEXT THEN 'lt_stat_cost_600s' ELSE 'lt_stat_cost_1s' END ; __query := format( 'SELECT s.bg_type, s.cost_type, s.evt_id, s.evt_sub_id, SUM(s.cost::bigint)::bigint AS cost_in_us, CASE WHEN SUM(SUM(cost)) OVER () = 0 THEN 0.00 ELSE ROUND((SUM(cost) / SUM(SUM(cost)) OVER (PARTITION BY s.bg_type)) * 100, 2) END AS percent_of_bg_type, CASE WHEN SUM(SUM(cost)) OVER () = 0 THEN 0.00 ELSE ROUND((SUM(cost) / SUM(SUM(cost)) OVER ()) * 100, 2) END AS percent_of_total FROM %s s WHERE s.born >= ' '%s' ' AND s.born < ' '%s' ' GROUP BY s.bg_type,s.cost_type,s.evt_id,s.evt_sub_id' , __table, born_start_time, born_end_time ); --RAISE NOTICE 'lt_stat_cost_last_n::query: %', __query; RETURN QUERY SELECT * FROM lt_stat_cost_translate_id_to_text(__query) ; END ; $$ LANGUAGE plpgsql; |
1 | watch -n 1 "/home/dev/stage/lightdb-x/bin/ltsql -c \"select * from lt_stat_cost_last_n(1)\"" ; |
下面分别以ltbench 并发1,以及并发16进行测试,并显示其开销明细。
/home/dev/stage/lightdb-x/bin/ltbench lt_test -P 2 -T 10000 -c 1
/home/dev/stage/lightdb-x/bin/ltbench lt_test -P 2 -T 10000 -c 16
测试机器cpu core 4,由上图可知,当并发数明显高于cpu core的时候,可以见到transactionid, tuple相关的Lock耗时明显增加。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· Docker 太简单,K8s 太复杂?w7panel 让容器管理更轻松!