PgSQL · 实战经验 · 如何预测Freeze IO风暴

背景和原理

有没有被突发的IO惊到过，有没有见到过大量的autovacuum for prevent wrap。 
PostgreSQL 的版本冻结是一个比较蛋疼的事情，为什么要做版本冻结呢？ 
因为PG的版本号是uint32的，是重复使用的，所以每隔大约20亿个事务后，必须要冻结，否则记录会变成未来的，对当前事务”不可见”。 
冻结的事务号是2

src/include/access/transam.h
#define InvalidTransactionId            ((TransactionId) 0)
#define BootstrapTransactionId          ((TransactionId) 1)
#define FrozenTransactionId                     ((TransactionId) 2)
#define FirstNormalTransactionId        ((TransactionId) 3)
#define MaxTransactionId                        ((TransactionId) 0xFFFFFFFF)

现在，还可以通过行的t_infomask来区分行是否为冻结行

src/include/access/htup_details.h
/*
 * information stored in t_infomask:
 */
#define HEAP_XMIN_COMMITTED             0x0100  /* t_xmin committed */
#define HEAP_XMIN_INVALID               0x0200  /* t_xmin invalid/aborted */
#define HEAP_XMIN_FROZEN                (HEAP_XMIN_COMMITTED|HEAP_XMIN_INVALID)

表的最老事务号则是记录在pg_class.relfrozenxid里面的。

执行vacuum freeze table，除了修改t_infomask，还需要修改该表对应的pg_class.relfrozenxid的值。

那么系统什么时候会触发对表进行冻结呢？

当表的年龄大于autovacuum_freeze_max_age时（默认是2亿），autovacuum进程会自动对表进行freeze。 
freeze后，还可以清除掉比整个集群的最老事务号早的clog文件。 
那么可能会出现这样的情形： 
可能有很多大表的年龄会先后到达2亿，数据库的autovacuum会开始对这些表依次进行vacuum freeze，从而集中式的爆发大量的读IO（DATAFILE）和写IO（DATAFILE以及XLOG）。 
如果又碰上业务高峰，会出现很不好的影响。

为什么集中爆发Freeze很常见？ 
因为默认情况下，所有表的autovacuum_freeze_max_age是一样的，并且大多数的业务，一个事务或者相邻的事务都会涉及多个表的操作，所以这些大表的最老的事务号可能都是相差不大的。 
这样，就有非常大的概率导致很多表的年龄是相仿的，从而导致集中的爆发多表的autovacuum freeze。

PostgreSQL有什么机制能尽量的减少多个表的年龄相仿吗？ 
目前来看，有一个机制，也许能降低年龄相仿性，但是要求表有发生UPDATE，对于只有INSERT的表无效。 
vacuum_freeze_min_age 这个参数，当发生vacuum或者autovacuum时，扫过的记录，只要年龄大于它，就会置为freeze。因此有一定的概率可以促使频繁更新的表年龄不一致。

那么还有什么手段能放在或者尽量避免大表的年龄相仿呢？ 
为每个表设置不同的autovacuum_freeze_max_age值，从认为的错开来进行vacuum freeze的时机。 
例如有10个大表，把全局的autovacuum_freeze_max_age设置为5亿，然后针对这些表，从2亿开始每个表间隔1000万事务设置autovacuum_freeze_max_age。 如2亿，2.1亿，2.2亿，2.3亿，2.4亿….2.9亿。 
除非这些表同时达到 2亿，2.1亿，2.2亿，2.3亿，2.4亿….2.9亿。 否则不会出现同时需要vacuum freeze的情况。

但是，如果有很多大表，这样做可能就不太合适了。 
建议还是人为的在业务空闲时间，对大表进行vacuum freeze。

优化建议 
1. 分区，把大表分成小表。每个表的数据量取决于系统的IO能力，前面说了VACUUM FREEZE是扫全表的， 现代的硬件每个表建议不超过32GB。 
2. 对大表设置不同的vacuum年龄. alter table t set (autovacuum_freeze_max_age=xxxx); 
3. 用户自己调度 freeze，如在业务低谷的时间窗口，对年龄较大，数据量较大的表进行vacuum freeze。 
4. 年龄只能降到系统存在的最早的长事务即 min pg_stat_activity.（backend_xid, backend_xmin）。 因此也需要密切关注长事务。

