'bundle exec rake db:migrate' prend beaucoup de temps en raison de la migration du calendrier

Installation
21

Les gars - j’apprécie vraiment l’aide ici et @pfaffman - s’il vous plaît, ne travaillez pas tard pour moi. Les participants au forum devront simplement attendre si vous devez vous déconnecter pour la soirée.

1 « J'aime »
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)

OMG

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

Whoa, qu’est-ce que c’est ?

24

C’est le plugin de calendrier

Est-ce que cela dure 7 heures ou 7 minutes ?

25

Il a duré bien plus de 7 minutes la dernière fois, mais pas 7 heures, du moins pour moi.

26

Le plugin Calendrier est à peine utilisé - il peut être supprimé, si cela peut aider à quelque égard.

1 « J'aime »
27

Cool.

Falco — Et si on supprimait simplement le plugin ?

Et ensuite, supprimer les tables du plugin ?

EDIT : le calendrier a été supprimé, la base de données a migré et les ressources sont en cours de précompilation. Le site devrait être opérationnel dans quelques minutes.

28

Je suis extrêmement curieux de savoir ce qui est arrivé au calendrier pour causer ce genre de problème ?!

29

Il est VIVANT. Des légendes absolues.

1 « J'aime »
30

Je vous contacterai demain matin pour savoir comment nettoyer les choses.

2 « J'aime »
31

Merci d’avoir fait un effort supplémentaire :heart:

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
        )

Cela ressemble donc au moins à une opération O(n^2), n’est-ce pas ? Il y a 69 724 384 lignes dans cette table, donc ce n’est pas une très bonne idée.

@Sikamikanico. Si vous voulez récupérer le plugin de calendrier, je pense que la meilleure chose à faire est de supprimer tous les événements du calendrier et de recommencer. L’autre chose que nous pourrions faire serait d’exécuter cette requête sur le serveur actif et de voir si elle se termine un jour.

La cause profonde, je pense, est un bug dans le plugin qui a dupliqué les événements lorsqu’un fuseau horaire a changé.

La table calendar_events fait 11 Go :

SELECT pg_size_pretty( pg_total_relation_size('calendar_events') );

 pg_size_pretty
----------------
 11 GB
(1 row)

Voici les plus grosses tables :

       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)

Seule calendar_events est clairement bizarre.

1 « J'aime »
33

Nous devons comprendre s’il s’agit toujours d’un bug dans le plugin ou simplement de quelque chose qui s’est produit dans le passé.

Pouvez-vous confirmer si la majorité des entrées dupliquées datent du passé ou s’il y a encore trop de lignes avec une created_at récente ?

Merci !

1 « J'aime »
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)