postgresql模块——pg_stat_statements详解和安装测试

PostgreSQL SQL监控实践
本文详细介绍了如何使用pg_stat_statements模块监控PostgreSQL中的SQL执行情况,包括配置步骤、核心参数解析及实际应用。

其实很简单,最近可能需要对postgresql进行监控,所以接触了很多相关的监控命令和工具,这边文章主要是记录下工作过程,怕之后会忘记。

 

转载注明出处:http://blog.csdn.net/lengzijian/article/details/8133471

 

我想要的功能:记录每条sql的执行时间,能够查询每天执行最慢的top10。


下面先介绍下pg_stat_statements:(翻译)

引文原文地址:http://www.postgresql.org/docs/9.0/interactive/pgstatstatements.html


pg_stat_statements模块提供了一种跟踪执行的所有SQL语句的统计信息的方法。

这个模块必须改写配置文件postgresql.conf中的shared_preload_libraries变量(之后讲解如何配置),这是因为他需要额外的共享内存。同时也意味着需要重启服务。

 

1-先看下pg_stat_statements视图

字段名

类型

引用

说明

userid

oid

pg_authid.oid

执行者id

dbid

oid

pg_database.oid

执行数据库id

query

text

 

执行的语句

calls

bigint

 

执行次数

total_time

double precision

 

执行总时间 (平均值=total_time/calls )

rows

bigint

 

影响的总行数

shared_blks_hit

bigint

 

共享块命中数量

shared_blks_read

bigint

 

共享块读数量

shared_blks_written

bigint

 

共享块写数量

local_blks_hit

bigint

 

本地块命中数量

local_blks_read

bigint

 

本地块读数量

local_blks_written

bigint

 

本地块写数量

如上视图和函数pg_stat_statements_reset只有在数据库已经正确安装,并且已经执行pg_stat_statements.sql脚本后才会生效。只要pg_stat_statements成功添加,就会跟踪服务器上所有的数据库操作。

 

处于安全的原因,普通用户不允许查看其他用户执行的语句信息(query),如果视图安装到他的数据库,那么就可以查看相关的统计信息(子健做的实验实在超级用户下:postgres用户postgres库)

 

注意,如果语句信息(query)一样,不论任何out-of-line变量的值被使用,都会认为这几条声明是相同的。使用out-of-line变量有助于组织语句并且可能回事统计数据更加有用


2­­-函数

pg_stat_statements_reset() returns void

       pg_stat_statements_reset丢弃目前由pg_stat_statements统计的所有信息,默认情况下,这个函数只能运行在超级用户下。

 

3-配置变量

pg_stat_statements.max(integer)

       pg_stat_statements.max是最大追踪的统计数据数量(即,视图中的最大行数)。如果数据量大于最大值,那么执行最少的语句将会被丢弃(本人测试,如果语句执行次数都为1时,其次是时间久的数据被丢弃),这个值默认是1000,这个变量在服务启动前设置

 

pg_stat_statements.track(enum)

        pg_stat_statements.track控制统计数据规则,top用于追踪top-level statement(直接由客户端方发送的),all还会追踪嵌套的statements(例如在函数中调用的statements)

 

pg_stat_statements.track_utility(boolen)

       pg_stat_statements.track_utility控制是否跟踪公共程序命令(utility commands),公共程序命令是SELECT/INSERT/UPDATE/DELETE以外的命令,默认值是开启,只有超级用户可以更改此设置。

 

pg_stat_statements.save(boolean)

       pg_stat_statements.save指定在服务器关闭时,是否保存统计信息。如果设置off,服务关闭时,统计信息将不会保存。默认值是on。这个值只能够在postgresql.conf中或者命令行设置。

 

该模块需要额外的共享内存,内存大小大致为pg_stat_statements.max* track_activity_query_size。要注意的是,一旦模块被加载,即使pg_stat_statements.track设置为none,共享内存都会被消耗。

 

上面的都是一些需要掌握的知识,下面开始真正配置pg_stat_statements并且运行

首先要编写postgresql.conf

#postgresql.conf

#------------------------------------------------------------------------------

