So I did an upgrade today and the postgresql version seems to have been updated in the process. Since doing this, this issue (or similar) has returned (old topic is closed now): [صورة] Very slow Sidekiq issue with large queue due to massive numbers of unread user notification…

Ok so to follow up, everything still looks good, postmaster has calmed down drastically and sidekiq is moving really fast again. To summarise on what worked in my scenario (with default db name of ‘discourse’): cd /var/discourse/ ./launcher enter app sudo -u postgres psql \c discourse Then from t…

[صورة] markersocial: VACUUM FULL VERBOSE; Can you try a vacuum verbose analyze? Also applies to you @eboehnisch . This following very simple query averaging 2s is really weird: [صورة] markersocial: SELECT "posts"."id" FROM "posts" WHERE ("posts"."deleted_at" IS NULL) AND "posts"."topic_id…

Tried VACUUM VERBOSE ANALYZE;. What shall I be looking for in the results?

Great, thanks! So I think this has solved the issue with postmasters going wild using all the CPU. So this is a big improvement. Sidekiq is still slow unfortunately, but better than before running VACUUM VERBOSE ANALYZE;

[صورة] eboehnisch: What shall I be looking for in the results? Nothing special, unless it is a big error message. Performance should recover now. [صورة] markersocial: Great, thanks! So I think this has solved the issue with postmasters going wild using all the CPU. So this is a big impr…

This improved the situation definitely but after a while again three postmaster processes use 100% CPU for over a minute each.

I’d say wait a bit, because you probably have a queue to chew from the slow period. Check /sidekiq for stats.

:smiley: Speed has really picked up now, looks like it’s fixed. Thanks a lot for the help @Falco ! I’ll leave it running for a while and post an update here later~

Maybe try running: VACUUM FULL VERBOSE; and (assuming your db name is ‘discourse’ which is default): REINDEX DATABASE discourse; This might be better than normal reindex, but I haven’t tested it: PostgreSQL 12 update

Both operations listed above generates locks that can be really hard in a live site. I’d recommend the ones listed at post-update-optional-tasks because other than using lots of CPU, they don’t block the normal database operations.

Run both. The latter reports an error, however: discourse=# REINDEX SCHEMA CONCURRENTLY public; ERROR: could not create unique index "index_users_on_username_lower_ccnew" DETAIL: Key (username_lower)=(marks) is duplicated. I guess it’s time to get into PostgreSQL and to find and delete the recor…

Sidekiq بطيء + Postmaster يستهلك أكثر من 95% من وحدة المعالجة المركزية (32 نواة) بعد ترقية إصدار PostgreSQL

الدعم تثبيت

sam (Sam Saffron) 28 مايو 2020، 12:58ص 18

انظر:

الموضوع		الردود	مرات العرض
Very slow Sidekiq issue with large queue due to massive numbers of unread user notifications Self-hosting	68	8060	11 أبريل 2020
Long-Running Sidekiq Jobs Feature	21	2013	24 ديسمبر 2020
PostgreSQL runaway IO Self-hosting	35	3469	3 مارس 2021
PostgreSQL 13 update Announcements	2	11244	13 سبتمبر 2023
Primary Postgres database process (postmaster) eating all CPU Self-hosting server-resources	13	4358	28 مايو 2020

Sidekiq بطيء + Postmaster يستهلك أكثر من 95% من وحدة المعالجة المركزية (32 نواة) بعد ترقية إصدار PostgreSQL

الموضوعات ذات الصلة