Question

我们的数据库似乎被打破了，通常它占用了大约1-2％的cpu，但是如果我们运行一些额外的后端服务，为10M行表制作UPDATE和INSERT查询（每3秒约1次查询），一切都将进入地狱（包括CPU从2％增加到98％）。

我们决定调试正在进行的操作，运行VACUUM和ANALYZE以了解db的错误但是......

production=# ANALYZE VERBOSE users_user;
INFO:  analyzing "public.users_user"
INFO:  "users_user": scanned 280 of 280 pages, containing 23889 live rows and 57 dead rows; 23889 rows in sample, 23889 estimated total rows
INFO:  analyzing "public.users_user"
INFO:  "users_user": scanned 280 of 280 pages, containing 23889 live rows and 57 dead rows; 23889 rows in sample, 23889 estimated total rows
ERROR:  tuple already updated by self

我们无法在任何表格上完成ANALYZE，也无法找到有关此问题的任何信息。有什么建议可能是错的吗？

 PostgreSQL 9.6.8 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16), 64-bit

评论中要求的其他信息：

也许你有一个损坏的pg_class

SELECT * FROM pg_class WHERE relname = 'users_user';

输出：https://pastebin.com/WhmkH34U

所以要做的第一件事就是开始所有其他会议再试一次

没有其他会话，我们已将整个数据库转储到新的测试服务器上，问题仍然存在，没有客户端连接到此数据库

Answer 1

我建议您在搜索重复的行之前使用以下参数启动服务器：

enable_indexscan = off
enable_bitmapscan = off
ignore_system_indexes = on

如果服务器崩溃，索引可能处于不同的表数据状态。例如，当损坏影响事务可见性（pg_clog）时会发生这种情况。然后在评论中提到的pg_class或pg_statistic上搜索重复的行。

您也可以尝试清理pg_statistic。首先，使用以下命令启动服务器：

allow_system_table_mods = on

然后发出TRUNCATE TABLE和ANALYZE：

--Cleaning pg_statistic
TRUNCATE TABLE pg_catalog.pg_statistic;
--Analyze entire database
ANALYZE VERBOSE;

如果问题出现在pg_statistic中，那就足够了。

PostgreSQL“元组已经自我更新”

1 个答案: