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 muestra que el discourse [local] delete es lo que está consumiendo el 100% de la CPU. El droplet tiene 8 GB de RAM y ahora mismo se usa <1 GB (sin contar los búferes).
El sistema operativo está desactualizado, pero esto me parece muy extraño. Hay mucha RAM y disco, y esa tarea de eliminación de postgres ha estado ejecutándose durante >12 minutos. Hay menos de 600K publicaciones y <4K usuarios, por lo que la base de datos no es enorme. Oh. Espera. el directorio postgres_data tiene 28 GB.
Ejecuté un VACUUM VERBOSE ANALYZE;.
Hice esto:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
Ahora estoy intentando reindexar concurrentemente. Quizás el vacuum y el reindex ayuden.