Сейчас перезагрузку сделать не могу, отпишусь, как только будет возможность. Это займёт как минимум несколько дней.
Стоит ли мне беспокоиться? Я могу выделить больше ресурсов, если нужно.
Да, вам стоит беспокоиться.
У вас практически нет запаса прочности, и почти не остаётся места для дискового кэширования.
Но прежде чем выделять дополнительные ресурсы, стоит выяснить, что вызывает такое необычно высокое потребление памяти.
Сейчас мало что могу сделать, я в пути. Вернусь к этому в эти выходные и обязательно постараюсь разобраться, что происходит. Спасибо за подсказку 
Похоже, проблема была вызвана лишь просроченной перезагрузкой. Удалось перезагрузить сервер, и на данный момент показатели выглядят гораздо-гораздо лучше.
root@discourse:~# free
total used free shared buff/cache available
Mem: 3927308 977624 2246208 42880 703476 2646836
Swap: 2097148 0 2097148
Это может быть полезно, если вы снова окажетесь в подобной ситуации: спросите Discourse, какие процессы используют память. Вывод по адресу
https://example.com/admin/upgrade#/processes
отсортирован по объему используемой оперативной памяти. На мой взгляд, это покажет только процессы, запущенные внутри контейнера. В командной строке вы можете использовать
ps aux | sort -nr -k 4 | head -22
или аналогичную команду, чтобы увидеть использование памяти всеми процессами, включая те, что запущены во всех контейнерах.
Если перезагрузка решает проблему нехватки памяти, с большой долей вероятности где-то есть какой-то процесс-«беглец», который будет наращивать потребление (возможно, медленно), пока не начнутся проблемы.
Редактирование: Хм, я вижу, что упомянул просмотр процессов по использованию оперативной памяти (RSS). Это может быть полезно, но в данном случае нас больше интересует использование виртуальной памяти: для этого нужно сортировать по столбцу VSZ, то есть по столбцу 5.
Этот экземпляр Discourse был настроен много лет назад, возможно, до внедрения проверки файла подкачки. Я вручную добавил указанные строки кода, и файл подкачки теперь создан. Спасибо.
Чтобы Docker использовал файл подкачки, нужно ли применять это? Или, скорее, в чем смысл этой рекомендации?
Я нашел материал, объясняющий, что такое vm.overcommit_memory, но мне непонятно, зачем вообще нужны подобные изменения:
Это связано с запуском Redis, а не с обновлением Discourse.
Думаю, дело не только в этом — позвольте мне объяснить. Рекомендация исходит от Redis, и она основана на том, что создание дочернего процесса (fork) требует значительного объёма виртуальной памяти. Redis использует fork для выполнения фонового сохранения данных, однако заявленная виртуальная память никогда не понадобится.
Это типично для многих Unix-приложений: они создают дочерние процессы, но не удваивают при этом потребление памяти. Поскольку такая ситуация распространена, а данное ядро системы меняет поведение для всех процессов во всех контейнерах, такая настройка может превратить сбой в успех, особенно когда виртуальная память испытывает нагрузку.
На небольших и недорогих экземплярах, которые используют многие из нас, виртуальная память часто оказывается под нагрузкой. Особенно это заметно во время обновлений или пересборки системы.
Поэтому изменение этой настройки может повлиять на то, завершится ли обновление успешно или нет, особенно если недавно были внесены изменения, увеличившие нагрузку на виртуальную память.
По умолчанию ядро отклоняет запросы на выделение памяти, которые не может удовлетворить. При включении этой настройки оно будет принимать такие запросы, что может предотвратить сбой, либо сбой может произойти позже, когда выделенная память действительно потребуется.
Если сумма оперативной памяти (RAM) и подкачки (swap) достаточно велика, вам никогда не потребуется менять эту настройку. Если же её недостаточно, изменение настройки может помочь.
Команда free покажет, сколько памяти подкачки настроено и сколько из неё используется. Я думаю, вы обнаружите, что она начнёт использоваться сразу после запуска этих команд.
Это делается для увеличения доступного объёма виртуальной памяти. (То есть суммы оперативной памяти и памяти подкачки.) Если оперативная память закончится, начнутся проблемы с производительностью. Но если закончится виртуальная память, процессы не смогут запуститься или будут завершены или убиты. Это становится суровым.
Те из нас, у кого и мало оперативной памяти, и мало места на диске, могут не иметь возможности добавить много памяти подкачки, но 2 ГБ, похоже, является хорошим минимумом. (Если бы у вас было 16 ГБ оперативной памяти, возможно, вам вообще не понадобилась бы память подкачки, но это уже другая история. Важна именно сумма обоих показателей, когда проблема заключается в сбоях процессов.)
Ага. Кажется, я это в общих чертах понял, но объяснение отличное. Вот почему я устанавливал это для каждой установки, которую делал виртуальной машины, которую создавал для клиентов.
Интересно, не стоит ли заставить discourse-setup изменять эти настройки при создании swap-раздела.