'bundle exec rake db:migrate' يستغرق وقتًا طويلاً بسبب calendar migration

تثبيت
21

يا رفاق - أقدر حقًا المساعدة هنا و @pfaffman - من فضلك لا تعمل لوقت متأخر على حسابي. سيتعين على رواد المنتدى الانتظار ببساطة إذا كنت بحاجة إلى تسجيل الخروج لهذا المساء.

إعجاب واحد (1)
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)

يا إلهي

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

واو، ما هذا؟

24

هذه هي إضافة التقويم

هل هذا يعمل لمدة 7 ساعات أم 7 دقائق؟

25

لقد استمر لفترة أطول بكثير من 7 دقائق في المرة الأخيرة، ولكن ليس 7 ساعات، على الأقل بالنسبة لي.

26

المكون الإضافي للتقويم نادر الاستخدام - يمكن إزالته، إذا كان ذلك يساعد بأي شكل من الأشكال.

إعجاب واحد (1)
27

رائع.

فالكو - ربما فقط قم بحذف المكون الإضافي؟

ثم قم بحذف جداول المكون الإضافي؟

تحرير: مع إزالة التقويم، تم ترحيل قاعدة البيانات ويتم تجميع الأصول مسبقًا. يجب أن يكون الموقع متاحًا في غضون دقائق قليلة.

28

أنا فضولي للغاية لمعرفة ما حدث للتقويم ليسبب هذا النوع من المشاكل؟!

29

إنها حية. أساطير مطلقة.

إعجاب واحد (1)
30

سأقوم بالاتصال بك في الصباح لمعرفة كيفية تنظيف الأمور.

إعجابَين (2)
31

شكرا لك على بذل جهد إضافي :heart:

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
        )

إذًا، تبدو هذه عملية ذات تعقيد O(n^2) على الأقل، أليس كذلك؟ يوجد 69,724,384 صفًا في هذا الجدول، لذا لا يبدو هذا فكرة جيدة جدًا.

@Sikamikanico. إذا كنت تريد استعادة إضافة التقويم، أعتقد أن ما يجب فعله هو حذف جميع أحداث التقويم والبدء من جديد. الشيء الآخر الذي يمكننا فعله هو تشغيل هذا الاستعلام على الخادم النشط ومعرفة ما إذا كان سينتهي على الإطلاق.

السبب الجذري، أعتقد، هو خطأ في الإضافة أدى إلى تكرار الأحداث عند تغيير المنطقة الزمنية.

جدول calendar_events حجمه 11 جيجابايت:

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

نحتاج إلى فهم ما إذا كان هذا لا يزال خطأ في المكون الإضافي أم أنه مجرد شيء حدث في الماضي.

هل يمكنك تأكيد ما إذا كان الجزء الأكبر من الإدخالات المكررة من الماضي أم أنه لا يزال هناك عدد كبير جدًا من الصفوف التي تحتوي على created_at حديث؟

شكرا لك!

إعجاب واحد (1)
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)