# PG_STAT_STATEMENTS OPTIONS

#------------------------------------------------------------------------------

shared_preload_libraries = 'pg_stat_statements'

custom_variable_classes = 'pg_stat_statements'

pg_stat_statements.max = 1000

pg_stat_statements.track = all

4-编译安装pg_stat_statements模块

进入postgresql的源码目录:

cd /home/proxy_pg/postgresql-9.1.3/contrib/pg_stat_statements

make

make install

#如果$pgpath/share/extension目录下存在pg_stat_statements--1.0.sql,说明安装成功了

 

5-加载pg_stat_statements模块

#启动postgresql服务

bin/pg_ctl start -D stat_date/

#加载sql文件

[postgres@slave2 pgsql]$ bin/psql -f share/extension/pg_stat_statements--1.0.sql -p 5499

Use "CREATE EXTENSION pg_stat_statements" to load this file.

#进入数据库做,如下操作

[postgres@slave2 pgsql]$ bin/psql -p 5499

psql (9.1.3)

Type "help" for help.

 

postgres=# create extension pg_stat_statements;         #创建pg_stat_statements

CREATE EXTENSION

postgres=# SELECT pg_stat_statements_reset();          #清空pg_stat_statements(可以不做)

 pg_stat_statements_reset

--------------------------

 

(1 row)

#我们手动插入10条数据:(这里是自己写的脚本,可以通过http://blog.csdn.net/lengzijian/article/details/7729465下载)

./a.out 1 10

#执行如下命令

SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit /nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;


#可以看到最耗时的5条数据,最后一列表示命中率

 

虽然成功了,但这也是监控系统中很小的一部分,接下来我的挑战是把各种监控系统融合在意思,做出可视化界面,使监控更友好。

