Это не моя проблема, но значит ли это, что больше ничего нет?
Возможно, не специально, но стоит проверить содержимое хоста на наличие процессов криптомайнинга и т.д.
Шаг 1: исправьте уже выявленную проблему производительности, связанную с использованием драйвера vfs
Что касается этого перехода к (в идеале) overlay2, мне придётся удалить текущую установку и переустановить всё заново. Это связано с тем, что на текущем хосте поддерживаются только fuse-overlayfs или vfs, ни один из которых не рекомендуется.
Однако скоро там включат KVM-окружения, поддерживающие overlay2.
Поэтому я планирую использовать именно его, а не также не рекомендуемый fuse-overlayfs.
Теперь, в самом приложении Discourse, я могу создавать резервные копии. Что именно сохраняется в такой копии?
Потеряю ли я что-либо из текущего форума Discourse (имею в виду сообщения, чаты, настройки, пользователей, загруженные изображения и т. д.), если сделаю резервную копию, переустановлю чистый Discourse на новом сервере, а после начальной настройки Discourse заменю его этой резервной копией?
Сработает ли это?
Да, это сработает.
Единственное, о чём вы не упомянули, — это убедиться, что на новом Discourse установлены те же плагины, что и на текущем. Если вы переиспользуете свой app.yml, то у вас тоже всё будет в порядке.
Понятно, спасибо, что указали на это, я бы наверняка столкнулся с этой проблемой.
Так вот…
- Создайте резервную копию в административной панели Discourse.
- Для надёжности, конечно же, создайте резервную копию сервера.
- Сохраните копию YAML-файла.
- Создайте дамп сервера.
- Настройте новый сервер с поддержкой необходимых технологий.
- Установите Docker с правильным драйвером хранилища.
- Разверните полную свежую копию Discourse, используя сохранённый YAML-файл.
- Восстановите Discourse из резервной копии.
Чуть удивлён, что размер резервной копии составляет всего 19,2 МБ. У нас уже загружено несколько изображений и других файлов… но, думаю, мне остаётся только попробовать.
Попробую это сделать в выходные и отчитаюсь, сработал ли смена драйвера хранилища.
Проверьте, что это установлено:
Обратите внимание, что эта конкретная настройка применяется только к запланированным резервным копиям, а не к ручным. При создании ручных резервных копий вам всегда предоставляется явный выбор.
Ещё одна настройка, которую следует включить, — включать миниатюры в резервные копии.
@smileBeda, я бы отложил задачу #4 до тех пор, пока всё не будет работать корректно.
Действительно, эта опция отмечена, но Включать сгенерированные миниатюры в резервные копии. Отключение этого параметра уменьшит размер резервных копий, но потребует повторной обработки всех сообщений после восстановления. — нет.
@RGJ … да, хорошая идея, потребуется больше шагов, так как мне нужно будет создать сервер под новым юридическим лицом, но это мелочь по сравнению с риском.
Я запущу автоматическое создание резервной копии, чтобы включить в неё все данные, так как, насколько я понимаю, ручная не будет включать изображения и т. д.
Спасибо…
Это неверное предположение.
При ручном создании резервной копии во всплывающем окне вам будет предложено выбрать: создать резервную копию только базы данных или включить загрузки.
При создании запланированных резервных копий это определяет настройка «Резервное копирование с загрузками».
Хорошо, я неправильно понял вашу предыдущую фразу: «Обратите внимание, что данная настройка применяется только к запланированным резервным копиям, а не к ручным».
Спасибо…
Привет! Я возвращаюсь к этой теме, так как она ещё открыта, и у нас возникла та же проблема после миграции на новый виртуальный сервер. Как и все остальные, я обычно тратил не более 20 минут на пересборку нашего Discourse, но на этом новом сервере процесс занимает часы, хотя у него в два раза больше ресурсов, чем у предыдущего. 
Я просмотрел другие темы на Meta, посвящённые долгим обновлениям, но не могу понять, в чём проблема именно у нас:
Сервер: 4 ГБ ОЗУ, 2 ядра CPU, 50 ГБ диска.
Swap:
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker:
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Мне всё кажется нормальным, но, возможно, я что-то упускаю. Куда ещё можно посмотреть?
Возможно, «шумный сосед» замедляет работу вашей новой ВМ по сравнению со старой, потому что он использует весь процессор, который вы не получаете?
Да, спасибо, успокаивает, что опытный администратор, такой как вы, не видит ничего очевидного в приведенной выше информации. И да, мы начинаем проверять физический сервер и нашу виртуальную среду. По крайней мере, форум работает без проблем, заметных для пользователей. Мы сталкиваемся с этой серьёзной проблемой производительности только при перестроении. Вчера у нас ушло 4 часа на перестроение. 
Если бы у меня была эта проблема, я бы открыл два или три окна терминала. Одно для запуска пересборки, второе для записей о прошедшем времени и фиксации моментов, когда происходят длительные задержки между обновлениями логов, и третье для отслеживания активности системы — скорее всего, с помощью команды vmstat 5.
Когда вы дойдёте до точки, где лог не обновляется подозрительно долго, запишите показатели активности, которые показывает vmstat.
Опубликуйте здесь подходящие фрагменты лога вместе с вашими заметками и соответствующим выводом vmstat.
Выглядит очень вероятным, что время тратится на определённые этапы пересборки: нужно выяснить, какие именно, и посмотреть, что делает машина в эти моменты.
Я бы также делал снимок активности системы с помощью команды ps auxf во время таких пауз.
Спасибо, это очень хороший совет. В следующий раз, когда нам потребуется пересобрать, мы сделаем это именно так.