皆さん、ご協力ありがとうございます。@pfaffman さん、私のために遅くまで作業しないでください。もしログオフする必要があるなら、フォーラムの参加者は待つしかありません。
「いいね！」 1
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)
うわー、それは何ですか？
それがカレンダープラグインです
それは7時間実行されているのですか、それとも7分ですか？
前回は7分をかなり超えて実行されましたが、少なくとも私にとっては7時間ではありませんでした。
カレンダープラグインはほとんど使用されていません。必要であれば削除できます。
「いいね！」 1
クール。
Falco–プラグインを削除するだけでは？
そしてプラグインテーブルを削除する？
編集：カレンダーを削除し、データベースを移行し、アセットをプリコンパイルしました。サイトは数分でアップするはずです。
一体全体、カレンダーに何が起こってあのような問題が発生したのか、非常に気になります！
生きてる。最高のレジェンドたちだ。
「いいね！」 1
朝、片付け方について連絡します。
「いいね！」 2
お気遣いいただきありがとうございます <3
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
)
これは少なくとも O(n^2) の操作のように見えますね。このテーブルには 69,724,384 行あるので、あまり良い考えではないように思えます。
@Sikamikanico さん。カレンダープラグインを元に戻したいのであれば、すべてのカレンダーイベントを削除して最初からやり直すのが良いと思います。もう一つの方法として、そのクエリをアクティブなサーバーで実行して、それが終わるかどうかを確認することもできます。
根本原因は、タイムゾーンが変更されたときにイベントが重複するプラグインのバグだと思います。
calendar_events テーブルは 11GB です。
discourse=# SELECT pg_size_pretty( pg_total_relation_size('calendar_events') );
pg_size_pretty
----------------
11 GB
(1 row)
最大のテーブルは次のとおりです。
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)
calendar_events だけが明らかに異常です。
「いいね！」 1
これがまだプラグインのバグなのか、それとも過去に発生したことなのかを理解する必要があります。
重複エントリの大部分が過去のものであるか、それとも最近の created_at を持つ行がまだ多すぎるかを確認していただけますか？
よろしくお願いします！
「いいね！」 1
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)