<think>好的,我现在需要帮助用户深入了解PostgreSQL的BgWriter后台写进程的LRU策略以及pg_stat_bgwriter表的详细信息。用户之前已经得到过相关回答,现在可能希望更详细的信息或者进一步的解释。 首先,回顾之前的对话,用户提问关于BgWriter的LRU策略pg_stat_bgwriter表,系统已经给出了结构化的回答,包括实现机制、参数、优化方法等。现在用户再次询问,可能希望更深入的细节或补充说明。 接下来,用户提供的引用内容中,引用了四个来源,其中引用[2]直接提到了pg_stat_bgwriter视图的结构用途,而其他引用涉及pg_stat_statements模块pg_stat_activity视图等,可能与当前问题关联不大。需要重点参考引用[2]的信息,但也要确保其他引用是否有关联点。 用户的问题分为两部分:LRU策略pg_stat_bgwriter表的作用及字段。需要确保两部分都详细解答。 首先,关于BgWriter的LRU策略,之前回答提到了近似LRU算法、动态写入量计算自适应休眠机制。需要确认是否有更多细节可以补充,比如具体如何记录访问时间戳,环形扫描的工作机制,以及如何与检查点进程协同工作。此外,引用[2]中提到的pg_stat_bgwriter可能包含相关统计信息,可以结合这些统计指标来说明LRU策略的效果。 其次,pg_stat_bgwriter表的作用字段含义。根据引用[2],该视图提供了BgWriter进程的统计信息,如写入的缓冲区数量、后端进程直接写的次数等。需要列出主要字段并逐一解释其含义,同时结合监控优化的实际案例,说明如何利用这些字段进行性能调优。 需要确保回答符合用户提供的格式要求,使用中文,行内公式用$...$,独立公式用$$...$$,结构清晰,分点说明。此外,生成相关问题,帮助用户进一步探索。 检查是否有遗漏的关键点,例如参数调优的具体建议,如何根据pg_stat_bgwriter的数据调整bgwriter_lru_maxpages或bgwriter_delay等参数。同时,可能需要解释不同字段之间的关系,例如buffers_cleanbuffers_backend的比例对性能的影响。 最后,确保引用正确的来源,用户提供的引用[2]是关于pg_stat_bgwriter的,而其他引用可能作为补充,但当前问题主要关注引用[2]之前的回答内容。需要确认引用标识是否正确,如[^2]对应pg_stat_bgwriter的说明。 总结回答结构: 1. BgWriter的LRU策略详细机制 2. pg_stat_bgwriter表的作用字段解释 3. 监控与优化建议 4. 相关问题 需要确保内容准确,参考用户提供的引用之前的回答,避免重复,但提供更深入的信息。</think>#### PostgreSQL BgWriter后台写进程的LRU策略详解 --- ### 一、BgWriter的LRU策略核心机制 BgWriter通过**动态LRU策略**平衡内存脏页写入与查询性能,主要实现逻辑如下: 1. **近似LRU算法** - 每个缓冲区维护最后一次访问时间戳(`usage_count`字段) - 通过**环形缓冲区扫描**(循环遍历共享缓冲区池)选择候选页 - 优先淘汰**最近未被访问的脏页**,写入磁盘后释放缓冲区[^2] 2. **写入量动态调整** 每次写入的页数由公式控制: $$ \text{写入量} = \min\left(\text{bgwriter\_lru\_maxpages},\ \text{avg\_required} \times \text{bgwriter\_lru\_multiplier}\right) $$ 其中: - `avg_required`: 最近服务器进程请求新缓冲区的平均值 - `bgwriter_lru_multiplier`: 动态调整写入强度的乘数因子(默认2.0) 3. **自适应休眠机制** - **无脏页时**:自动延长休眠间隔(超过`bgwriter_delay`设定值) - **存在脏页时**:严格按`bgwriter_delay`(默认200ms)周期性唤醒[^2] --- ### 二、`pg_stat_bgwriter`视图详解 #### 1. 核心作用 提供BgWriter进程的**实时运行统计**,用于监控内存管理与I/O负载平衡,主要指标包括: - 后台写入的脏页数量 - 后端进程被迫自行写入的次数 - 检查点协同效率 #### 2. 关键字段说明 | 字段名称 | 数据类型 | 描述 | |------------------------|----------|----------------------------------------------------------------------| | `buffers_alloc` | bigint | **新缓冲区分配次数**,反映共享缓冲区的使用压力 | | `buffers_backend` | bigint | **后端进程自行写入的缓冲区数**,值高表明BgWriter未能及时清理脏页[^2] | | `buffers_clean` | bigint | BgWriter主动清理的缓冲区数量 | | `maxwritten_clean` | bigint | **因达到`bgwriter_lru_maxpages`限制而提前终止扫描的次数** | | `buffers_checkpoint` | bigint | 检查点触发的缓冲区写入数量 | | `checkpoints_timed` | bigint | 计划内检查点(基于`checkpoint_timeout`)触发次数 | | `checkpoints_req` | bigint | 因WAL日志量触发的非计划检查点次数 | --- ### 三、监控与优化实践 #### 1. 关键指标分析 ```sql -- 查看BgWriter工作状态 SELECT buffers_clean, buffers_backend, maxwritten_clean FROM pg_stat_bgwriter; ``` - **健康状态判断**: - `buffers_backend / buffers_clean < 0.3`:BgWriter工作正常 - `maxwritten_clean`频繁增长:需增大`bgwriter_lru_maxpages` #### 2. 参数调优建议 - **高并发写入场景**: ```sql ALTER SYSTEM SET bgwriter_lru_maxpages = 300; -- 增大单次写入上限 ALTER SYSTEM SET bgwriter_delay = '100ms'; -- 缩短唤醒间隔 ``` - **混合负载场景**: 调整`bgwriter_lru_multiplier`(推荐1.5-2.5),避免过度预写 #### 3. 与检查点协同 - 通过`checkpoint_completion_target`(默认0.5)控制检查点写入节奏 - 确保BgWriter在检查点间隔期间完成**至少80%的脏页写入** --- ### 四、特殊场景处理 1. **SSD存储优化** - 降低`bgwriter_lru_multiplier`至1.0-1.2 - 允许更密集的小批量写入(利用SSD低延迟特性) 2. **长事务影响** - 旧版本数据会阻塞BgWriter清理 - 需配合优化`autovacuum`参数事务提交频率 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值