Ещё одна загадка дискурса

В 21:09 по восточному времени (ET) я получил предупреждение от AWS CloudWatch, а также получил сообщения от друзей: «Эй, Discourse не работает?»

Я не смог подключиться по SSH к экземпляру AWS Lightsail, и все метрики зависли/перестали обновляться.

В конце концов я сдался и остановил/перезапустил экземпляр Lightsail.

Сервис восстановился.

После восстановления я проверил логи, чтобы понять, что произошло.

Я запускаю Discourse в виде одного экземпляра, поэтому ошибка в 21:05 относительно сетевого подключения Redis ставит меня в тупик.

Я не могу понять, что именно произошло, кроме как «что-то» зависло/не сработало по «какой-то причине».

Буду признателен любому, кто сможет объяснить ситуацию или дать подсказки.

Спасибо!

Какие характеристики у сервера? Похоже, что ему не хватает ресурсов? Скорее всего, это процессор. Возможно, в это время выполняется какая-то ежедневная задача?

Это экземпляр Lightsail с 1 vCPU, 1 ГБ ОЗУ и SSD-диском на 40 ГБ.

Объём хранилища использован примерно на 60%, но после очистки этот показатель значительно снижается.

AWS показывает, что у меня закончились кредиты на всплеск производительности CPU, что странно, поскольку другие метрики этому не соответствуют.

Сообщество довольно небольшое (20–30 активных участников), поэтому меня удивит, если на самом деле существуют реальные ограничения по CPU или ОЗУ.

Ежедневных задач, о которых я знаю, нет, за исключением тех, которые Discourse может планировать по умолчанию.

1 ГБ с подкачкой — это абсолютный минимум для запуска Discourse.

Как давно работает этот экземпляр? Каков размер базы данных?

Я проверю размер базы данных, не ожидаю, что он будет большим (резервные копии составляют около 57 МБ).

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

Этот тип экземпляра работает стабильно с момента его создания (по моим оценкам, в феврале 2021 года).

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

Общий размер базы данных составляет 423 МБ.

Самые большие таблицы:
Posts — 66 МБ
Post_timings — 60 МБ

Произошел второй подобный сбой при «высокой нагрузке».

Предполагаю, что это связано с конкуренцией за ресурсы.

Кто-нибудь пробовал использовать снимок Lightsail для создания снимка экземпляра и его восстановления на экземпляре большего размера в качестве метода обновления?

Вы можете попробовать перезагрузить экземпляр AWS, это может решить множество проблем.

Я перенёс инстанс с помощью снимка Lightsail с конфигурации 1 vCPU, 1 ГБ ОЗУ и 40 ГБ SSD на конфигурацию 2 vCPU, 4 ГБ ОЗУ и 80 ГБ SSD.

Помимо необходимости отсоединить и снова присоединить публичный IP-адрес, что было довольно просто, меня беспокоит вопрос: «что я мог упустить»?

Есть ли что-то (резервные копии, почта, конфигурация бакета S3 и т. д.), что мне следует проверить, или мне нужно заново выполнить начальные параметры установки, чтобы воспользоваться преимуществами обновлённых ресурсов?

Исходя из этой ссылки, я думаю, можно увеличить db_shared_buffer хотя бы до 1 ГБ. В текущем файле app.yml указано 128 МБ, а также упоминается автоматическая настройка при загрузке.

1 ГБ вполне достаточно для системы с 4 ГБ ОЗУ. Убедитесь также, что параметр unicorn_workers установлен в 4.

Обычная рекомендация при переезде между серверами — снова запустить discourse-setup, который автоматически решит все вышеперечисленные вопросы.

Спасибо. Теперь я погружаюсь в кроличью нору Prometheus.

Отличные материалы.