Похоже, 2+2 уже может быть недостаточно… Я управляю довольно скромным экземпляром Discourse (без крупных/сложных плагинов и т.д.), который на сегодняшний день не может загрузиться, так как Ember потребляет всю доступную оперативную память, а также весь файл подкачки, из-за чего машина перестаёт отвечать на запросы. Добавление ещё 2 ГБ файла подкачки позволило завершить загрузку, при этом пиковое использование файла подкачки составило около 2,5 ГБ.
Ой, это в списке @david’а для расследования.
@david провёл расследование: мы подтверждаем, что в текущем состоянии 2 ГБ достаточно для пересборки Docker, но недостаточно для работы веб-апгрейдера.
Одна из идей, которую я обдумывал, — это остановка всех процессов Ruby во время работы веб-апгрейдера, чтобы освободить дополнительные 300–500 МБ, чего будет достаточно для предварительной компиляции ассетов.
В долгосрочной перспективе нам, вероятно, потребуется переход на подготовленные контейнеры для самостоятельной установки, что открывает ящик Пандоры: как веб-апгрейдер сможет это реализовать? Мы не хотим монтировать сокеты Docker…
Это действительно сложная ситуация.
Ну, для меня этого не хватило.
Сравнение это между базовой чистой установкой и реальными ситуациями?
Действительно, это не всегда работает идеально. Даже при отключении всего остального сбои всё ещё возможны.
К сожалению, мы ведём проигрышную битву с современными инструментами сборки JavaScript. Они спроектированы для работы на 8 ГБ+ оперативной памяти на современных машинах разработчиков, а не на VPS с 1 ГБ памяти 
У нас уже есть несколько решений в разработке. Например: предоставление готовых ассетов, которые можно автоматически загружать. Основная сложность заключается в плагинах, так как они различаются на каждом сайте, и в данный момент они тесно интегрированы в основную сборку.
Однако на данный момент полная пересборка через CLI должна иметь более высокий процент успеха по сравнению с обновлением через веб-интерфейс.
Как и в случае с Jagster, 2 ГБ ОЗУ + 2 ГБ подкачки на самом деле недостаточно для моей пересборки Docker через CLI. При более детальном проверке выяснилось, что на этой установке установлены только плагины docker_manager и discourse-prometheus — ни один из них, насколько я ожидаю, не создаёт неожиданной нагрузки на Ember.
Если минимальные требования придётся изменить, это будет неприятно, но это всё же лучше, чем текущая ситуация, когда машины неожиданно «умирают» при каждой обновлении.
Если дело обстоит именно так, я считаю, что всё же лучше немного увеличить рекомендуемые характеристики. Лично я не возражаю против добавления ещё 2 (или даже 4) ГБ подкачки, если это повысит надёжность восстановления — по крайней мере, при условии, что ежедневные операции остаются стабильными с 2–4 ГБ ОЗУ (для небольших и средних сообществ).
Действительно, при моей недавней установке на инстансе с 4 ядрами и 4 ГБ ОЗУ начальная установка не удалась. Ed предложил создать файл подкачки. Я нашёл тему о создании файла подкачки и создал файл подкачки размером 4 ГБ. Теперь всё работает как ожидалось как при обновлении/обновлении через веб-интерфейс, так и через CLI.
На мой взгляд, нам, возможно, просто нужно принять, что Discourse требует больше оперативной памяти, чем раньше.
Разве zram не имеет смысла?
Мы только что применили этот коммит, который, надеемся, улучшит ситуацию. Пожалуйста, сообщите нам, как у вас получится! (это отразится на статусе tests-passed в течение следующих ~30 минут)
При тестировании в локальном Docker-контейнере с ограниченным объемом памяти я теперь могу выполнить успешную сборку с параметром -m 1600m. До этого изменения минимально достижимым значением было -m 3000m.
Я выполнил тестовую пересборку (чистая установка), которая прошла без проблем. У этой машины 4 ГиБ оперативной памяти (Hetzner CAX11) и файл подкачки того же размера, так что она, безусловно, менее ограничена, чем описанная выше конфигурация с 2+2 ГиБ. Однако использование подкачки было минимальным на протяжении всей сборки, а максимальное потребление ОЗУ составило ~3,1 ГиБ. В большинстве случаев оно держалось на уровне ~2 ГиБ, так что всё выглядит вполне неплохо (время сборки осталось примерно прежним, то есть около 8 минут).
Я бы очень хотел провести ряд контролируемых экспериментов с чистыми установками и пересборками на различных конфигурациях, и в частности хотел бы увидеть разницу (если она есть) при запуске с перераспределением памяти (vm overcommit), но, боюсь, у меня не было на это времени.
(Без перераспределения памяти большой процесс, который создаёт дочерние процессы через fork, будет иметь мгновенный рост потребления памяти, что может оказаться фатальным, и это не отобразится на мониторинге с опросом. Даже при включённом перераспределении рост потребления памяти может быть настолько быстрым, что не будет заметен при опросе, будь то htop, vmstat или что-то другое.)
Мне кажется, я никогда не видел, чтобы кто-либо добровольно указывал, используют ли они перераспределение памяти, хотя, по моему мнению, это важный аспект конфигурации хоста.
Думаю, большинство людей не указывают.
Я настраиваю это автоматически при установке. Но всё равно получаю предупреждение об этом.
Overcommit здесь не имеет значения, потому что проблема не в преждевременном завершении процессов из-за нехватки памяти (OOM), а в попытке уместить 10 фунтов выделенной памяти в мешок вместимостью 5 фунтов.
На практике невозможно выполнить пересборку Discourse с параметром overcommit_memory=2, поскольку ember (и, несомненно, другие компоненты) заранее выделяет огромные объемы виртуальной памяти (по моим данным, около 80 ГБ), что всегда будет приводить к конфликту с любым разумным значением overcommit_ratio. Установка overcommit_memory=1 также не поможет, поскольку, опять же, проблема не в излишне агрессивном управлении памятью ядром (VMM), а в крайне неэффективном управлении памятью компилятором ember.
Я не совсем согласен с вашим анализом! Насколько я понимаю, overcommit позволяет процессам выделять память, которую они не используют. Речь идёт не только о поведении OOM-killer. Но, как я уже сказал, я хотел бы провести ряд контролируемых экспериментов — это лучший способ понять, что влияет на ситуацию, а что нет.
У меня 4 ГБ оперативной памяти и много плагинов (насколько мне известно, файла подкачки нет). Сколько плагинов у вас, и считаете ли вы, что обычных 4 ГБ оперативной памяти достаточно?
Частично верно, но даже в этом случае это не имеет значения, поскольку проблема, обсуждаемая в этой теме, касается процессов, выделяющих память, к которой они обращаются, и обращаются к большему её объёму, чем доступно в системе, что приводит к сбоям, заметным для клиентов.
Можете подтвердить, что после изменений @david требования к памяти снизились? Мы должны сейчас находиться в приемлемом состоянии.
Следующий крупный шаг — предварительная компиляция и распространение предварительно скомпилированных ресурсов. Это довольно значительное изменение, но после его реализации мы избавимся от большого объема работы в интернете.
С уважением, я не уверен в этом. Я видел файлы журналов, показывающие сбои при создании дочерних процессов. В этой ветке мы говорим о «требованиях к памяти», но это, на мой взгляд, включает и стратегии ядра для виртуальной памяти. Очевидно, что один или два эксперимента покажут, прав я или нет в вопросе перераспределения памяти.
Это была свежая сборка без каких-либо плагинов. Я могу попробовать другую с включёнными несколькими плагинами и, возможно, временно отключить файл подкачки, чтобы убедиться, что сборка проходит успешно (хотя, скорее всего, у меня появится время на это только через несколько дней).