'bundle exec rake db:migrate' richiede molto tempo a causa della migrazione del calendario

Supporto Installazione
16 
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: checkpointer 
systemd+  7668  0.3  0.9 352060 78796 ?        Ss   22:31   0:03 postgres: 13/main: background writer 
systemd+  7669  0.0  0.1 352060 13696 ?        Ss   22:31   0:00 postgres: 13/main: walwriter 
systemd+  7670  0.0  0.1 352728 11892 ?        Ss   22:31   0:00 postgres: 13/main: autovacuum launcher 
systemd+  7671  0.0  0.0  67996  5320 ?        Ss   22:31   0:00 postgres: 13/main: stats collector 
systemd+  7672  0.0  0.0 352612  6640 ?        Ss   22:31   0:00 postgres: 13/main: logical replication launcher 
systemd+ 10900 82.0  3.8 487164 317728 ?       Rs   22:33  10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901  0.0  0.1 353432 13804 ?        Ss   22:33   0:00 postgres: 13/main: discourse discourse [local] idle

htop mostra che il discourse [local] delete sta consumando il 100% della CPU. Il droplet ha 8GB di RAM e al momento viene utilizzata meno di 1GB (senza contare i buffer).

Il sistema operativo è obsoleto, ma questo mi sembra molto strano. C’è molta RAM e disco, e quel task di delete di postgres è in esecuzione da oltre 12 minuti. Ci sono meno di 600K post e meno di 4K utenti, quindi il database non è enorme. Oh. Aspetta. la directory postgres_data è di 28GB.

Ho eseguito un VACUUM VERBOSE ANALYZE;.

Ho fatto questo:

discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; 
 checkpoints_timed | checkpoints_req 
-------------------+-----------------
                 6 |              20

Sto ora provando a fare un reindex concorrente. Forse il vacuum e il reindex aiuteranno.