说说pg中的检查点(checkpoint)之一

最近一直在使用pgbench对pg进行压测,在压测的过程中,发现checkpoint的发生会对数据库的性能产生极大的影响.

想看到最近有没有发生checkpoint,有两种比较简单的方式:

一个是不停的刷新pg_stat_bgwriter这个视图,这个视图中两个字段checkpoints_timed和checkpoints_req直接反映了PG已经发生或是正在发生的checkpoint次数,如果这两个字段的值发生了变化,就说明发生了checkpoint。如果凑巧正在做checkpoint,可以查询这个视图的另外的一个字段buffers_checkpoint,这个字段表明了checkpoint进程刷回了多少个脏的block回磁盘,在做checkpoint的过程中这个字段的结果将会不断累积。在PG的checkpoint进程内部的实现中,如果要做checkpoint,会首先将checkpoints_timed或是checkpoints_req字段关联的统计值加一,然后再来把脏块挨个写回(write)磁盘,每写一个就把相关的统计值加1。一般来说,如果checkpoint_segments设置得足够大(例如128个)并且脏数据块很多,那么在一次做checkpoint的过程可以持续100多秒都是可能的,因此是可以看到buffers_checkpoint这个字段在不断增加的。

另外一个就是在postgresql.conf中打开log_checkpoints配置项,然后查看日志文件。在checkpoint开始时,会在日志文件中打印一行说checkpoint开始了,然后结束之后也会将本次checkpoint的统计信息打印出来,例如:

Bash代码

1. LOG:  checkpoint starting: time

2. LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.000 s

3. , total=0.011 s; sync files=0, longest=0.000 s, average=0.000 s

注意这段日志里面第一行提到了是因为到点了(time)才做的checkpoint。

前面提到的pg_stat_bgwriter视图中两个字段checkpoints_timed和checkpoints_req,在官方的英文文档中说得有些过于简洁,而被翻译成中文之后,结果有些晦涩。对于checkpoints_timed的解释,中文翻译过来是定期执行的检查点数这个基本上是对的,而对于checkpoints_req,英文文档是:Number of requested checkpoints that have been performed。应该是执行被请求的检查点数。至于被谁、在什么情况下请求的?都没有说明。

对于checkpoints_timed统计的检查点,很容易理解,就是在过了checkpoint_timeout这个配置项指定的时间之后执行的检查点,这个实际上是checkpoint进程主动发起的检查点。他在日志中输出就是上面日志的内容。

而对于checkpoints_req统计的检查点,实际上可以分为三种:一种是写的WAL距离上次的checkpoint位置已经超过了checkpoint_segments个WAL,那么这个时候需要做一个检查点了;另外一种就是做了比较重量的DML,例如创建了一个database,或是删除了一个database,或是修改了tablespace;最后一种就是用户直接通过SQL执行checkpoint这个命令而触发的检查点。

checkpoints_req统计的检查点实际上就是checkpoint进程被动执行的。如何来触发checkpoint进程来执行这些检查点呢?很简单:我们知道PG是个多进程的程序,checkpoint的进程信息(包括进程ID)存在了共享内存的hash表中的,是通过名字可以查到的,那么可以获得checkpoint进程的ID、直接通过kill调用来发生某个特定的信号来告诉checkpoint进程需要执行检查点了。实际上也是这样实现的,大家可以看具体的源码。

那么有个问题:如果过了checkpoint_timeout并且也接到了其他进程做checkpoint的请求了,那么该把谁加一呢?实际代码中是把checkpoints_req加一的。

另外:PG中发生的checkpoint是否都会被checkpoints_timed和checkpoints_req统计呢?答案是否定的:在PG启动的过程中,postmaster做完了恢复会做一个checkpoint,这个时候还没有其他进程,参见StartupXLOG函数;另外,当PG退出时,checkpoint进程会做一个检查点,这个检查点也是不被统计的。但是,如果打开了log_checkpoints配置项,这两种情况都是会被记录下来的。

时间: 2024-10-23 19:11:38

说说pg中的检查点(checkpoint)之一的相关文章

如何用好LoadRunner中的检查点

