pgsql怎么从interval中取出数字_「实录」来⾃原⼚｜⾸次利⽤
GPCC历史数据调优。。。
导读：数据库性能分析和优化是⼀个难题，作者 Pivotal Greenplum ⼯程技术经理王昊所在的Greenplum 研发部门近期正好在解决⼀个实际⽤户的全局性能问题，本⽂记录了分析过程和解决思路。
《「实录」来⾃原⼚｜⾸次利⽤GPCC历史数据调优Greenplum 第⼀部分》帮助⼤家了解了 Greenplum 集的整体性能特征，现在为⼤家带来第⼆部分——分析查询负载整体情况的⼲货内容。
第⼆部分，分析查询负载整体情况
先介绍和对⽐ GPCC 的查询历史表
对⽐ GPPerfmon，查询历史记录提供的信息如下：
⾸先需要做的是对升级前后的查询数量进⾏定量分析。由于 GP4 上的 GPPerfmon 只能采集到20秒以上的查询，这给对⽐分析带来了⼀
定的困难。
下⾯ SQL 分别对 GPPerfmon 和 GPCC 4.8 的历史各选取⼀周的数据进⾏统计，将执⾏时间按照0-20秒、20-40秒、40-60秒、60秒-
2分钟、2分钟-5分钟、5分钟-10分钟、10分钟以进⾏分类统计。
-- GPPERFMONSELECT sum(CASE WHEN tfinish - tsubmit < INTERVAL '20s' THEN 1 ELSE 0 END)  AS dur0_20    , sum(CASE WHEN tfinish - tsubmit >
-- GPCC 4.8SELECT sum(CASE WHEN tfinish - tsubmit < INTERVAL '1s' THEN 1 ELSE 0 END)  AS dur0_1  , sum(CASE WHEN tfinish - tsubmit >= INTER
各区间查询数量对⽐
剖析：
通过 GP5 上的历史数据来看，⼀周内发⽣的⼩于1秒的短查询3000万次以上，同时混合5-10分钟的分析型查询，属于较典型的
HTAP 混合负载的使⽤场景，⽽且系统资源⼀直处于⾼负荷运⾏⽔平。
⽤户⾃述由于性能考虑关闭了 ORCA，也符合短查询较多的⽤户场景。
由于只能对⽐20秒以上的查询，通过上图我们看到这部分查询数量在升级前后基本持平，GP4 共计201507查询对⽐ GP5 的
202816个，差距在1%以内。
2分钟-5分钟档位下，GP5 的查询增加了⼀倍，但20秒-40秒档位和5分钟到10分钟档位，GP5 都降低了，总体差距不明显。
整体⽽⾔，升级前后⽤户的⼯作负载没有质的变化，基本排除了⼯作负载增加导致系统响应降低的问题。
因为⽤户反映的问题是“整体性能降低”，因此除了查询数量，有必要进⼀步分析查询的平均时间，期待平均的查询时间能够佐证⽤户的反
馈。单个查询的 tfinish – tsubmit 就得到执⾏时间，代⼊到前⼀个查询中就可以计算出查询的平均耗时。⽤下⾯查询对不同时长区间的查
常见mpp数据库
询分别统计平均耗时。
-- GPPERFMONSELECT    elp20_40  , elp20_40 / cnt20_40    avg20_40  , elp40_60  , elp40_60 / cnt40_60    avg40_60  , elp60_120  , elp60_120 / c
-- GPCC 4.8-- 省略 (只需将以上查询替换成gpmetrics.gpcc_queries_history即可，不再重复以节省篇幅)-- 统计结果elp20_40  | 592:01:47.648825  --总时长avg20_4
各区间平均查询时长(秒)对⽐
剖析：
以上分析反映出在所有超过20秒的查询中，升级前后各个区间的查询平均时间变化细微，合计的平均查询耗时从2分29秒降低到2分26
秒。这个结果不⾜以佐证⽤户反馈的现象。
以上针对查询个数和平均时长的统计似乎没有直接结论，抱着怀疑的态度，⼜对每个数据库⾓⾊的查询进⾏了分析，统计每个⽤户提交的查
询个数、平均时长。
SELECT    substring(md5(username) FROM 1 FOR 7)  , cnt_queries  , total_time  , EXTRACT(EPOCH FROM total_time/cnt_queries) avg_secondsFRO
各⽤户的平均查询时长对⽐
剖析：
通过对⽐得出，只有550b111、f8da676、4287401三个⽤户的查询在升级后平均耗时增加了。
遗憾的是 GP4 的 GPPerfmon 数据并没有短查询的记录，⽽且记录的性能指标也不⾜，例如没有磁盘IO的指标，所以⽆法与 GP5 的历史记录进⾏深⼊的对⽐分析。根据当前的分析结果，我们进⼀步跟客户进⾏了沟通确认，澄清认定了查询数量基本⼀致，20秒以上慢查询的平均时长没有增加，只有少部分⽤户的查询的确略微变慢等事实。对于 GP5 上实⽤ GPCC4.8 收集的查询数据，不包含20秒的限制，所以可以针对 GP5 的历史数据专门分析⼀下各⽤户的整体的查询特征。这⾥我们以1秒为界，分别统计⼀秒以内的查询和超过1秒的查询：
剖析：
从紫红⾊总查询时长看出，第⼀位的⽤户a4fde70贡献了该系统绝⼤多数⼯作负载，其占⽤的数据库运⾏时间占绝对地位，并且平均单个查询的耗时也⽐较长，其⼯作负载以分析型为主。
从蓝⾊数字看到，查询数量上前三位的⽤户贡献了⼤量的短查询，第⼆位的f8da676，其平均时长最短且数量⼤，可以推断出是主要的短查询为主数据库⽤户。
总体⽔平看，该系统短查询偏多，这类系统对响应时间敏感，有必要进⼀步挖掘⽤户的反馈。
(未完待续)
关于作者
王昊
Pivotal Greenplum⼯程技术经理
曾任职于 Teradata SQL 实验室。长期从事分布式数据仓库的研究，深谙⾼并发MPP数据库之美，作为 Greenplum 内核研发团队的核⼼成员，主持全新⼀代⾃治数据库平台 GPCC 的规划、设计和开发，
奠定了 Greenplum 在⾃动化运维领域的领先地位。同时凭借丰富的⼯程经验和⾏业洞悉，为中国研发团队在分布式引擎、ETL⼯具、扩展组件、质量保证等多项领域提供创新输⼊和⼈才培养。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。