为什么要开启autovaccum

在Postgresql做delete操作时，数据集(也叫做元组 (tuples))是没有立即从数据文件中移除的，仅仅是通过在行头部设置xmax做一个删除标记。

update操作也是一样的，在postgresql中可以看作是先delete再insert;

这是Postgresql MVCC的基本思想之一，因为它允许在不同进程之间只进行最小的锁定就可以实现更大的并发性。这个MVCC实现的缺点当然是它会留下被标记删除的 元组（ dead tuples），即使在这些版本的所有事务完成之后。

如果不清理掉那些dead tuples（对任何事务都是不可见的）将会永远留在数据文件中，浪费磁盘空间，对于表来说，有过多的删除和更新，dead tuples很容易占绝大部分磁盘空间。而且dead tuples也会在索引中存在，更加加重磁盘空间的浪费。这是在PostgreSQL中常说的膨胀（bloat）。

数据库臃肿是数据库服务器性能不佳的主要原因之一，dead tuples数据过多，造成表相关update/deletion操作性能下降，同时查询也会变慢。如果过于频繁会造成cpu和磁盘读写的繁忙，同样会造成性能问题。

autovacuum自动清理机制

autovacuum是postgresql数据库是一个后台进程，在默认配置下，随数据库自启动。自动清理会检查被大量插入、更新或删除元组的表。是一个非常频繁的操作。

autovacuum的作用

1、清理表中的过期死元组
2、防止业务表膨胀
3、更新表的统计信息以供优化器使用
4、autovacuum launcher使用stats collector后台进程收集统计信息来确定autovacuum候选列表

autovacuum功能

autovacuum会做两件事件：一是vacuum，二是analyze。

自动清理vaccum

1.功能

清理过程相当简单,它从数据文件中读取页面(默认8kB数据块),并检查它是否需要清理.如果没有死元组,页面就会被丢弃而不做任何更改.否则它被清理(死元组被删除)

2.清理比较值

更新或删除的元组数。
失效元组的数量从统计信息收集器获得，它是一个半准确的计数（它只是半准确，是因为在高负载的情况下某些信息可能会丢失）。

3.死亡元组数查询

select relid,schemaname,relname,n_dead_tup from pg_stat_user_tables;

4.触发条件

清理阈值 = 清理基本阈值 + 清理缩放系数 * 元组数

5.配置参数

①　清理基本阈值：autovacuum_vacuum_threshold，默认值为50
②　清理缩放系数：autovacuum_vacuum_scale_factor，默认值0.2

自动分析analyze

1.功能

更新查询计划器使用的统计信息以选择或选择执行查询的最有效计划。
ANALYZE的效率稍差,因为VACUUM的成本与死元组的数量成正比(当很少/没有时成本比较低),ANALYZE必须在每次执行时从头开始重建统计数据。
Analyze只需要获取一个read锁，不会影响表的正常读写。

2.分析比较值

自从上次ANALYZE以来插入、更新或删除的行数

3.改变行数查询

select relid,schemaname,relname,n_mod_since_analyze from pg_stat_user_tables;

4.触发条件

分析阈值 = 分析基本阈值 + 分析缩放系数 * 元组数

5.配置参数

①　分析基本阈值：autovacuum_analyze_threshold，默认值为50
②　分析缩放系数：autovacuum_analyze_scale_factor，默认值0.1

autovacuum配置参数调整

默认的比例因子适用于中小型表,但对于非常大的表则没有那么多(在10GB表上,这大约是2GB的死元组,而在1TB表上则是~200GB)

这是一个累积大量死元组并立即处理所有这些元素的例子,这将会严重影响数据库性能.根据前面提到的规则。

大表的自动清理参数设定方案

调低vacuum触发阈值，积极触发vacuum机制
1.降低比例因子
如：autovacuum_vacuum_scale_factor = 0.01
这将限制表中的数据变化达到1%时触发autovacuum