如何用好LoadRunner中的检查点转自:领测软件测试网[http://www.ltesting.net] 原文链接:http://www.ltesting.net/ceshi/ceshijishu/rjcsgj/mercury/loadrunner/2012/0120/203946.html 如何用好LoadRunner中的检查点LR中检查点有两种:图片和文字. 常用检查点函数如下: 1)web_find()函数用于从 HTML 页中搜索指定的文本字符串; 2)web_reg_find()函

spark streaming 中使用saveAsNewAPIHadoopDataset方法写入hbase中,从checkpoint中恢复时报错

问题描述 最近写了一个从Kafka读取数据,处理之后通过saveAsNewAPIHadoopDataset方法写入到hbase中,正常运行的时候没有报错,写入也正常,但是当手动停止应用,再次执行(通过Checkpoint恢复)的时候就会报错,跪求大神们解答!!报错信息如下:15/12/2216:26:52WARNVerifiableProperties:Propertyserializer.classisnotvalid15/12/2216:26:57WARNFileOutputCommitte

PgSQL · 源码分析 · PG中的无锁算法和原子操作应用一则

原子操作概述 近年来随着服务器上CPU核数的不断增加,无锁算法(Lock Free)越来越广泛的被应用于高并发的系统中.PostgreSQL 做为世界上最高级开源数据库也在9.5时引入了无锁算法.本文先介绍了无锁算法和原子操作在PostgreSQL中的具体实现, 再通过一个Patch来看一下在PostgreSQL中是如何利用它来解决实际的高并发问题的. 无锁算法是利用CPU的原子操作实现的数据结构和算法来解决原来只能用锁才能解决的并发控制问题. 众所周知,在一个并发系统中特别是高并发的场景下,锁

实例恢复(Instance Recovery)之前滚(Rolling Forward)和回滚(Rolling Back)

Oracle实例恢复(Instance Recovery)之前滚(Rolling Forward)和回滚(Rolling Back)     关于oracle实例恢复的一些理解,一直都有误区,今天通过查看相关资料和与同学探讨,发觉了自己的错误,探讨结果如下:       实例恢复:当数据库非正常关闭的时候(断电或者shu  abort等等非一致性关闭),当你从新启动数据库的时候,数据库相关进程自动进行实例恢复,无须人工干预,        一. 什么时候需要实例恢复     在shutdown 

oracle 检查点(checkpoint)

以下内容整理自网路,如有侵权,请联系我. checkpoint扫盲 什么是checkpoint 在数据库系统中,写日志和写数据文件是数据库中IO消耗最大的两种操作,在这两种操作中写数据文件属于分散写,写日志文件是顺序写,因此为了保证数据库的性能,通常数据库都是保证在提交(commit)完成之前要先保证日志都被写入到日志文件中,而脏数据块着保存在数据缓存(buffer cache)中再不定期的分批写入到数据文件中.也就是说日志写入和提交操作是同步的,而数据写入和提交操作是不同步的.这样就存在一个问

【Spark Summit EU 2016】Spark中的自动检查点

本讲义出自Nimbus Goehausen在Spark Summit EU 2016上的演讲,主要介绍了面对需要自动保证Spark的数据来源以及存储路径正确,并且在对于需要保存的数据进行保存而对于需要改变的数据进行改变,所以需要在Spark工作流中使用自动检查点来对以上要求进行保障,本讲义就主要介绍了Spark中自动检查点的设计动机.工作原理以及使用方法.

通过设置 CheckPoints 检查点来增强 SSIS Package 流程的重用性

通常一个 ETL Package 是由多个控制流和数据流共同组成,有的时候 ETL 的步骤可能会比较多,整个流程执行下来的时间可能比较长.假设在 ETL Package 中包含5个Task,前3个Task执行超过1个小时,到了第4个Task的时候发生失败.如果下次执行的时候重新从第1个任务开始执行,那么又要花费1个小时等待 1-3 任务执行,无疑在效率上讲是非常低的.特别是在数据仓库的应用上,往往从数据源到Staging的过程中有千万级甚至亿级的数据要加载,加载完毕之后再进入到维度和事实表.如果

SSIS:通过设置 CheckPoints 检查点来增强 SSIS Package 流程的重用性

通常一个 ETL Package 是由多个控制流和数据流共同组成,有的时候 ETL 的步骤可能会比较多,整 个流程执行下来的时间可能比较长.假设在 ETL Package 中包含5个Task,前3个Task执行超过1个小时 ,到了第4个Task的时候发生失败.如果下次执行的时候重新从第1个任务开始执行,那么又要花费1个小 时等待 1-3 任务执行,无疑在效率上讲是非常低的.特别是在数据仓库的应用上,往往从数据源到 Staging的过程中有千万级甚至亿级的数据要加载,加载完毕之后再进入到维度和事实

关于oracle检查点及SCN的深入研究

一.检查点概述 大多数关系型数据库都采用"在提交时并不强迫针对数据块的修改完成"而是"提交时保证修改记录(以重做日志的形式)写入日志文件"的机制,来获得性能的优势.这句话的另外一种描述是:当用户提交事务,写数据文件是"异步"的,写日志文件是"同步"的.这就可能导致数据库实例崩溃时,内存中的DB_Buffer中的修改过的数据,可能没有写入到数据块中.数据库在重新打开时,需要进行恢复,来恢复DB Buffer中的数据状态,并确保已