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

Soutien Installation
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 montre que discourse [local] delete est ce qui consomme 100% du CPU. Le droplet a 8 Go de RAM, et actuellement moins de 1 Go est utilisé (sans compter les buffers).

L’OS est obsolète, mais cela me semble très étrange. Il y a beaucoup de RAM et de disque, et cette tâche de suppression postgres s’exécute depuis plus de 12 minutes. Il y a moins de 600K posts et moins de 4K utilisateurs, donc la base de données n’est pas énorme. Oh. Attendez. Le répertoire postgres_data fait 28 Go.

J’ai exécuté un VACUUM VERBOSE ANALYZE;.

J’ai fait ceci :

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

J’essaie maintenant de réindexer en mode concurrent. Peut-être que le vacuum et le réindex aideront.