2.整体完全放弃比例因子,并仅使用阈值(建议使用)
如：
autovacuum_vacuum_scale_factor = 0
autovacuum_vacuum_threshold = 10000

这将生成10000个死元组后触发清理.

单个表设置比例因子或阈值

注意：该设定方式，请三思而后行。它会让你的系统变得更复杂也更难检查

1．修改已经存在的表

根据实际情况决定是否设置

ALTER TABLE t set with (fillfactor=80,
        autovacuum_enabled=true,toast.autovacuum_enabled=true,
        autovacuum_vacuum_threshold=100,autovacuum_analyze_threshold=200,
autovacuum_analyze_scale_factor = 0,
        toast.autovacuum_vacuum_threshold=100);

注意：如果是用ALTER TABLE设置的存储参数,设置好后并不会生效,需要重新vacuum full表后才会生效.

2．新建表

create table test(
    objectid bigserial not null
) with (fillfactor=80,
        autovacuum_enabled=true,toast.autovacuum_enabled=true,
        autovacuum_vacuum_threshold=100,autovacuum_analyze_threshold=200,
        toast.autovacuum_vacuum_threshold=100);

3．参数说明

①　fillfactor 页填充率,根据update和delete的发生程度设置.对于已经存在的表修改了这个参数是无效的,必须对重新vacuum full表后才会生效。功能：让每个数据块预留一定的空间用于记录的更新，也可以提升update的效率。缺点：Insert效率有所降低，同时加大磁盘开销。
②　autovacuum_vacuum_threshold 当update和delete多少行数据开始autovacuum vacuum。注意如果没有发生update和delete vacuum会自动跳过。
③　autovacuum_analyze_threshold 当insert、update和delete多少行数据开始autovacuum analyze。注意因为analyze都会从头开始执行，因此需要估算好。

④   PostgreSQL采用TOAST技术来存储大字段的值，TOAST针对大字段的值通常被压缩或切片成多个物理行存储在系统表TOAST表中，也就是行外存储。
TOAST只支持特定的数据类型，因为对于小字段（整型、浮点数、时间等）是没有必要使用TOAST的。TOAST只支持变长的数据类型，在变长类型中，前4个字节（32bit）称为长度字，前2bit是标志位，一个表示是否压缩，一个表示是否行外存储；剩下的30bit表示数据的实际尺寸；长度字后面存储的是具体的内容或指针。
  如果一个表中有任何字段是可以TOAST的，则PostgreSQL会自动为该表建一个相关联的TOAST表，其中OID存储在表的pg_class.reltoastrelid记录里，行外的内容保存在TOAST表里。自动清理会清理toast表，自动分析不涉及到toast表

自动清理限流设定

默认值

autovacuum_vacuum_cost_delay = 20ms
autovacuum_vacuum_cost_limit = 200

说明：

通过限制一次性完成的工作量(默认设置为200)来实现限流，每次清理工作完成这么多工作(计数达到autovacuum_vacuum_cost_limit )，它就会休眠20毫秒:

使用20ms延迟，清理工作每秒可以执行50轮，每轮200意味着每秒10000。这意味着:
每秒从share_buffer读80M（假设不脏）。
每秒从操作系统读8M（也可能来自磁盘）。
每秒写4M（被autovacuum进程弄脏的页）。
考虑到当前硬件的能力，读/写大多是连续的，这些限制太低了。

将cost_limit参数增加到1000(或2000)，这将使吞吐量增加5倍(或10倍)，即
autovacuum_vacuum_cost_limit = 2000
将cost_limit参数增加到1000(或2000)，这将使吞吐量增加5倍(或10倍)。

注意：依据于硬件能力来决定设定值，硬件能力不确定时，最好不要调整

调整postgresql 其他参数，更有效调整数据库性能

1.shared_buffers

