PostgreSQL统计信息问题 - 无法重命名临时统计信息文件

Question

我在Windows上运行PotgreSQL 9.4,并不断收到错误,

2015-06-15 09:35:36 EDT LOG could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied 

我还看到对global.stat和global.tmp的常量200-800k写入.我见过其他用户有同样的问题,但没有解决方案.它是一个大型数据库服务器,拥有300g数据和6,000个数据库.

我尝试过设置,

track_activities=off

在配置文件中,但它似乎没有任何影响.

任何错误的帮助,或减少写入？

Answer 1

在我最初的回答之后,我决定研究统计数据收集器的操作,特别是它对pg_stat_tmp中的文件做了什么.结果我大大改写了答案.

global.stat/global.tmp文件用于什么？

Postgresql包含收集有关其操作的统计信息和状态信息的功能.该功能在手册的第27.2节中描述.

这些信息由stats collector process.它通过该global.stat文件提供给其他postgresql进程.第一次运行在事务中访问此数据的查询时,您连接到的后端将读取global.stat文件并缓存结果,使用它直到事务结束.

为了使此文件保持最新,stats收集器进程会定期使用更新的信息重写它.它通常每秒执行几次.过程如下:

1. 创建一个新文件global.tmp
2. 将数据写入此文件
3. 将global.tmp重命名为global.stat,覆盖以前的global.stat

在global.tmp和global.stats文件被写入到由配置目录stats_temp_directory配置参数.通常这是设置为$PGDATA/pg_stat_tmp.

关闭时,将stats文件写入文件$PGDATA/global/pgstat.stat,并删除上面tmp目录中的文件.然后在再次启动数据库时读取并删除此文件.

为什么统计信息收集器处理器会产生如此多的I/O负载？

通常,写入global.stats的数据量相对适中,写入它不会产生那么多的I/O流量.然而,在某些情况下,它似乎变得非常臃肿.当发生这种情况时,生成的负载量可能开始变得过多,因为整个文件每秒被重写一次以上.

与其他类似的服务器相比,我有过一次经历增长10倍或更多的经验.这台机器确实拥有非常多的数据库(对于我们的应用程序至少--30-40个数据库 - 但没有像你说的那样6000).拥有大量数据库可能会加剧这种情况.

下面的一些参考文献讨论了创建/删除大量表格导致这些文件膨胀的模式,并且可能autovacuum没有足够强大地运行以消除相关的膨胀.您可能希望考虑您的autovac设置.

为什么我在Windows上出现"Permission Denied"错误？

在检查了postgresql源代码之后,我认为在访问global.stats文件时可能存在竞争条件,这可能在任何时候发生,但是文件的大小会加剧.

Windows中的默认操作模式是,当另一个进程打开文件时,无法重命名或删除文件.这与Linux(或Unix)不同,后者可以在其他进程访问文件时重命名或删除文件.

在上面的序列中,您可以看到,如果其中一个后端进程在stats collector重写它的同时读取文件,则后端进程在尝试重命名时仍可能打开该文件.这导致您看到的"权限被拒绝"错误.

自然地,当文件变得非常大时,读取它所花费的时间量变得更加显着,因此当后端仍然打开时,统计数据收集器进程尝试重命名的概率增加.

但是,由于文件经常被重写,因此这些错误的影响相对较小.它只是意味着此特定更新失败,导致后端略微过时的统计信息.下一次更新可能会成功.

请注意,Windows确实提供了一种文件打开模式,它允许在另一个进程打开文件时删除或重命名文件,但据我所知,Postgresql不使用此模式.我找不到任何关于此的错误报告 - 似乎应该报告.

总之,这些错误是主要问题的副作用,即global.stat文件的大小过大.

我已经track_activities关闭但文件仍在写 - 为什么？

从我所看到的,track_activites只影响统计数据收集器收集的一组信息.

此外,看起来无论这些设置如何都启动了统计信息收集器进程,并且将继续重写该文件.设置似乎仅控制新数据的集合.

我的结论是,一旦文件变得臃肿,即使所有的统计信息收集选项都关闭,它仍将保持不变并继续重写.

我该怎么做才能避免这个问题？

一旦文件变得臃肿,似乎使数据库恢复到良好工作状态的最简单方法是使用以下步骤删除文件:

1. 停止数据库

2. 当DB停止时,pg_stat_tmp目录为空并$PGDATA/global/pgstat.stat写入文件.我们将此文件重命名为pgstat.stat.old.

3. 启动数据库.它创建了一组新的pgstat文件.确认服务器运行正常后,您可以删除已重命名的旧文件.

这是我们的一台服务器遇到此问题时使用的过程.

不用说在手动操作Postgresql Data目录下的任何文件时要非常小心.

在此之后,您可能希望监视服务器以查看文件是否再次膨胀.如果是,那么这里有一些额外的想法需要考虑:

• 如上所述,我已经看到一些对此文件的引用如果autovacuum没有足够积极地运行则会变得臃肿.您可能希望调整autovacuum设置

• 禁用本手册第18.9.1节中track_xxx描述的任何不需要的选项可能会有所帮助

• 可以将pg_stats_tmp目录放在tmpfs文件系统中(或者在Windows中可用的基于RAM的文件系统).这样做应该消除I/O作为这些文件的关注点.

参考文献:

• Postgres统计信息收集器显示高磁盘I/O.
• postgres统计信息收集器进程生成的I/O太多
• 统计数据收集器突然导致大量IO