Обновление через /admin/upgrade занимает *очень* много времени

Внести вклад Ошибка
1

При обновлении одного плагина через admin/upgrade процесс занимает очень много времени.

Обычно полная пересборка занимает около 7 минут.

Обновление началось 2023-03-02T20:07:00Z, текущий статус:

image
image1209×628 171 KB

Вывод HTOP:

image
image927×202 48.7 KB

РЕДАКТИРОВАНО: 2023-03-02T20:44:00Z — всё ещё на той же строке лога. Загрузка процессора без изменений. В этот момент была запущена пересборка через CLI.

РЕДАКТИРОВАНО 2: Для точного указания времени, необходимого на пересборку на моём компьютере, отметка времени завершения пересборки: 2023-03-02T20:51:00Z

4 лайка
2

Да, я сталкиваюсь с тем же уже как минимум со вчерашнего дня.

В данный момент практически невозможно выполнить обновление через экран обновления за разумное время, поэтому вам придётся обновляться через командную строку.

3

Пересборка CLI завершена.

Обновление администратора всё ещё зависло, и похоже, что плагин не обновлён.

image
image386×168 6.51 KB

Я нажал «СБРОСИТЬ ОБНОВЛЕНИЕ» и запустил ещё одну пересборку CLI.

1 лайк
4

Я тоже, у меня точно такая же проблема. Очень раздражает при обновлении плагинов — это занимает действительно очень много времени — чрезвычайно неудобно.

2 лайка
5

Есть ли какое-то обходное решение для этого? Каждый раз, когда я обновляюсь, чтобы не отставать от изменений в Discourse Chatbot :robot: (поддержка ChatGPT) — плагин — Discourse Meta, это занимает очень-очень много времени.

6

Это всё ещё проблема.

Однако, похоже, она затрагивает только серверы с более низкой конфигурацией?

1 лайк
9

Просто добавлю свой голос, а не ответы… :slight_smile:

У меня есть крошечный тестовый сайт на DO с объёмом 1 ГБ и множеством плагинов, так что обычно он работает не слишком быстро. Однако, мне кажется, в последнее время он стал работать ещё медленнее, и на днях мой сайт попал в какую-то странную ситуацию, как и у @MarcP, поэтому нам пришлось его перезагрузить.

Раньше я никогда не засекал время, но сегодня я нажал «Обновить всё» и записал время нажатия кнопки. На данный момент процесс начался в 9:30 утра и всё ещё идёт в 10:15. Сейчас он упаковывает некоторые ресурсы. Могу с уверенностью сказать, что обычно на выполнение этой задачи уходит не более 45 минут.

Кажется, возникли проблемы с правами доступа при удалении временных файлов? Не уверен, имеет ли это какое-то значение.

4 лайка
11

@david и я нашли корневую причину (похожую на ту, что @Falco обнаружил ранее).

Мы используем специальные флаги Ruby, чтобы попытаться ограничить потребление памяти во время обновлений, но это больше не работает в Ruby 3.2.

Вскоре должен появиться PR для исправления этой проблемы.

7 лайков
12
7 лайков
13

Обратите внимание: чтобы исправление вступило в силу, возникает небольшая проблема «курица и яйцо». При запуске обновления ещё загружается старый код.

Возможно, потребуется выполнить ./launcher rebuild в первый раз; в дальнейшем веб-обновление будет работать без проблем.

Обойти это просто невозможно. @cvx, это сложная задача… Технически мы должны сделать так, чтобы DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade вызывал внешний процесс и запускал новый код обновителя при обновлении… но это открывает ящик Пандоры.

Быстрое решение

  1. Начните обновление Docker Manager.
  2. Отмените его, когда процесс зависнет.
  3. Выполните ./launcher restart app из командной строки.
  4. Обновление через веб-интерфейс заработает.

Простое решение

  1. Выполните ./launcher rebuild app.

После этого всё будет в порядке.

РЕДАКТИРОВАНИЕ

Закрываю эту тему превентивно, так как хочу, чтобы это был последний пост по данной теме. Это упростит поиск решений для пользователей. Если проблема сохраняется после rebuild, отметьте сообщение флагом для reopen.

8 лайков