Всем привет, надеюсь на помощь!
Кто-нибудь сталкивался с этим раньше?
Команда ./launcher rebuild app выполняется, доходит до этой точки и просто зависает.
Сейчас что-то происходит, но это занимает невероятно много времени. Я уже 3 года запускаю форум на самостоятельно установленном Droplet от DigitalOcean, но такое поведение для меня ново и вызывает много простоев. Есть ли способ ускорить этот процесс? Может быть, дело в изображениях на форуме или в чём-то другом?
Не могли бы вы открыть еще одну сессию SSH и попытаться определить, какая миграция вызывает проблемы?
Команда вроде ps aux | grep postgres должна показать начало процесса.
Я не эксперт по Linux (или, если честно, даже не любитель), но попробую.
Мой прогноз — нехватка памяти. Попробуйте выполнить
free -h
Также можно попробовать
du -hs /var/discourse/shared/standalone/*
Память (ОЗУ) или место на диске?
Должно быть много и того, и другого, я так думаю — Droplet: 8 ГБ памяти / 4 виртуальных ядра Intel / 160 ГБ диска + 200 ГБ / Ubuntu 18.04.3 (LTS) x64
«Безопасно» ли открыть ещё одну сессию SSH и запустить эти команды, пока db:migrate ещё выполняется?
На вашем месте я бы начал с получения нового VPS с ОС, которая всё ещё имеет активную поддержку.
Да.
Хорошо — пожалуйста, поймите, что я НЕ эксперт по Linux — ваш пост намекает, что текущая сборка Ubuntu сильно устарела и т.д.?
Да, ОС вышла в апреле 2018 года и поддерживалась в течение 5 лет, поэтому поддержка закончилась более 6 месяцев назад.
Спасибо за информацию.
Как человек, который открыто признает, что он любитель, делающий всё возможное, — есть ли у вас какие-либо рекомендации, что мне делать дальше?
Команда db:migrate не сработала — сообщение об ошибке:
client_loop: send disconnect: Connection reset
После повторного входа вы абсолютно правы:
Доступен новый релиз ‘20.04.6 LTS’.
Запустите ‘do-release-upgrade’ для обновления до него.
Учитывая, что мой форум сейчас недоступен, безопасно ли мне выполнить обновление, а затем заняться восстановлением форума? Или мне сначала попробовать вернуть форум в онлайн?
Это ошибка SSH…
Вы сделали резервную копию перед обновлением? Если да, то проще всего будет получить новый сервер с Ubuntu 22, установить Discourse и восстановить резервную копию.
Увы, один из моих администраторов нажал кнопку обновления на сайте, и, похоже, оно не прошло, после чего всё сломалось. 
Последняя резервная копия была сделана вчера — так что не так уж и плохо.
Правильно ли я понимаю, что обновление существующего сервера сотрёт текущую установку?
(Спасибо за ваше терпение, @RGJ)
Сложно сказать наверняка, но поскольку возникают сбои, я бы не стал рисковать. По крайней мере, не убедившись, что резервная копия надёжно сохранена в безопасном месте.
Вполне вероятно, что вы сможете создать новую виртуальную машину, остановить контейнер (похоже, он всё равно не запущен), затем с помощью rsync скопировать все данные на новый сервер и попробовать снова. Это, скорее всего, позволит вам восстановить работу без потери данных.
Всё звучит так просто, но, чёрт возьми, я чувствую себя здесь не в своей тарелке. Сейчас это работает на Droplet от DigitalOcean. Так что запуск новой ВМ — это уже вопрос с подвохом? На том же Droplet? Или на новом? 
Виртуальная машина (ВМ) — это общепринятый термин для того, что DigitalOcean называет «дропплетом».
Кажется, вам стоит взглянуть на мой профиль и рассмотреть вариант управляемого хостинга 
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 показывает, что процесс discourse [local] delete потребляет 100% процессорного времени. У дроплета 8 ГБ оперативной памяти, и в данный момент используется менее 1 ГБ (без учёта буферов).
Операционная система устарела, но это кажется мне очень странным. Памяти и места на диске достаточно, а задача postgres delete выполняется уже более 12 минут. Записей меньше 600 тысяч, а пользователей — менее 4 тысяч, так что база данных не огромная. О, подождите. Каталог postgres_data занимает 28 ГБ.
Я выполнил команду VACUUM VERBOSE ANALYZE;.
Вот что я сделал:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
Сейчас я пытаюсь выполнить параллельную реиндексацию. Возможно, вакуум и реиндексация помогут.
Спасибо, Джей. Дай знать, если тебе что-то нужно от меня.
Пожалуйста, предоставьте полный SQL-запрос для этого долго выполняющегося запроса.
Где я могу это найти?
Миграция не выводит никаких логов. Последняя строка в rebuild:
I, [2023-12-04T22:33:33.759401 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
Я собираю полный лог для только что перезапущенного экземпляра.
Войдите в контейнер, переключитесь на пользователя postgres, запустите psql и выполните:
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;