PostgreSQL既使用自身的缓冲区，也使用内核缓冲IO。这意味着数据会在内存中存储两次，首先是存入PostgreSQL缓冲区，然后是内核缓冲区。这被称为双重缓冲区处理。对大多数操作系统来说，这个参数是最有效的用于调优的参数。此参数的作用是设置PostgreSQL中用于缓存的专用内存量。
shared_buffers的默认值设置得非常低，因为某些机器和操作系统不支持使用更高的值。但在大多数现代设备中，通常需要增大此参数的值才能获得最佳性能。
建议的设置值为机器总内存大小的25％，但是也可以根据实际情况尝试设置更低和更高的值。实际值取决于机器的具体配置和工作的数据量大小。举个例子，如果工作数据集可以很容易地放入内存中，那么可以增加shared_buffers的值来包含整个数据库，以便整个工作数据集可以保留在缓存中。
在生产环境中，将shared_buffers设置为较大的值通常可以提供非常好的性能，但应当时刻注意找到平衡点。

2.wal_buffers

PostgreSQL将其WAL（预写日志）记录写入缓冲区，然后将这些缓冲区刷新到磁盘。由wal_buffers定义的缓冲区的默认大小为16MB，但如果有大量并发连接的话，则设置为一个较高的值可以提供更好的性能。

autovacuum所有参数查询sql

select name,setting,short_desc  from pg_settings where name like 'autovacuum%';

查询表的死亡元组数和改变的行数

select 
relid,
schemaname,
relname,
n_dead_tup,
n_mod_since_analyze,
 last_autovacuum,
last_autoanalyze
from pg_stat_user_tables;

autovaccum配置参数

1.vacuum_cost_delay (integer)

进程超过代价限制后将休眠的时间长度，以毫秒计。其默认值为0，这将禁用基于代价的清理延迟特性。正值将启用基于代价的清理。注意在很多系统上，实际的休眠延迟单位是10毫秒，将vacuum_cost_delay设置成不为10的倍数的值和将它设置为比该值大的10的倍数的效果相同。
在使用基于代价的清理时，vacuum_cost_delay的合适值通常很小，也许是10或20毫秒。调整清理时资源消耗最好的方法是调整其他清理代价参数。

2.vacuum_cost_page_hit (integer)

清理一个在共享缓存中找到的缓冲区的估计代价。它表示锁住缓冲池、查找共享哈希表和扫描页内容的代价。默认值为1。

3.vacuum_cost_page_miss (integer)

清理一个必须从磁盘上读取的缓冲区的代价。它表示锁住缓冲池、查找共享哈希表、从磁盘读取需要的块以及扫描其内容的代价。默认值为10。

4.vacuum_cost_page_dirty (integer)

当清理修改一个之前干净的块时需要花费的估计代价。它表示再次把脏块刷出到磁盘所需要的额外I/O。默认值为20。

5.vacuum_cost_limit (integer)

将导致清理进程休眠的累计代价。默认值为200。
注意: 有些操作会保持关键性的锁，这样可以尽快完成。基于代价的清理延迟在这类操作期间不会发生。因此有可能代价会累计至大大超过指定的限制。为了防止在这种情况下的无意义的长时间延迟，实际延迟的计算方式是vacuum_cost_delay * accumulated_balance / vacuum_cost_limit，且最大值是vacuum_cost_delay * 4。

6.log_autovacuum_min_duration (integer)

如果自动清理运行至少该值所指定的毫秒数，被自动清理执行的每一个动作都会被日志记录。将该参数设置为0会记录所有的自动清理动作。-1（默认值）将禁用对自动清理动作的记录。例如，如果你将它设置为250ms，则所有运行250ms或更长时间的自动清理和分析将被记录。此外，当该参数被设置为除-1外的任何值时，如果一个自动清理动作由于存在一个锁冲突而被跳过，将会为此记录一个消息。开启这个参数对于追踪自动清理活动非常有用。该设置只能在postgresql.conf文件或者服务器命令行上设置。 但是可以通过为单表修改表存储参数重写这个设置。

7.autovacuum_max_workers (integer)

指定能同时运行的自动清理进程（除了自动清理启动器之外）的最大数量。默认值为3。该参数只能在服务器启动时设置。尽量不要修改

