'bundle exec rake db:migrate' richiede molto tempo a causa della migrazione del calendario

Installazione
21

Ragazzi, apprezzo molto il vostro aiuto e @pfaffman, per favore, non lavorare fino a tardi per me. Gli utenti del forum dovranno semplicemente aspettare se devi disconnetterti per la sera.

1 Mi Piace
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 cos’è quello?

24

Questo è il plugin del calendario

Sta funzionando per 7 ore o 7 minuti?

25

È durato molto più di 7 minuti l’ultima volta, ma non 7 ore, almeno per me.

26

Il plugin del calendario è poco utilizzato: può essere rimosso, se ciò aiuta in qualche modo.

1 Mi Piace
27

Fantastico.

Falco – Forse basta eliminare il plugin?

E poi eliminare le tabelle del plugin?

MODIFICA: con il calendario rimosso, il database migrato e gli asset in precompilazione. Il sito dovrebbe essere online tra qualche minuto.

28

Sono oltremodo curioso di sapere cosa diavolo sia successo al calendario per causare un simile problema?!

29

È VIVO. Leggende assolute.

1 Mi Piace
30

Ti contatterò domattina per sapere come ripulire le cose.

2 Mi Piace
31

Grazie per esserti fatto in quattro <3

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
        )

Quindi sembra almeno un’operazione O(n^2), giusto? Ci sono 69.724.384 righe in quella tabella, quindi non sembra una buona idea.

@Sikamikanico. Se vuoi riavere il plugin del calendario, penso che la cosa da fare sia semplicemente eliminare tutti gli eventi del calendario e ricominciare da capo. L’altra cosa che potremmo fare sarebbe eseguire quella query sul server attivo e vedere se finisce mai.

La causa principale, penso, è un bug nel plugin che ha duplicato gli eventi quando è cambiato un fuso orario.

La tabella calendar_events è di 11 GB:

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

Ecco le tabelle più grandi:

       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)

Solo calendar_events è chiaramente bizzarro.

1 Mi Piace
33

Dobbiamo capire se questo possa essere ancora un bug nel plugin o solo qualcosa che è successo in passato.

Puoi confermare se la maggior parte delle voci duplicate risale al passato o se ci sono ancora troppe righe con un created_at recente?

Grazie!

1 Mi Piace
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)