# Не удалось обновить экземпляр Discourse до версии от 15 февраля 2022 года
**URL:** https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204
**Category:** Self-hosting
**Tags:** server-resources
**Created:** [15.Февраль.2022 06:10:07 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204 "2022-02-15T06:10:07Z")
**Posts on this page:** 11
**Page:** 2
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [15.Февраль.2022 15:55:22 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/22 "2022-02-15T15:55:22Z")
Сейчас перезагрузку сделать не могу, отпишусь, как только будет возможность. Это займёт как минимум несколько дней.
> [@RGJ](#):
>
> Это не так уж много
Стоит ли мне беспокоиться? Я могу выделить больше ресурсов, если нужно.
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [15.Февраль.2022 15:58:13 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/23 "2022-02-15T15:58:13Z")
> [@itsbhanusharma](#):
>
> Мне стоит беспокоиться? Я могу выделить больше ресурсов, если нужно.
Да, вам стоит беспокоиться.
У вас практически нет запаса прочности, и почти не остаётся места для дискового кэширования.
Но прежде чем выделять дополнительные ресурсы, стоит выяснить, что вызывает такое необычно высокое потребление памяти.
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [15.Февраль.2022 16:01:00 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/24 "2022-02-15T16:01:00Z")
Сейчас мало что могу сделать, я в пути. Вернусь к этому в эти выходные и обязательно постараюсь разобраться, что происходит. Спасибо за подсказку 👍
---
### Author:  [@itsbhanusharma](https://meta.discourse.org/u/itsbhanusharma)
#### Post date: [15.Февраль.2022 16:42:21 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/25 "2022-02-15T16:42:21Z")
Похоже, проблема была вызвана лишь просроченной перезагрузкой. Удалось перезагрузить сервер, и на данный момент показатели выглядят гораздо-гораздо лучше.
```plaintext
root@discourse:~# free
total used free shared buff/cache available
Mem: 3927308 977624 2246208 42880 703476 2646836
Swap: 2097148 0 2097148
```
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [15.Февраль.2022 16:53:39 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/26 "2022-02-15T16:53:39Z")
Это может быть полезно, если вы снова окажетесь в подобной ситуации: спросите Discourse, какие процессы используют память. Вывод по адресу
[https://example.com/admin/upgrade#/processes](https://example.com/admin/upgrade#/processes)
отсортирован по объему используемой оперативной памяти. На мой взгляд, это покажет только процессы, запущенные внутри контейнера. В командной строке вы можете использовать
```plaintext
ps aux | sort -nr -k 4 | head -22
```
или аналогичную команду, чтобы увидеть использование памяти всеми процессами, включая те, что запущены во всех контейнерах.
Если перезагрузка решает проблему нехватки памяти, с большой долей вероятности где-то есть какой-то процесс-«беглец», который будет наращивать потребление (возможно, медленно), пока не начнутся проблемы.
Редактирование: Хм, я вижу, что упомянул просмотр процессов по использованию оперативной памяти (RSS). Это может быть полезно, но в данном случае нас больше интересует использование виртуальной памяти: для этого нужно сортировать по столбцу VSZ, то есть по столбцу 5.
---
### Author:  [@balupton](https://meta.discourse.org/u/balupton)
#### Post date: [16.Февраль.2022 01:13:43 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/27 "2022-02-16T01:13:43Z")
> [@david](#):
>
> Вам потребуется минимум 1 ГБ ОЗУ + 2 ГБ файла подкачки (согласно [нашему стандартному скрипту установки](https://github.com/discourse/discourse_docker/blob/main/discourse-setup#L199-L203))
Этот экземпляр Discourse был настроен много лет назад, возможно, до внедрения проверки файла подкачки. Я вручную добавил указанные строки кода, и файл подкачки теперь создан. Спасибо.
Чтобы Docker использовал файл подкачки, нужно ли применять это? Или, скорее, в чем смысл этой рекомендации?
> [@balupton](#):
>
> ```plaintext
> 103:M 15 Feb 2022 06:54:18.720 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
>
> ```
Я нашел материал, объясняющий, что такое `vm.overcommit_memory`, но мне непонятно, зачем вообще нужны подобные изменения:
> **[7.5. Configuring System Memory Capacity | Performance Tuning Guide | Red Hat...](https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/performance_tuning_guide/sect-red_hat_enterprise_linux-performance_tuning_guide-configuration_tools-configuring_system_memory_capacity)**
>
> 7.5. Configuring System Memory Capacity | Performance Tuning Guide | Red Hat Enterprise Linux | 7 | Red Hat Documentation
---
### Author:  [@RGJ](https://meta.discourse.org/u/RGJ)
#### Post date: [16.Февраль.2022 08:16:24 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/28 "2022-02-16T08:16:24Z")
> [@balupton](#):
>
> `добавить 'vm.overcommit_memory = 1' в /etc/sysctl.conf`
> Или, скорее, в чём смысл этой рекомендации?
Это связано с запуском Redis, а не с обновлением Discourse.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [16.Февраль.2022 11:27:36 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/29 "2022-02-16T11:27:36Z")
> [@RGJ](#):
>
> Это связано с запуском Redis, а не с обновлением Discourse.
Думаю, дело не только в этом — позвольте мне объяснить. Рекомендация исходит от Redis, и она основана на том, что создание дочернего процесса (fork) требует значительного объёма виртуальной памяти. Redis использует fork для выполнения фонового сохранения данных, однако заявленная виртуальная память никогда не понадобится.
Это типично для многих Unix-приложений: они создают дочерние процессы, но не удваивают при этом потребление памяти. Поскольку такая ситуация распространена, а данное ядро системы меняет поведение для всех процессов во всех контейнерах, такая настройка может превратить сбой в успех, особенно когда виртуальная память испытывает нагрузку.
На небольших и недорогих экземплярах, которые используют многие из нас, виртуальная память часто оказывается под нагрузкой. Особенно это заметно во время обновлений или пересборки системы.
Поэтому изменение этой настройки может повлиять на то, завершится ли обновление успешно или нет, особенно если недавно были внесены изменения, увеличившие нагрузку на виртуальную память.
По умолчанию ядро отклоняет запросы на выделение памяти, которые не может удовлетворить. При включении этой настройки оно будет принимать такие запросы, что может предотвратить сбой, либо сбой может произойти позже, когда выделенная память действительно потребуется.
Если сумма оперативной памяти (RAM) и подкачки (swap) достаточно велика, вам никогда не потребуется менять эту настройку. Если же её недостаточно, изменение настройки может помочь.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [16.Февраль.2022 11:43:20 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/30 "2022-02-16T11:43:20Z")
> [@balupton](#):
>
> Чтобы Docker использовал файл подкачки, нужно ли мне применить это?
Команда `free` покажет, сколько памяти подкачки настроено и сколько из неё используется. Я думаю, вы обнаружите, что она начнёт использоваться сразу после запуска этих команд.
> [@balupton](#):
>
> Или, скорее, в чём смысл этой рекомендации?
Это делается для увеличения доступного объёма виртуальной памяти. (То есть суммы оперативной памяти и памяти подкачки.) Если оперативная память закончится, начнутся проблемы с производительностью. Но если закончится виртуальная память, процессы не смогут запуститься или будут завершены или убиты. Это становится суровым.
Те из нас, у кого и мало оперативной памяти, и мало места на диске, могут не иметь возможности добавить много памяти подкачки, но 2 ГБ, похоже, является хорошим минимумом. (Если бы у вас было 16 ГБ оперативной памяти, возможно, вам вообще не понадобилась бы память подкачки, но это уже другая история. Важна именно сумма обоих показателей, когда проблема заключается в сбоях процессов.)
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [16.Февраль.2022 12:04:13 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/31 "2022-02-16T12:04:13Z")
> [@Ed\_S](#):
>
> В исходном виде ядро отклоняет запросы на выделение памяти, которые не может удовлетворить. С этой настройкой оно будет принимать такие запросы, и сбой может быть предотвращён, а может и произойти.
Ага. Кажется, я это в общих чертах понял, но объяснение отличное. Вот почему я устанавливал это для каждой ~~установки, которую делал~~ виртуальной машины, которую создавал для клиентов.
Интересно, не стоит ли заставить `discourse-setup` изменять эти настройки при создании swap-раздела.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [23.Март.2022 03:47:54 UTC](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204/33 "2022-03-23T03:47:54Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
[Previous page](https://meta.discourse.org/t/failed-to-upgrade-discourse-instance-to-feb-15-2022/218204.md?page=1)