8.autovacuum_naptime (integer)

指定自动清理在任意给定数据库上运行的最小延迟。在每一轮中后台进程检查数据库并根据需要为数据库中的表发出VACUUM和ANALYZE命令。延迟以秒计，且默认值为1分钟（1min）。该参数只能在postgresql.conf文件或在服务器命令行上设置。应该根据数据库的单位时间更新量来决定该值，一般来说单位时间的更新量越大该时间间隔应该设置越短。由于自动清理对系统的开销较大，该值应该谨慎配置（不要过小）。

9.autovacuum_vacuum_threshold (integer)

指定能在一个表上触发VACUUM的被插入、被更新或被删除元组的最小数量。默认值为50个元组。该参数只能在postgresql.conf文件或在服务器命令中设置。对个别表可以通过修改存储参数来覆盖该设置。

10.autovacuum_analyze_threshold (integer)

指定能在一个表上触发ANALYZE的被插入、被更新或被删除元组的最小数量。默认值为50个元组。该参数只能在postgresql.conf文件或在服务器命令中设置。对个别表可以通过修改存储参数来覆盖该设置。

11.autovacuum_vacuum_scale_factor (floating point)

指定一个表尺寸的分数，在决定是否触发VACUUM时将它加到autovacuum_vacuum_threshold上。默认值为0.2（表尺寸的20%）。该参数只能在postgresql.conf文件或在服务器命令中设置。对个别表可以通过修改存储参数来覆盖该设置。

12.autovacuum_analyze_scale_factor (floating point)

指定一个表尺寸的分数，在决定是否触发ANALYZE时将它加到autovacuum_analyze_threshold上。默认值为0.1（表尺寸的10%）。该参数只能在postgresql.conf文件或在服务器命令中设置。对个别表可以通过修改存储参数来覆盖该设置。

13.autovacuum_freeze_max_age (integer)

指定在一个VACUUM操作被强制执行来防止表中事务ID回卷之前，一个表的pg_class.relfrozenxid域能保持的最大年龄（事务的）。注意即便自动清理被禁用，系统也将发起自动清理进程来阻止回卷。
清理也允许从pg_clog子目录中移除旧文件，这也是为什么默认值被设置为较低的2亿事务。该参数只能在服务器启动时设置，但是对于个别表可以通过修改存储参数来降低该设置。

14.autovacuum_vacuum_cost_delay (integer)

指定用于自动VACUUM操作中的代价延迟值。如果指定-1（默认值），则使用vacuum_cost_delay值。默认值为20毫秒。该参数只能在postgresql.conf文件或在服务器命令中设置。对个别表可以通过修改存储参数来覆盖该设置。

15.autovacuum_vacuum_cost_limit (integer)

指定用于自动VACUUM操作中的代价限制值。如果指定-1（默认值），则使用vacuum_cost_limit值。注意该值被按比例地分配到运行中的自动清理工作者上（如果有多个），因此每一个工作者的限制值之和绝不会超过这个变量中的限制值。该参数只能在postgresql.conf文件或在服务器命令中设置。对个别表可以通过修改存储参数来覆盖该设置。

