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…

There’s a decent chance that you could spin up a new VM, stop the container (sounds like it’s not runnnig anyway) then rsync everything to the new server and try again there. That can likely get you back up and running without losing any data.

It all sounds so simple, but man am I feeling out of my depth here. It’s currently running on a digital ocean droplet. So spinning up a new VM - that’s a loaded sentence? On the same droplet? On a new one? :woozy_face:

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:

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

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

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

'bundle exec rake db:migrate' prend beaucoup de temps en raison de la migration du calendrier

Soutien Installation

Falco (Falco) Décembre 4, 2023, 11:39 18

Veuillez partager tout le SQL de la requête longue durée.

Sujet		Réponses	Vues
Database migration chokes on huge value of a "calendar-details" item in table "post_custom_fields" Bug	12	2301	Décembre 7, 2020
Discourse installation has been getting slower and slower and slower Self-hosting server-resources	36	2144	Avril 15, 2023
Help! Upgrade led to complete fail Self-hosting	7	1533	Mars 9, 2021
Restore fails due to disk space on migration because of 70M calendar events Support events	10	355	Février 14, 2026
PostgreSQL Stuck During Rebuilding Self-hosting	51	2879	Septembre 4, 2024

'bundle exec rake db:migrate' prend beaucoup de temps en raison de la migration du calendrier

Sujets connexes