'bundle exec rake db:migrate' dauert wegen Kalendermigration lange

Installation
21

Jungs – ich weiß eure Hilfe hier wirklich zu schätzen und @pfaffman – bitte arbeitet deswegen nicht länger als nötig. Die Forenuser müssen eben warten, wenn ihr für den Abend offline gehen müsst.

1 „Gefällt mir“
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

Wow, was ist das?

24

Das ist das Kalender-Plugin

Läuft das 7 Stunden oder 7 Minuten?

25

Es lief das letzte Mal deutlich länger als 7 Minuten, aber nicht 7 Stunden, zumindest für mich.

26

Der Kalender-Plugin wird kaum genutzt – er kann entfernt werden, wenn das in irgendeiner Weise hilft.

1 „Gefällt mir“
27

Cool.

Falco – Vielleicht das Plugin einfach löschen?

Und dann die Plugin-Tabellen löschen?

EDIT: Mit entferntem Kalender, migrierter Datenbank und vorkompilierten Assets sollte die Seite in wenigen Minuten online sein.

28

Ich bin mehr als neugierig, was zum Teufel mit dem Kalender passiert ist, um eine solche Störung zu verursachen?!

29

Es LEBT. Absolute Legenden.

1 „Gefällt mir“
30

Ich werde dich morgens anpingen, um zu besprechen, wie wir die Dinge bereinigen können.

2 „Gefällt mir“
31

Vielen Dank, dass Sie sich besonders angestrengt haben <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
        )

Das sieht also nach mindestens einer O(n^2)-Operation aus, oder? In dieser Tabelle befinden sich 69.724.384 Zeilen, das sieht also nicht nach einer sehr guten Idee aus.

@Sikamikanico. Wenn du das Kalender-Plugin zurückhaben willst, denke ich, das Beste ist, alle Kalenderereignisse zu löschen und neu anzufangen. Das andere, was wir tun könnten, wäre, diese Abfrage auf dem aktiven Server auszuführen und zu sehen, ob sie jemals fertig wird.

Die Grundursache, denke ich, ist ein Fehler im Plugin, der Ereignisse duplizierte, wenn sich die Zeitzone änderte.

Die Tabelle calendar_events ist 11 GB groß:

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

Hier sind die größten Tabellen:

       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 Zeilen)

Nur calendar_events ist eindeutig bizarr.

1 „Gefällt mir“
33

Wir müssen verstehen, ob dies immer noch ein Fehler im Plugin ist oder ob es nur etwas ist, das in der Vergangenheit passiert ist.

Können Sie bestätigen, ob der Großteil der doppelten Einträge aus der Vergangenheit stammt oder ob es immer noch zu viele Zeilen mit einem aktuellen created_at gibt?

Vielen Dank!

1 „Gefällt mir“
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)