'bundle exec rake db:migrate' demorando muito devido à migração de calendário

Instalação
21

Pessoal - agradeço muito a ajuda aqui e @pfaffman - por favor, não trabalhe até tarde por minha causa. Os frequentadores do fórum terão que esperar se você precisar se desconectar para a noite.

1 curtida
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)

Meu Deus

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

Uau, o que é isso?

24

Esse é o plugin de calendário

Está rodando por 7 horas ou 7 minutos?

25

Ele durou bem mais de 7 minutos da última vez, mas não 7 horas, pelo menos para mim.

26

O plugin de calendário é pouco utilizado - pode ser removido, se isso ajudar de alguma forma.

1 curtida
27

Legal.

Falco–Talvez apenas excluir o plugin?

E então excluir as tabelas do plugin?

EDIT: com o calendário removido, o banco de dados migrado e os assets pré-compilando. O site deve estar no ar em mais alguns minutos.

28

Estou extremamente curioso para saber o que diabos aconteceu com o calendário para causar esse tipo de problema?!

29

Está VIVO. Lendas absolutas.

1 curtida
30

Vou te ligar de manhã sobre como organizar as coisas.

2 curtidas
31

Obrigado por ir além <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
        )

Então isso parece ser pelo menos uma operação O(n^2), certo? Existem 69.724.384 linhas nessa tabela, então isso não parece uma ideia muito boa.

@Sikamikanico. Se você quiser o plugin de calendário de volta, acho que o que fazer é simplesmente excluir todos os eventos do calendário e você pode começar de novo. A outra coisa que poderíamos fazer seria executar essa consulta no servidor ativo e ver se ela termina.

A causa raiz, eu acho, é um bug no plugin que duplicou eventos quando um fuso horário mudou.

A tabela calendar_events tem 11 GB:

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

Aqui estão as maiores tabelas:

       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)

Apenas calendar_events é claramente bizarro.

1 curtida
33

Precisamos entender se isso ainda pode ser um bug no plugin ou apenas algo que aconteceu no passado.

Você pode confirmar se a maior parte das entradas duplicadas é do passado ou se ainda há muitas linhas com um created_at recente?

Obrigado!

1 curtida
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)