402 Star 1.4K Fork 1.5K

GVPopenGauss / openGauss-server

 / 详情

query执行时间过长,wait IO【M】

待办的
咨询
创建于  
2024-02-26 10:59

问题:
查询语句select count(*) from 表名执行时间超48小时,session_stat显示WAIT IO,磁盘不忙。帮忙分析问题

openGauss版本:2.0.0
输入图片说明

相关图片:
输入图片说明
输入图片说明
输入图片说明

评论 (7)

enmo_limengjie 创建了咨询

Hey @enmo_limengjie, Welcome to openGauss Community.
All of the projects in openGauss Community are maintained by @opengauss_bot.
That means the developers can comment below every pull request or issue to trigger Bot Commands.
Please follow instructions at Here to find the details.

Hi @enmo_limengjie, please use the command /sig xxx to add a SIG label to this issue.
For example: /sig sqlengine or /sig storageengine or /sig om or /sig ai and so on.
You can find more SIG labels from Here.
If you have no idea about that, please contact with @xiangxinyong , @zhangxubo .

王恬静 负责人设置为pengjiong
pengjiong 添加协作者pengjiong
pengjiong 负责人pengjiong 修改为wangfeihuo

@enmo_limengjie
你好,想问下这个问题有没有多点的信息? 比如什么时候下出现的, 表的个数、大小之类的? 另外这个问题必现吗 或者有重现方法吗?

直接select count(*) 其实连表都不用扫描,不太涉及到IO的操作,应该耗时很短才对
输入图片说明

图片中有详细描述,
语句:select /*+ indexonlyscan(table_name index_name) */ from table_name
表的大小:29GB,索引大小:3872MB

1)indexonlyscan超48小时未执行完毕:已解决,原因为没有vm文件,已经通过vacuum机制重新生成vm文件 。
2)引入新的问题:没有回表情况下, indexonlyscan 性能慢于 seqscan, seqscan 扫描全表为 10分钟左右,indexonlyscan 扫描全表为 2-3 小时左右

通过测试,
1)索引的不连续对于范围扫描有一定的影响。参考下图(下图中是否连续指的索引的叶子节点,未特殊标明的走的是bitmapscan)


2)对于连续的索引,走了错误的执行计划。数据量为35%时,analyze后,默认走的bitmapscan,但加hint发现走seqscan更快
输入图片说明

enmo_limengjie 修改了描述

@enmo_limengjie

能否打开如下两个开关看下bitmapscan 和 seqscan的路径代价?
log_min_messages = debug5
logging_module = 'on(OPT_JOIN)'
输入图片说明

代价在data 目录下的pg_log/postgresqlxxxx.log 下,如下所示:
输入图片说明

登录 后才可以发表评论

状态
负责人
项目
里程碑
Pull Requests
关联的 Pull Requests 被合并后可能会关闭此 issue
分支
开始日期   -   截止日期
-
置顶选项
优先级
预计工期 (小时)
参与者(4)
13084139 opengauss bot 1686829535
C++
1
https://gitee.com/opengauss/openGauss-server.git
git@gitee.com:opengauss/openGauss-server.git
opengauss
openGauss-server
openGauss-server

搜索帮助