'bundle exec rake db:migrate' 因日历迁移耗时过长

安装
21

伙计们 - 非常感谢你们的帮助，@pfaffman - 请不要为我加班。如果你们需要下班休息，论坛用户只能等待。

1 个赞
22 
discourse=# SELECT pid, age(clock_timestamp(), query_start), usename, query 
FROM pg_stat_activity 
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' 
ORDER BY query_start desc;
 pid  |       age       |  usename  |                                                    query                                                     
------+-----------------+-----------+--------------------------------------------------------------------------------------------------------------
   47 |                 |           | 
   50 |                 | postgres  | 
   48 |                 |           | 
   46 |                 |           | 
   45 |                 |           | 
 3231 | 00:07:57.332835 | discourse | DELETE                                                                                                      +
      |                 |           |   FROM calendar_events ce
      |                 |           | WHERE
      |                 |           |   ce.id IN (SELECT DISTINCT(ce3.id) FROM calendar_events ce2
      |                 |           |             LEFT JOIN calendar_events ce3 ON ce3.user_id = ce2.user_id AND ce3.description = ce2.description+
      |                 |           |             WHERE ce2.start_date >= (ce3.start_date - INTERVAL '1 days')                                    +
      |                 |           |               AND ce2.start_date <= (ce3.start_date + INTERVAL '1 days')                                    +
      |                 |           |               AND ce2.timezone IS NOT NULL                                                                  +
      |                 |           |               AND ce3.timezone IS NULL                                                                      +
      |                 |           |               AND ce3.id != ce2.id                                                                          +
      |                 |           |               AND ce2.post_id IS NULL                                                                       +
      |                 |           |               AND ce3.post_id IS NULL                                                                       +
      |                 |           |   )
      |                 |           | 
 3232 | 00:07:57.347747 | discourse | SELECT pg_try_advisory_lock(2859260972035668690)
(7 rows)

我的天啊

discourse=# select count(*) from calendar_events;
  count   
----------
 69724384
(1 row)
23

哇，那是什么？

24

这是日历插件

这是运行了 7 小时还是 7 分钟？

25

上次运行时间远超7分钟，但对我来说，并没有达到7小时。

26

日历插件几乎不被使用 - 如果这有任何帮助，可以将其删除。

1 个赞
27

好的。

Falco–也许直接删除插件？

然后删除插件表？

编辑：日历已移除，数据库已迁移，资源文件正在预编译。网站将在几分钟内上线。

28

我非常想知道到底是什么导致了日历出现那种问题？！

29

它活了。绝对的传奇。

1 个赞
30

我早上会联系你，告诉你如何清理。

2 个赞
31

感谢您付出额外的努力 \u003c3

32 
      DELETE
        FROM calendar_events ce
      WHERE
        ce.id IN (SELECT DISTINCT(ce3.id) FROM calendar_events ce2
                  LEFT JOIN calendar_events ce3 ON ce3.user_id = ce2.user_id AND ce3.description = ce2.description
                  WHERE ce2.start_date >= (ce3.start_date - INTERVAL '1 days')
                    AND ce2.start_date <= (ce3.start_date + INTERVAL '1 days')
                    AND ce2.timezone IS NOT NULL
                    AND ce3.timezone IS NULL
                    AND ce3.id != ce2.id
                    AND ce2.post_id IS NULL
                    AND ce3.post_id IS NULL
        )

所以这看起来至少是一个 O(n^2) 的操作，对吧？那个表里有 69,724,384 行，所以这看起来不是个好主意。

@Sikamikanico。如果你想让日历插件回来，我认为应该做的就是删除所有日历事件，然后你可以重新开始。我们还可以做的另一件事是在活动服务器上运行那个查询，看看它是否能完成。

我认为根本原因是在时区更改时复制事件的插件中的一个错误。

calendar_events 表有 11GB：

SELECT pg_size_pretty( pg_total_relation_size('calendar_events') );
 pg_size_pretty
----------------
 11 GB
(1 row)

以下是最大的表：

       relation       | total_size
----------------------+------------
 calendar_events      | 11 GB
 post_timings         | 6884 MB
 posts                | 2292 MB
 user_auth_token_logs | 1240 MB
 user_actions         | 1055 MB
(5 rows)

只有 calendar_events 明显很奇怪。

1 个赞
33

我们需要了解这是否仍然是插件中的一个 bug，还是仅仅是过去发生的事情。

您能确认重复条目的大部分是否来自过去，还是仍然有太多行的 created_at 时间戳是最近的？

谢谢！

1 个赞
34 
discourse=# select count(*) from calendar_events where created_at > NOW()-INTERVAL '200 days';
  count
----------
 25970368
(1 row)

discourse=# select count(*) from calendar_events where created_at > NOW()-INTERVAL '100 days';
  count
----------
 14377700
(1 row)

discourse=# select count(*) from calendar_events where created_at > NOW()-INTERVAL '50 days';
  count
---------
 7207939
(1 row)

discourse=# select count(*) from calendar_events where created_at > NOW()-INTERVAL '5 days';
 count
--------
 589938
(1 row)

iscourse=# select count(*) from calendar_events where created_at < NOW()-INTERVAL '200 days';
  count
----------
 43754016
(1 row)