postgresql autovaccum自动清理相关推荐

  1. PostgreSQL归档配置及自动清理归档日志

    PostgreSQL归档配置及自动清理归档日志 在生产环境中,数据库都需要开启归档模式,那么PG该如何开始归档呢? PG中归档配置涉及几个参数: # - Archiving - #是否开启归档 #ar ...

  2. pg 定时删除_postgresql AutoVacuum系统自动清理进程

    2.5.5  AutoVacuum系统自动清理进程 在PostgreSQL数据库中,对表元组的UPDATE或DELETE操作并未立即删除旧版本的数据,表中的旧元组只是被标识为删除状态,并未立即释放空间 ...

  3. zookeeper3.4.6配置实现自动清理日志

    在使用zookeeper过程中,我们知道,会有dataDir和dataLogDir两个目录,分别用于snapshot和事务日志的输出(默认情况下只有dataDir目录,snapshot和事务日志都保存 ...

  4. linux centos7 /tmp目录 自动清理规则

    CentOS7下,系统使用systemd管理易变与临时文件,与之相关的系统服务有3个: systemd-tmpfiles-setup.service :Create Volatile Files an ...

  5. centos7 tmp目录 自动清理规则

    CentOS6以下系统(含)使用watchtmp + cron来实现定时清理临时文件的效果,这点在CentOS7发生了变化,在CentOS7下,系统使用systemd管理易变与临时文件,与之相关的系统 ...

  6. python 技术篇-logging模块的日志定期清理设置，自动清理上个月的日志实例演示

    先说一下我设置的清理日志原理: 每天都建立一个新的日志文件来存储日志,每次启用程序时检查日志目录里的所有日志文件,自动清理上个月之前的日志. 如图,我把日期存在当天日志的名字里. 然后遍历目录下所有的 ...

  7. linux生成日志文件,linux实现按天生成日志文件并自动清理

    linux实现按天生成日志文件并自动清理 前篇文章中讲到如何在Linux crontab创建每秒执行的方法,高人可能早意识到日志文件没做处理,假如没人工处理久了日后越来越大肯定会出现问题,当然人工处理 ...

  8. zookeeper3.4.5自动清理日志

    2019独角兽企业重金招聘Python工程师标准>>> 从3.4.0开始,zookeeper提供了自动清理snapshot和事务日志的功能, 通过配置 autopurge.snapR ...

  9. CentOS7的/tmp目录自动清理规则（转）

    CentOS7的/tmp目录自动清理规则 CentOS6以下系统(含)使用watchtmp + cron来实现定时清理临时文件的效果,这点在CentOS7发生了变化,在CentOS7下,系统使用sys ...

最新文章

  1. C++对象模型5——类对象的内存布局
  2. JavaScript字符串的单引号和双引号问题
  3. byte数组和正数BigInteger之间的相互转换
  4. 并发编程-13线程安全策略之两种类型的同步容器
  5. [渝粤教育] 广东-国家-开放大学 21秋期末考试Java程序设计基础10232k2
  6. 无限复活服务器,绝地求生无限复活模式怎么玩 无限复活新手教程
  7. mysql改原始密码mac_MAC版修改MySQL初始密码的方法
  8. 神啊，6小时30分钟，完成想要的所有Lync测试
  9. 如何用轻量级RTSP服务本地生成RTSP测试URL
  10. 风糜全球、年销128亿！著名品牌好丽友突陷“双标”争议！
  11. 力扣90. 子集 II（JavaScript）
  12. 设置居中_安卓手机时间怎么显示在中间 时间居中设置教程
  13. 编译原理系列之四 自顶向下语法分析方法
  14. [2018.10.10 T2] 烯烃
  15. 如何五分钟之后自动锁定计算机,win10五分钟自动锁屏怎么设置_win10定时锁屏设置方法...
  16. LaTeX符号大全-基于lshort-zh-cn
  17. 图解 FAT 文件系统之基础知识（一）
  18. 【实验】SVO2.0 待更新
  19. 微信打不开MP4文件 （记录编码问题）
  20. Tomcat 服务器搭建

热门文章

  1. 希腊和土耳其的400年的血海深仇
  2. python爬虫要点_Python爬虫知识点梳理
  3. java.lang.boolean_java.lang.Boolean
  4. 二叉树及先序遍历二叉树，中序遍历二叉树，后序遍历二叉树
  5. 尚硅谷学习笔记——Java8新特性
  6. C# winIO32位，64位的使用
  7. Lucene 7.5.0 索引文件之timtip
  8. mybatis注解sql使用判断if踩坑
  9. 少年西游记 服务器维护中,【公告】《少年西游记》12月22日停服维护
  10. php 截图ppt文件,PPT转图片你还在靠截图？一键即可导出，这个方法太逆天了吧...