Хорошо, я понимаю это. Неужели невозможно оптимизировать процесс инициализации/компиляции так, чтобы он занимал больше времени (по CPU/последовательности), но укладывался в ограниченные ресурсы (например, ОЗУ)?
Я думаю, что это отличная идея. Одна из причин заключается в следующем: если нельзя выполнить сборку на маленьком сервере, то и установить на нём тоже нельзя. А если установка производится на сервере среднего размера, то файл подкачки, который понадобится на маленьком сервере, не будет создан. (В идеале скрипт установки должен всё равно создавать файл подкачки, а также устанавливать два параметра ядра, которые должны быть настроены.)
Это тоже отличная идея. Точно так же, как в идеале процесс разработки программного обеспечения отслеживает время сборки, чтобы время сборки не росло бесконечно, для Discourse в идеале процесс должен тестировать и отслеживать возможность установки на малых инстансах. Сделайте это целью.
Я экспериментировал с созданием образов с загрузкой зависимостей, которые мигрируют и прекомпилируют ассеты при запуске (с настройками ENV для пропуска этих задач). В целом это работает (хотя не очень хорошо для огромных сайтов и для случаев, когда запуск должен произойти за определённое время.
Однако при этом требуется наличие Redis и PostgreSQL.
При установке в виде двух контейнеров по стандартной схеме, возможно, удастся добиться почти полной работоспособности.
Оооооооооооооо, но, похоже, именно этап прекомпиляции ассетов вызывает проблемы…
Я читаю об обновлении Ember 5, которое постепенно внедряется в систему. Какое влияние это окажет на ресурсы сборки?
Кажется, документацию нужно обновить: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
- По умолчанию 1 ГБ оперативной памяти достаточно для небольших сообществ Discourse.
1 ГБ больше не является допустимым вариантом. Минимальное требование — 2 ГБ для сборки Discourse.
У меня есть несколько сайтов, которые я недавно обновил с 1 ГБ оперативной памяти. Правда, я увеличил файл подкачки до 3 или 4 ГБ.
Я, конечно, не рекомендую это делать, но для некоторых людей стоимость — серьёзное препятствие, и они как-то справляются. Но, возможно, фраза «работает отлично» — это преувеличение.
Да, возможно, стоит уточнить: 1 ГБ ОЗУ + 4 ГБ подкачки. С 2 ГБ подкачки это не сработало.
У вас есть плагины? Много тем?
9 плагинов и всего одна тема. Всё это отлично работало до версии 3.1.x на системе с 1 ГБ ОЗУ и 2 ГБ подкачки (работала немного медленно, перестроение занимало около 20 минут, но всегда завершалось успешно). При попытке обновиться до версии 3.2.0 обновление неизменно завершалось ошибкой (см. выше).
Да. Точно никаких плагинов с 1 ГБ ОЗУ. Это, кажется, стоит добавить в документацию по установке.
Мне было бы интересно узнать, работало ли это без плагинов.
Как крайне краткое резюме, я понимаю, почему вы так говорите, но не согласны ли вы, что критерием «запускать/не запускать» Discourse является именно сумма RAM и swap? С точки зрения решения «запускать/не запускать» 1+3 так же хорошо, как и 2+2.
Только производительность (отзывчивость) зависит от того, сколько у вас оперативной памяти.
Правильно проверять и тестировать именно RAM+swap. Память = RAM + swap.
Кстати, если что-то не работает, и нет очевидных причин, почему это происходит, особенно если вы подозреваете нехватку памяти, стоит проверить наличие убийцы процессов из-за нехватки памяти, также известного как OOM-killer. Я рекомендую выполнить:
dmesg|egrep -i "memory|oom|kill"
Редактирование: для удобства я добавлю это в свой список стандартных мгновенных диагностических команд:
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
Я столкнулся с той же проблемой, но не во время обновления, а при чистой установке версии 3.2.0.
Я использую AWS EC2, так же как и @RBoy.
Я ищу решение для установки версии 3.1.5 вместо 3.2.0, так как старый форум не предоставил никакой помощи.
ОБНОВЛЕНИЕ:
извините, я нашел это:
Меня очень заинтересовало бы узнать, удалось ли вам выполнить чистую установку версии 3.1.5, используя метод с тегом, упомянутый в вашей ссылке. Пожалуйста, сообщите, если попробуете это сделать.
Что касается установки версии 3.2.0 на системе с 1 ГБ памяти, вы можете попробовать следующее: установите размер SWAP-раздела в 8 ГБ и посмотрите, сработает ли это. Скорее всего, система будет работать очень медленно, но возможно, всё получится.
Спасибо за ваши подробные рекомендации.
Недавно я выполнил чистую установку версии Discourse 3.15 в Docker и хотел поделиться тем, насколько простым был этот процесс, особенно для тех, кто использует бесплатный уровень AWS EC2, как и я.
Вот краткое руководство, основанное на моем опыте:
-
Перейдите к файлу конфигурации Discourse, расположенному по пути
/var/discourse/containers/app.yml. -
В секции
paramsобновите параметр версии, чтобы он соответствовал нужной версии Discourse. Например:params: # ... ## Укажите ревизию Git для этого контейнера (по умолчанию: tests-passed) version: v3.1.5 # Укажите здесь конкретный тег -
Сохраните изменения и выйдите из редактора. Затем выполните следующую команду для пересборки вашего приложения Discourse:
/var/discourse/launcher rebuild app
Этот процесс прошел для меня без сбоев, что доказывает: поддержка установки Discourse с минимальными затратами или даже с нулевым бюджетом вполне реальна.
Надеюсь, это руководство поможет другим, кто стремится эффективно и экономично управлять своими установками Discourse.