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

最新推荐文章于 2024-09-25 20:42:12 发布

iteye_6033

最新推荐文章于 2024-09-25 20:42:12 发布

阅读量530

点赞数

CC 4.0 BY-SA版权

分类专栏：数据库内核，pgsql 文章标签：数据库 c/c++ 数据结构与算法

本文链接：https://blog.youkuaiyun.com/iteye_6033/article/details/82642379

数据库内核，pgsql 专栏收录该内容

4 篇文章

订阅专栏

前面讲了如何从外部来观察checkpoint，但是，实际上checkpoint内部是如何运行的呢？这里就有必要讲讲来龙去脉了。

目前，PG中有一个单独的checkpoint的进程。一般来说，在正常的启动过程中，这个进程是postmaster进程生成的，实际上是一个信号的处理函数heaper（）生成的，具体的调用关系如下：

main()->postmastermain()->reaper()->StartCheckpointer()->StartChildProcess()->AuxiliaryProcessMain()->CheckpointerMain()

postmaster中触发heaper（）的是一个子进程退出的信号，这个子进程的名字是startup process，具体这个进程干啥了大家可以去看看代码。

CheckpointerMain()就是checkpoint进程的主体了。CheckpointerMain()主要分两部分：完成一些必要的初始化工作，之后就进入一个不断做checkpoint的死循环中。

初始化包括三部分的内容：一，在CheckpointerShmem这个所有进程都可以访问的变量中设置checkpoint进程的PID，这个PID回头是其他进程通过kill函数来通知做checkpoint的必要参数；设置信号处理函数，其中一个信号处理函数是负责接收SIGINT信号来表示需要做checkpoint了；三，设置long jump的异常堆栈，使得出现ERROR时能跳转回来进行一场处理（也就是用C来简单实现了C++中异常捕获和处理）。

在这个进程的死循环中，这个死循环的伪码如下：

for(;;){
     AbsorbFsyncRequests() // 整理fsync的请求
     if (got_SIGHUP)
     { 
         //用户执行了realod命令，重新加载配置问题
         ProcessConfigFile(PGC_SIGHUP);
         UpdateSharedMemoryConfig();
     }
     if (checkpoint_requested)
     {
         //接到信号，需要执行检查点
         checkpoint_requested = false;
         BgWriterStats.m_requested_checkpoints++;
         do_checkpoint = true;
     }
     if (shutdown_requested)
     {
        // 进程接到数据库退出的信号，退出
        ShutdownXLOG(0, 0);
        proc_exit(0);	
     }
     if (elapsed_secs >= CheckPointTimeout)
     {
           // 如果距离上次检查点发生的时间间隔大于checkpoint_timeout，则需要执行周期的checkpoint
           if (!do_checkpoint)
		BgWriterStats.m_timed_checkpoints++;
	   do_checkpoint = true;
	   flags |= CHECKPOINT_CAUSE_TIME;
     }
     if(do_checkpoint)
     {
          CreateCheckPoint(flags);//做检查点
          smgrcloseall() ;// 关闭所有的segments
     }
     CheckArchiveTimeout() //检查归档的timeout，切换WAL文件
     pgstat_send_bgwriter();//向pg_stat进程发生本次checkpoint的统计信息
　　 elapsed_secs = now - last_checkpoint_time;
     if (elapsed_secs >= CheckPointTimeout)//如果做检查点花费时间大于周期
         continue;
　　 elapsed_secs = now - last_xlog_switch_time;
　　 if (elapsed_secs >= XLogArchiveTimeout) // 如果大于归档的timeout
　　     continue;	
    WaitLatch（）//睡眠，直至超时或是信号发生
}

可以看到，能够影响发生做checkpoint基本上就两个原因：被其他进程要求执行（上一篇博客提到过），在一个就是超时了。

而在这个循环中，有三个比较重要的函数：AbsorbFsyncRequests()，pgstat_send_bgwriter();和CreateCheckPoint(flags)。

AbsorbFsyncRequests()主要将CheckpointerShmem这个全局变量中fsync请求都拷贝过来，这些请求主要存在于CheckpointerShmem的requests字段中，这个字段是一个变长数组，长度就是block的块数。当bgwriter或是backend将一个block写回（write）物理文件后，会将对该文件的sync请求放入CheckpointerShmem的requests中。拷贝fsync请求之后，然后根据将每个请求塞入哈希表pendingOpsTable中，key就是由物理文件的rnode，将segno加入每个fork对应的位图中。简单来说，就是如果同一个segment上多个block需要fsync那么这些fsync会合并成对一个segment的fsync请求。所以这样就大大消除了fysnc的请求。这样的好处是，不到做检查点，pg是不会去主动fsync被写脏的segment的，只有到了检查点，才会主动去fsync。而在未发生checkpoint的这段时间内，操作系统会根据参数在后台fsync文件，这个需要配置dirty_ratio和dirty_background_ratio来控制OS后台fsync文件。

而并不是只有checkpoint进程才会将写回的segment调用fsync的，backend进程也会调用，只不过是在系统压力很大的情况下才会发生：如果CheckpointerShmem的requests这个数组被塞满了，并且在将同一个segment的fysnc请求合并成一个之后，发现CheckpointerShmem的requests这个数组依然还是塞满了，那就说明系统需要fsync的segment的数量和share buffer中block的数量是一样的，这意味着什么呢？假设一个服务器给PG的share buffer是20G，那么出现这种情形，需要fsync回磁盘的数据超过 (20G/8K) *32M = 80T，如果真的发生了，说明系统的压力已经超出了硬件的承受能力了。

当然 bgwriter也存在调用fsync数据块的可能，只不过这种可能性比前面说的这种可能性还要低好多，所以可以忽略。

而pgstat_send_bgwriter()函数则是将每个checkpoint的统计信息发给pg_stat进程，统计信息存在如下的一个结构中：

typedef struct PgStat_MsgBgWriter
{
	PgStat_MsgHdr m_hdr;
	PgStat_Counter m_timed_checkpoints; //定期检查点次数
	PgStat_Counter m_requested_checkpoints; //请求执行的检查点次数
	PgStat_Counter m_buf_written_checkpoints; //检查点刷了多少脏block
	PgStat_Counter m_buf_written_clean;        //bgwriter刷了多少脏block
	PgStat_Counter m_maxwritten_clean;     //bgwriter刷脏块超过bgwriter_lru_maxpages的次数
	PgStat_Counter m_buf_written_backend; //backend刷回的脏块
	PgStat_Counter m_buf_fsync_backend;  //backend fsync的次数
	PgStat_Counter m_buf_alloc;                 // 重新分配的块数
	PgStat_Counter m_checkpoint_write_time;//检查点写文件花的时间
	PgStat_Counter m_checkpoint_sync_time; //检查点fsync文件花的时间
} PgStat_MsgBgWriter;

这个数据结构基本上就对应我们前面说的pg_stat_bgwriter这个系统视图。checkpoint进程每次发生的统计信息只包括于本进程以及backend进程相关的信息：m_timed_checkpoints，m_requested_checkpoints，m_buf_written_checkpoints，m_buf_written_backend，m_buf_fsync_backend m_checkpoint_write_time，m_checkpoint_sync_time。

而m_buf_fsync_backend这个字段的值大于0，就说明前面说backend调用fsync的极端情况出现了，您该跟boss打报告研究下对策了。

对于CreateCheckPoint(flags)这个函数，无疑是checkpoint进程的核心，下一篇将为您讲述。