讲完了Freeze的背景，接下来给大家讲讲如何预测Freeze IO风暴。

预测 IO 风暴

如何预测此类(prevent wrapped vacuum freeze) IO 风暴的来临呢？ 
首先需要测量几个维度的值。

  1. 表的大小以及距离它需要被强制vacuum freeze prevent wrap的年龄
  2. 每隔一段时间的XID值的采样（例如每分钟一次），采样越多越好，因为需要用于预测下一个时间窗口的XID。（其实就是每分钟消耗多少个事务号的数据）
  3. 通过第二步得到的结果，预测下一个时间窗口的每分钟的pXID（可以使用线性回归来进行预测）
    预测方法这里不在细说，也可以参考我以前写的一些预测类的文章。

预测的结论包括”未来一段时间的总Freeze IO量，以及分时的Freeze IO量”。 
预测结果范例 
Freeze IO 时段总量 

Freeze IO 分时走势 

预测过程

  • 每隔一段时间的XID值的采样（例如每分钟一次），采样越多越好，因为需要用于预测下一个时间窗口的XID。（其实就是每分钟消耗多少个事务号的数据）
vi xids.sh
#!/bin/bash
export PATH=/home/digoal/pgsql9.5/bin:$PATH
export PGHOST=127.0.0.1
export PGPORT=1921
export PGDATABASE=postgres
export PGUSER=postgres
export PGPASSWORD=postgres

psql -c "create table xids(crt_time timestamp, xids int8)"
for ((i=1;i>0;))
do
# 保留1个月的数据
psql -c "with a as (select ctid from xids order by crt_time desc limit 100 offset 43200) delete from xids where ctid in (select ctid from a);"
psql -c "insert into xids values (now(), txid_current());"
sleep 60
done

chmod 500 xids.sh

nohup ./xids.sh >/dev/null 2>&1 &

采集1天的数据可能是这样的

postgres=# select * from xids ;
          crt_time          | xids
----------------------------+------
 2016-06-12 12:36:13.201315 | 2020
 2016-06-12 12:37:13.216002 | 9021
 2016-06-12 12:38:13.240739 | 21022
 2016-06-12 12:39:13.259203 | 32023
 2016-06-12 12:40:13.300604 | 42024
 2016-06-12 12:41:13.325874 | 52025
 2016-06-12 12:42:13.361152 | 62026
 2016-06-12 12:43:15.481609 | 72027
...
  • 表的大小以及距离它需要被强制vacuum freeze prevent wrap的年龄(因为freeze是全集群的，所以需要把所有库得到的数据汇总到一起)
vi pred_io.sh

#!/bin/bash
export PATH=/home/digoal/pgsql9.5/bin:$PATH
export PGHOST=127.0.0.1
export PGPORT=1921
export PGDATABASE=postgres
export PGUSER=postgres
export PGPASSWORD=postgres

psql -c "drop table pred_io; create table pred_io(crt_time timestamp, bytes int8, left_live int8);"
for db in `psql -A -t -q -c "select datname from pg_database where datname <> 'template0'"`
do
psql -d $db -c " copy (
select now(), bytes, case when max_age>age then max_age-age else 0 end as xids from
(select block_size*relpages bytes,
case when d_max_age is not null and d_max_age<max_age then d_max_age else max_age end as max_age,
age from
(select
(select setting from pg_settings where name='block_size')::int8 as block_size,
(select setting from pg_settings where name='autovacuum_freeze_max_age')::int8 as max_age,
relpages,
substring(reloptions::text,'autovacuum_freeze_max_age=(\d+)')::int8 as d_max_age,
age(relfrozenxid) age
from pg_class where relkind in ('r', 't')) t) t
) to stdout;" | psql -d $PGDATABASE -c "copy pred_io from stdin"
done

. ./pred_io.sh

得到的数据可能是这样的

postgres=# select * from pred_io limit 10;
          crt_time          | bytes  | left_live
----------------------------+--------+-----------
 2016-06-12 13:24:08.666995 | 131072 | 199999672
 2016-06-12 13:24:08.666995 |  65536 | 199999672
 2016-06-12 13:24:08.666995 |      0 | 199999672
 2016-06-12 13:24:08.666995 |      0 | 199999672
 2016-06-12 13:24:08.666995 |      0 | 199999672
 2016-06-12 13:24:08.666995 |      0 | 199999672
