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:

[Bild] 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:…

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

[Bild] 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 …

[Bild] 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) [Bild] KrisKotlarek …

'bundle exec rake db:migrate' dauert wegen Kalendermigration lange

Unterstützung Installation

pfaffman (Jay Pfaffman) 5. Dezember 2023 um 00:13 27

Cool.

Falco – Vielleicht das Plugin einfach löschen?

Und dann die Plugin-Tabellen löschen?

EDIT: Mit entferntem Kalender, migrierter Datenbank und vorkompilierten Assets sollte die Seite in wenigen Minuten online sein.

Thema		Antworten	Aufrufe
Database migration chokes on huge value of a "calendar-details" item in table "post_custom_fields" Bug	12	2301	7. Dezember 2020
Discourse installation has been getting slower and slower and slower Self-hosting server-resources	36	2146	15. April 2023
Help! Upgrade led to complete fail Self-hosting	7	1533	9. März 2021
Restore fails due to disk space on migration because of 70M calendar events Support events	10	355	14. Februar 2026
PostgreSQL Stuck During Rebuilding Self-hosting	51	2879	4. September 2024

'bundle exec rake db:migrate' dauert wegen Kalendermigration lange

Verwandte Themen