Hi all, hoping for some help! Has anyone experienced this before? ./launcher rebuild app is running, get’s to this point and just hangs here. [image] Now it is doing something, but it’s doing it extremely slowly. I’ve been running the forum via a self installed digital ocean droplet for 3 years…

A VM is the common term for what DigitalOcean calls a droplet. Sounds like you might want to take a look at my profile and considered managed hosting though :wink:

[图片] Falco: Something like ps aux | grep postgres should show the start of it. ystemd+ 7660 0.0 0.3 352060 28284 ? S 22:31 0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main systemd+ 7667 0.0 0.1 352588 9628 ? Ss 22:31 0:00 postgres: 13/main: c…

[图片] Jay Pfaffman: postgres_data directory is 28GB. Thanks Jay. Let me know if there’s anything you need from me.

[图片] Jay Pfaffman: htop shows that the discourse [local] delete is what’s eating 100% cpu. The droplet has 8GB of RAM, and right now <1GB is in use (not counting buffers). Please share the whole SQL of the long running query.

Where do I find that? The migration isn’t printing any logs. THe last line in the rebuild is I, [2023-12-04T22:33:33.759401 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' I"m working on a full log for the one that I just restarted.

Enter the container, switch to the postgres user, enter psql and run 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;

Lads - really appreciate the assistance here and @pfaffman - please don’t work late on my account. Forum goers will simply have to wait if you need to log off for the evening.

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 …

[图片] Jay Pfaffman: discourse=# select count(*) from calendar_events; count ---------- 69724384 (1 row) Whoa what is that?

That’s the calendar plugin FIX: remove duplicated holidays because of timezone change (#489) committed 03:48AM - 24 Nov 23 UTC (UTC) [图片] KrisKotlarek +…

'bundle exec rake db:migrate' 因日历迁移耗时过长

支持安装

renato (Renato Atilio) 2023 年12 月 5 日 15:42 33

我们需要了解这是否仍然是插件中的一个 bug，还是仅仅是过去发生的事情。

您能确认重复条目的大部分是否来自过去，还是仍然有太多行的 created_at 时间戳是最近的？

谢谢！

话题		回复	浏览量
Database migration chokes on huge value of a "calendar-details" item in table "post_custom_fields" Bug	12	2301	2020 年12 月 7 日
Discourse installation has been getting slower and slower and slower Self-hosting server-resources	36	2146	2023 年4 月 15 日
Help! Upgrade led to complete fail Self-hosting	7	1533	2021 年3 月 9 日
Restore fails due to disk space on migration because of 70M calendar events Support events	10	355	2026 年2 月 14 日
PostgreSQL Stuck During Rebuilding Self-hosting	51	2879	2024 年9 月 4 日

'bundle exec rake db:migrate' 因日历迁移耗时过长

相关话题