...
  • 预测XIDs走势(略)，本文直接取昨天的同一时间点开始后的数据。
create view v_pred_xids as
with b as (select min(crt_time) tbase from pred_io),
       a as (select crt_time + interval '1 day' as crt_time, xids from xids,b where crt_time >= b.tbase - interval '1 day')
select crt_time, xids - (select min(xids) from a) as xids from a ;

数据可能是这样的，预测未来分时的相对XIDs消耗量

          crt_time          | xids
----------------------------+------
 2016-06-13 12:36:13.201315 |    0
 2016-06-13 12:37:13.216002 |    100
 2016-06-13 12:38:13.240739 |    200
 2016-06-13 12:39:13.259203 |    300
 2016-06-13 12:40:13.300604 |    400
  • 结合pred_io与v_pred_xids 进行 io风暴预测 
    基准视图，后面的数据通过这个基准视图得到
create view pred_tbased_io as
with a as (select crt_time, xids as s_xids, lead(xids) over(order by crt_time) as e_xids from v_pred_xids)
select a.crt_time, sum(b.bytes) bytes from a, pred_io b where b.left_live >=a.s_xids and b.left_live < a.e_xids group by a.crt_time order by a.crt_time;

未来一天的总freeze io bytes预测

postgres=# select min(crt_time),max(crt_time),sum(bytes) from pred_tbased_io ;
            min             |            max             |   sum
----------------------------+----------------------------+----------
 2016-06-13 12:36:13.201315 | 2016-06-14 12:35:26.104025 | 19685376
(1 row)

未来一天的freeze io bytes分时走势 
得到的结果可能是这样的

postgres=# select * from pred_tbased_io ;
          crt_time          |  bytes
----------------------------+----------
 2016-06-13 12:36:13.201315 |    65536
 2016-06-13 12:37:13.216002 |   581632
 2016-06-13 12:38:13.240739 |        0
 2016-06-13 12:39:13.259203 |        0
 2016-06-13 12:40:13.300604 |        0
 2016-06-13 12:41:13.325874 |        0
 2016-06-13 12:43:15.481609 |   106496
 2016-06-13 12:43:24.133055 |     8192
 2016-06-13 12:45:24.193318 |        0
 2016-06-13 12:46:24.225559 |    16384
 2016-06-13 12:48:24.296223 | 13434880
 2016-06-13 12:49:24.325652 |    24576
 2016-06-13 12:50:24.367232 |   401408
 2016-06-13 12:51:24.426199 |        0
 2016-06-13 12:52:24.457375 |   393216
......

小结

预测主要用到哪些PostgreSQL的手段?

  1. 线性回归
  2. with语法
  3. 窗口函数
  4. xid分时消耗统计
  5. 强制prevent wrap freeze vacuum的剩余XIDs统计
时间： 2024-09-20 21:38:12

PgSQL · 实战经验 · 如何预测Freeze IO风暴的相关文章

PostgreSQL的&quot;天气预报&quot; - 如何预测Freeze IO风暴

还记得我写的这篇文档吗? <PostgreSQL 大表自动 freeze 优化思路>https://yq.aliyun.com/articles/50411 文章主要针对如何优化大表的freeze调度来减少IO风暴的问题,请注意只是减少,不是避免. 作为一名有追求的PGer,要时刻保持警惕,生于忧患.死于安乐:本文要给大家讲的是预测风暴,掌握了预测能力,才能未雨绸缪,淡定的面对暴风雨. 预测 IO 风暴 如何预测此类(prevent wrapped vacuum freeze) IO 风暴的来

PgSQL · 实战经验 · 分组TOP性能提升44倍

业务背景 按分组取出TOP值,是非常常见的业务需求. 比如提取每位歌手的下载量TOP 10的曲目.提取每个城市纳税前10的人或企业. 传统方法 传统的方法是使用窗口查询,PostgreSQL是支持窗口查询的. 例子 测试表和测试数据,生成10000个分组,1000万条记录. postgres=# create table tbl(c1 int, c2 int, c3 int); CREATE TABLE postgres=# create index idx1 on tbl(c1,c2); CR

【Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之RAC 特殊问题和实战经验（五）

