Весь компьютер зависает во время обновления

Поддержка Самостоятельное хостинг
1

С тех пор как я попробовал плагины AI (а затем снова удалил их), мой сервер полностью зависает при выполнении /admin/upgrade.

Не каждый раз, но примерно в 80% случаев.

Обычно полностью зависает весь экземпляр EC2, и мне приходится выполнять жесткую перезагрузку через веб-интерфейс AWS EC2.

Сегодня зависание произошло снова. К моему удивлению, система не зависла полностью. При открытии корневой URL-адреса теперь отображается:

Ой

Программное обеспечение, управляющее этим форумом, столкнулось с непредвиденной проблемой. Приносим извинения за неудобства.

Подробная информация об ошибке была записана в лог, и было автоматически сгенерировано уведомление. Мы разберёмся в этом.

Никаких дополнительных действий не требуется. Однако, если ошибка повторяется, вы можете предоставить дополнительные сведения, включая шаги для воспроизведения ошибки, опубликовав тему в разделе обратной связи сайта.

Сейчас я попробую снова перезагрузить систему и выполнить обычную команду sudo ./launcher rebuild app, которая помогала до сих пор. Держу кулаки, чтобы сегодня тоже сработало.

Мой вопрос

Может ли кто-нибудь подсказать, куда можно посмотреть в файлах логов или что ещё проверить, чтобы получить хотя бы сообщение об ошибке, объясняющее почему происходят зависания?

2

Официальный плагин ИИ?

Я бы запустил это из консоли и посмотрел, где оно застревает, и поделился бы логами.

3

Да, это официальный плагин.

Я удалил его, снова исключив плагины из app.yml и затем пересобрав. Возможно, этого недостаточно?

Что имеется в виду под «этим»? Команда sudo ./launcher rebuild app?

4

Каковы характеристики вашего сервера?

На мой взгляд, для онлайн-обновлений в наши дни минимум требуется сервер с 4 ГБ ОЗУ и 2 ГБ файла подкачки.

5

Я использую экземпляр AWS EC2 типа «t2.medium» с 2 vCPU и 4 ГиБ оперативной памяти.

Объём жёсткого диска составляет 100 ГиБ, свободно 60 ГиБ.

Если это поможет, я могу обновить экземпляр «t2.medium» до более крупного типа.

Я просто не понимаю, почему эта конфигурация работала безупречно (в течение многих лет) до моего тестирования официального плагина ИИ, и зависания при обновлении стали возникать только после его удаления.

6

Ещё одно изменение: версия ПО, до которой вы обновляетесь, стала в последнее время требовать больше памяти. Поэтому, я думаю, проблема может быть в чём угодно из этого.

Временное и обратимое увеличение объёма оперативной памяти на экземпляре, вероятно, самый простой способ проверить, является ли нехватка памяти причиной проблемы, хотя это и потребует нескольких перезагрузок. Другой вариант — добавить файл подкачки (swap), что также является обратимым решением.

7

Попробуйте добавить swap.

8

Спасибо, ребята, я поищу в Google, как это сделать, и затем сделаю :slight_smile:.

Обновление 1

Я добавил 8 ГиБ своп-пространства:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

Я опубликую обновление здесь после следующих обновлений, чтобы сообщить, помогло ли это.

Обновление 2

Только что выполнил /admin/upgrade и отслеживал использование ОЗУ:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

Обновление прошло успешно. :tada: Надеюсь, так и останется.

Обновление 3

Спустя несколько дней и обновлений у меня больше не было зависаний.

Поэтому я считаю, что своп-пространство стало решением. Ещё раз спасибо всем, кто помогал мне в решении этой проблемы.

9

Это немного не по теме, но я очень хочу понять. Почему своп, который занимал 200 МБ, помог, когда было свободно 2 ГБ оперативной памяти?

(Я понимаю, что в мире дюймов система СИ может сбивать с толку, потому что она использует десятичную шкалу, но почему черт возьми Ми? Я кое-как понимаю Ги, если это сокращение от гига, но тогда мега должно быть Ме?)

10

Mi, полагаю, для мебибайтов, а Gi для гибибайтов.

11

Спасибо. Я этого не знал, это очевидно. Но это мебибайт :wink:

И для тех, кто тоже этого не знал :smirking_face:

12

Думаю, исходная проблема, скорее всего, заключалась в том, что какой-то процесс был убит, потому что на машине закончилась память (остерегайтесь OOM-киллера). Добавление подкачки означало, что память не была исчерпана. Эти два вывода команды free, возможно, не рассказывают всей истории, если только они не были очень тщательно получены в момент наибольшей нагрузки на машину. Интересно, на мой взгляд, именно пиковое использование подкачки.

Но также есть вопрос о настраиваемых параметрах ядра, упомянутых в
Мнении Майкла К. Джонсона о конфигурации развёртывания Discourse,
которые у меня установлены правильно, но которые, возможно, у многих людей настроены неверно.

Стоит отметить, что перерасход памяти мало что имеет общего с Redis. Просто Redis любезно подсказывает, что это значение должно быть установлено правильно.

13

Только что запустил ещё одну команду /admin/upgrade и оставил оболочку открытой, чтобы вручную вызывать tree -h каждую секунду или около того.

Самые высокие значения использования памяти, которые мне удалось найти, были следующими:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

Обновление прошло успешно.

14

Итак, 4 ГБ — это как раз на грани во время сборки, если предположить, что последний скриншот показывает самый напряжённый момент.

И ещё один момент, который я не могу понять: почему у других возникает нехватка памяти, а у меня, кто использует множество плагинов и компонентов, не было никаких проблем :thinking: что именно создаёт эту разницу?

Я использовал слово «было», потому что сейчас у меня 8 ГБ из-за ИИ (и для меня разница в цене не была столь существенной, но это уже другая история).

Стоит ли перенести эту тему в другое место, или мы рассматриваем это как объяснение того, почему использование подкачки помогло?

В любом случае. Для других новичков вот один пример, где немного говорится о нехватке памяти и её причинах:

Это очень частый вопрос, когда обновление не удаётся. Но причина этого редко объясняется.

15

@Jagster @uwe_keim пожалуйста, отправьте вывод следующих команд:

cat /proc/sys/vm/overcommit_memory 
cat /sys/kernel/mm/transparent_hugepage/enabled

На моих системах выводится:

# cat /proc/sys/vm/overcommit_memory 
1
# cat /sys/kernel/mm/transparent_hugepage/enabled 
always madvise [never]
16 
$ cat /proc/sys/vm/overcommit_memory
0

и

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never
17

Спасибо @uwe_keim — я предполагаю, что именно эти настраиваемые параметры ядра стали причиной необходимости добавления swap-пространства, даже если оно не использовалось. (То же самое относится к случаю, если бы потребовалось добавить много оперативной памяти, поскольку общая доступная память равна сумме RAM и swap.)

18

Я могу в любой момент изменить настройки сервера, если вы порекомендуете это сделать.

19 
root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
всегда [madvise] никогда
20

Я рекомендую!

Это исправит проблему при будущих перезагрузках (обратите внимание, что файлы перезаписываются без проверки текущего состояния):

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system