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 zeigt, dass der discourse [local] delete 100% CPU verbraucht. Das Droplet hat 8 GB RAM, und derzeit wird weniger als 1 GB verwendet (Puffer nicht mitgerechnet).
Das Betriebssystem ist veraltet, aber das erscheint mir sehr seltsam. Es gibt reichlich RAM und Festplattenspeicher, und diese Postgres-Löschaufgabe läuft seit über 12 Minuten. Es gibt weniger als 600.000 Beiträge und weniger als 4.000 Benutzer, daher ist die Datenbank nicht riesig. Oh. Warte. Das Verzeichnis postgres_data ist 28 GB groß.
Ich habe VACUUM VERBOSE ANALYZE; ausgeführt.
Ich habe Folgendes getan:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
Ich versuche jetzt, gleichzeitig neu zu indizieren. Vielleicht helfen das Vacuum und die Neuindizierung.