RAC 特殊问题和实战经验(五) 共享存储 在需要将一个 LUN (逻辑单元号)映射给多个节点.为集群提供一个共享的存储卷时,同一个存储 LUN 在各个主机端的 LUNID 必须是相同的.比如:  (一) 在为多个 ESX 节点创建一个 VMFS 卷的时候 (二) 在双机 HA 集群创建共享存储的时候 回到顶部 时间一致性 集群模式下,各个节点要协同工作,因此,各主机的时间必须一致.因此,各主机的时间必须一致.各个节点之间的时间差不能超时,一般如果超过 30s,节点很可能会重启,所以要同步各节点

Shopify的Docker实战经验（二）如何用容器支持10万的在线商店

本文讲的是Shopify的Docker实战经验(二)如何用容器支持10万的在线商店,[编者的话]Shopify是一个电子商务平台,提供专业的网上店面.目前的客户超过12万,包括GE.特斯拉汽车.GitHub等.作为首家市值超过10亿美元的加拿大网络公司,Shopify在欧美市场的影响力也与日俱增.Shopify是一个大型的Ruby on Rails应用,其产品服务器能通过给1700个处理核心和6TB RAM分配任务来完成每秒处理8000多个请求.Shopify在其博客上分享了系列内容来介绍他们的

蘑菇预装器实战经验：浅析电脑装机员快速赚钱攻略

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 蘑菇预装器响应大众需求,经过几番更新调整后,功能更加全面,自该软件推出以来,广受大众好评,近日众多网赚高手纷纷云集,争先下载体验蘑菇预装器v1.1版本,根据相关数据统计,近八成蘑菇预装器体验者初战告捷,实战收益显着,近五成以上体验者就目前所赚收益,平均每日装机额可达500元不等. 不管是网赚高手还是电脑装机能手,电脑城装机领域在蘑菇预装器的引

关键词选择和描述实战经验

中介交易 http://www.aliyun.com/zixun/aggregation/6858.html">SEO诊断 淘宝客 云主机 技术大厅 关于关键词选择,说来说去也就是那么多,怎样巧妙利用关键词,长尾词,分析预测热门词,在网络上有很多站长分享他们的心得体会和技巧.作为seo新菜鸟,第一次实战,选择和网站对应的关键词,看起来是很简单,但在实在操作的时候要费一番功夫.下面总结一下这几个月来实战经验: 关键词选择: 1.是否选热门关键词? 一般来说,一个网站如果没有做过关键词优化,在

马帮CEO张洁分享十余年跨境电商实战经验

[编者按]过去,跨境电商是躲着发财,生怕别人来抢蛋糕.如今,他们藏不住了,许多人注意到他们的发展速度--在线进口每年翻倍增长,在线出口每年增长60%以上.日均订单量过万,在出口跨境电商中并不鲜见. 利好的新市场向来欢迎新玩家,过去一两年传统企业不断涌入,海外建仓令品类不断扩展.眼看2014年将成为跨境电商零售出口的转折点,在这个时间点上,是否还给创业者留有白手起家的机会?亿邦动力网与跨境电商资深卖家马帮CEO张洁深度对话,他从采购.管理.平台选择.物流配送等各个角度,分享了自己十余年的实战经验.

专访足记创始人：预测不了风暴

在电影<后会无期>里,王珞丹有过这么一句面无表情的台词:"听过很多道理,却依旧过不好这一生". 将场景换到很多以创业为主题的会议上,放眼望去,你可以看到如同山丘一般的人头攒动,他们有人仰望台上认真学习前辈不吝分享的创业心法,有人低头仔细品读手机里阅读数轻易超过十万的<你不得不关注的十个商业趋势>,对于这些充满热情而又不失机智的年轻面孔,我们可以用同样面无表情的旁白来做出说明:"复制过很多成功经验,却从来没有粘贴成功". 所谓"互联网

交通和个性化推荐实战经验分享

  而在4月20日的云栖大会深圳峰会的<大数据>专场上,数加又有新的迅猛变化,产品体系更加清晰,场景化方案走向个性化,来自企业的实践也已走向深入.   今日的数加:16+产品,3大方案,3种可视化应用   如果从阿里云官网导航栏的"大数据"入口进入,可以看到产品.解决方案.可视化是数加的三大框架体系.具体来看: 产品方面已经拥有16款产品: 开发套件:大数据开发.机器学习.BI报表: 数据应用:推荐引擎.规则引擎标准版.移动定向营销版.移动数据分析: 智能算法:智能语音交互