PostgreSQL 数据库大小不合理

Question

在我的 postgresql 9.6 实例中，我有 1 个生产数据库。当我查询所有数据库的大小时:

combit=> Select pg_database.datname,pg_size_pretty(pg_database_size(pg_database.datname)) as size from pg_database;
  datname  |  size   
-----------+---------
 template0 | 7265 kB
 combit    | 285 GB
 postgres  | 7959 kB
 template1 | 7983 kB
 repmgr    | 8135 kB
(5 rows)

当我检查数据库中的大表(包括索引)时:

combit=> SELECT nspname || '.' || relname AS "relation",
combit->     pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
combit->   FROM pg_class C
combit->   LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
combit->   WHERE nspname NOT IN ('pg_catalog', 'information_schema')
combit->     AND C.relkind <> 'i'
combit->     AND nspname !~ '^pg_toast'
combit->   ORDER BY pg_total_relation_size(C.oid) DESC
combit->   LIMIT 20;
      relation           | total_size 
-----------------------------+------------
 rep.ps_rf_inst_prod      | 48 GB
 rep.nap_inter_x5         | 46 GB
 rep.man_x5               | 16 GB
 rep.tc_fint_x5           | 9695 MB
 rep.nap_ip_debit_x5      | 7645 MB
 rep.ip__billing      | 5458 MB
 rep.ps_rd            | 3417 MB
 rep.nap_ip_discount      | 3147 MB
 rep.custo_x5             | 2154 MB
 rep.ip_service_discou_x5 | 1836 MB
 rep.tc_sub_rate__x5      | 294 MB

总和不超过120G。

当我直接检查 fs 时:

[/data/base] : du -sk * | sort -n
7284    13322
7868    13323
7892    1
8156    166694
298713364       16400

[/数据/基础]:

16400是combit数据库的oid。可以看到fs上combit的大小约为298G。

我检查了最大表中的死元组:

combit=>select relname,n_dead_tup,last_autoanalyze,last_analyze,last_autovacuum,last_vacuum from pg_stat_user_tables order by n_live_tup desc limit4;

  -[ RECORD 1 ]----+------------------------------
  relname          | ps_rf_inst_prod
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-04 09:00:16.585295+02
  last_analyze     | 2017-12-05 16:08:31.218621+02
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 2 ]----+------------------------------
  relname          | man_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-05 06:02:07.189184+02
  last_analyze     | 2017-12-05 16:12:58.130519+02
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 3 ]----+------------------------------
  relname          | tc_fint_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-05 06:04:06.698422+02
  last_analyze     | 
  last_autovacuum  | 
  last_vacuum      | 
  -[ RECORD 4 ]----+------------------------------
  relname          | nap_inter_x5
  n_dead_tup       | 0
  last_autoanalyze | 2017-12-04 08:54:16.764392+02
  last_analyze     | 2017-12-05 16:10:23.411266+02
  last_autovacuum  | 
  last_vacuum      | 

我在 2 小时前对所有 5 个顶级表运行了 vacuum full，但并没有释放很多空间...

在此数据库上，唯一发生的操作是截断、插入和选择。那么我的一些表上怎么会有死元组呢？如果我只运行截断、选择、插入查询元组，则不应创建..

更大的问题是，丢失的 180G 在哪里？

Answer 1

只是想提一下，解决方案是使用 pg_dump 将数据库转储到一个文件中，删除数据库然后恢复它。我在数据库的目录文件中表示不再存在的对象。