Synology DSM 6.2 Photo Station 6 - 载入数据失败修复的方法

739 阅读2分钟

我是一个相当快乐的Synology用户。在过去的几年里,我主要用它来备份我的东西,所以我没有太注意到一个事实,那就是Photo Station软件会变得越来越慢,以至于我每次访问它时都会出现"加载数据失败"的信息。

一些文章建议,你必须放弃并重新创建媒体索引数据库来解决这个问题。然而,从长远来看,这并不能帮助你。你的Photo Station 6数据库会在一段时间后再次变得臃肿。

之所以Photo Station 6的速度越来越慢,是因为Synology出于某种疯狂的原因,禁用了PostgreSQL的自动吸尘功能。抽真空是为了保持你的数据库处于良好的状态。

如何一劳永逸地解决这个问题?你需要启用PostgreSQL的自动吸尘功能,为了达到立竿见影的效果,你还应该手动运行吸尘功能。

SSH进入你的服务器,然后。

sudo su
cd /volume1/@database/pgsql
vim postgresql.conf

postgresql.conf 文件中替换(如果不存在则添加)以下设置。

wal_buffers =128MB
autovacuum = on
checkpoint_segments = 10

保存,退出该文件并重新启动。

如果你想手动运行吸尘,登录到PostgreSQL控制台。

psql -U postgres

列出可用的数据库。

postgres=# \l
                                       List of databases
    Name     |           Owner            | Encoding  | Collate | Ctype |   Access privileges   
-------------+----------------------------+-----------+---------+-------+-----------------------
 mediaserver | MediaIndex                 | SQL_ASCII | C       | C     | 
 ong         | SynologyApplicationService | SQL_ASCII | C       | C     | 
 photo       | PhotoStation               | SQL_ASCII | C       | C     | 
 postgres    | postgres                   | SQL_ASCII | C       | C     | 
 synosnmp    | postgres                   | SQL_ASCII | C       | C     | 
 template0   | postgres                   | SQL_ASCII | C       | C     | =c/postgres          +
             |                            |           |         |       | postgres=CTc/postgres
 template1   | postgres                   | SQL_ASCII | C       | C     | postgres=CTc/postgres+
             |                            |           |         |       | =c/postgres

连接到photo 数据库。

postgres=# \c photo;
You are now connected to database "photo" as user "postgres".

通过运行下面的查询来检查表的大小。

SELECT nspname || '.' || relname AS "relation",
    pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
  FROM pg_class C
  LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
  WHERE nspname NOT IN ('pg_catalog', 'information_schema')
    AND C.relkind <> 'i'
    AND nspname !~ '^pg_toast'
  ORDER BY pg_total_relation_size(C.oid) DESC
  LIMIT 5;

       relation       | total_size 
----------------------+------------
 public.photo_image   | 1097 MB
 public.photo_log     | 5912 kB
 public.video_convert | 936 kB
 public.photo_share   | 928 kB
 public.video         | 864 kB
(5 rows)

和潜在的吸尘对象现在应该很明显了。

photo=# vacuum full public.photo_image;
VACUUM

再次运行大小检查查询,看到图像表的大小减少了93%。

       relation       | total_size 
----------------------+------------
 public.photo_image   | 72 MB
 public.photo_log     | 5912 kB
 public.video_convert | 936 kB
 public.photo_share   | 928 kB
 public.video         | 864 kB
(5 rows)

在这之后,一切都会工作得非常快!