'bundle exec rake db:migrate' tarda mucho debido a la migración del calendario

Instalación
21

Chicos: Agradezco mucho la ayuda aquí y @pfaffman: por favor, no trabajes hasta tarde por mi cuenta. Los asistentes al foro simplemente tendrán que esperar si necesitas desconectarte por la noche.

1 me gusta
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)

¡¡¡Dios mío!!!

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

¿Whoa qué es eso?

24

Ese es el plugin de calendario

¿Está funcionando durante 7 horas o 7 minutos?

25

Se ejecutó mucho más tiempo que 7 minutos la última vez, pero no 7 horas, al menos para mí.

26

El plugin de calendario apenas se usa; se puede eliminar si eso ayuda en algo.

1 me gusta
27

Genial.

Falco: ¿Quizás simplemente eliminar el plugin?

¿Y luego eliminar las tablas del plugin?

EDITAR: con el calendario eliminado, la base de datos migrada y los activos precompilando. El sitio debería estar en línea en unos minutos más.

28

¡Tengo mucha curiosidad por saber qué demonios le pasó al calendario para causar ese tipo de problema!

29

ESTÁ VIVO. Leyendas absolutas.

1 me gusta
30

Te avisaré por la mañana sobre cómo limpiar las cosas.

2 Me gusta
31

Gracias por hacer un esfuerzo adicional <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
        )

Así que eso parece al menos una operación O(n^2), ¿verdad? Hay 69.724.384 filas en esa tabla, así que no parece una muy buena idea.

@Sikamikanico. Si quieres que el plugin de calendario vuelva, creo que lo que hay que hacer es simplemente eliminar todos los eventos del calendario y puedes empezar de nuevo. Lo otro que podríamos hacer sería ejecutar esa consulta en el servidor activo y ver si alguna vez termina.

La causa raíz, creo, es un error en el plugin que duplicaba eventos cuando cambiaba la zona horaria.

La tabla calendar_events tiene 11 GB:

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

Aquí están las tablas más grandes:

       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 es claramente extraño.

1 me gusta
33

Necesitamos entender si esto todavía puede ser un error en el plugin o simplemente algo que sucedió en el pasado.

¿Puede confirmar si la mayor parte de las entradas duplicadas son del pasado o si todavía hay demasiadas filas con una created_at reciente?

¡Gracias!

1 me gusta
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)