So first, thanks a lot! Manually stopping the services inside the container apparently did the trick, and I was able to the double container rebuild for the upgrade (with locale variables adjusted as discussed above - side note: I checked the installation docs and I don’t think they mention locales; maybe this would be a good addition).
Unfortunately, the analysis of problematic processes was inconclusive. The only thing I see is Postgres-related things like WalWriter, AutoVacuum, etc. The only clue I have is that when I reboot the system and also after index changes on updates, I typically see a high CPU load for postgres for about half an hour.
And when I checked pg_stat_activity today after the reboot, I saw two long running queries (at least if my understanding of the columns is correct):
SELECT "posts"."id" FROM "posts" INNER JOIN "topics" ON "topics"."deleted_at" IS NULL AND "topics"."id" = "posts"."topic_id" LEFT JOIN post_search_data ON post_id = posts.id WHERE "posts"."deleted_at" IS NULL AND (posts.raw != '') AND (topics.deleted_at IS NULL) AND (post_search_data.locale IS NULL OR post_search_data.locale != 'de' OR post_search_data.version != 5) ORDER BY posts.id DESC LIMIT 20000
and
SELECT "optimized_images".* FROM "optimized_images" WHERE "optimized_images"."upload_id" = 13 AND "optimized_images"."height" = 32 AND "optimized_images"."width" = 32 LIMIT 1
After the aforementioned 30 minutes, the first one was apparently completed and the CPU load from postgres is now normal.
I’m not sure why these two queries take so long and even less why the second one is still showing up in pg_stat_activity after more than an hour, but potentially such long-running queries blocked the postgres service from shutting down correctly when trying to rebuild it earlier.
If you have any lead here, that’ll be much appreciated. But potentially this is also something that might be go into another thread (if so, just let me know, and I’ll edit this post).
Related screenshots:
