我们注意到最近几周我们平台的性能下降,所以我运行了以下命令:
select relname, last_vacuum, last_autovacuum, last_analyze, last_autoanalyze
from pg_stat_user_tables
where relname like 'core_%';
Run Code Online (Sandbox Code Playgroud)
并注意到我们的主桌已经一个多星期没有自动清扫了。所以上周我跑了:
vacuum analyse verbose TABLENAME
Run Code Online (Sandbox Code Playgroud)
这似乎有帮助,但我们现在又遇到了同样的问题。仔细检查后,很多表要么从未被分析过(自动或其他方式),除了vacuum analyse
上周手动运行之外,没有一个表被手动清理过,而且很多其他表也没有被自动清理过,充其量是几天前,更糟的是几周前。
我对条款的理解如下:
在 中postgres.conf
,autovacuum 属性被注释掉了,但是文档指出这是默认打开的,所以我的假设是即使它被注释掉了,它仍然应该打开吗?
有人可以解释为什么这些表不会被频繁地清理和分析,更具体地说,这些没有更新的值实际上对系统有那么大的影响吗?
信息:Postgres 9.1 操作系统:Ubuntu 12.04
输出
SELECT relname as "Table",
pg_size_pretty(pg_total_relation_size(relid)) As "Size",
pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;
Table | Size | External Size
-----------------+------+---------------
"Primary Table" | 27G | 8232M
Run Code Online (Sandbox Code Playgroud) postgresql performance postgresql-9.1 postgresql-performance
所以昨晚我们的 PG Slave 在大量重新配置磁盘空间、新驱动器等后空间不足,现在报告以下错误:
FATAL: could not receive data from WAL stream: FATAL: requested WAL segment 00000001000018F70000008A has already been removed
Run Code Online (Sandbox Code Playgroud)
根据我所做的阅读,似乎唯一的解决方案是使用 pg_start_backup() 等重新同步从站。基于此,我有几个问题。
根据要求,可以找到日志文件:http : //pastebin.com/9F8vJh6R,已删除文件的其余部分,因为它只有 5 个小时的相同重复错误
非常感谢