Устранение неполадок медленного сайта, который до сегодняшнего утра работал быстро

Как мне начать устранять неполадки на сайте, который сегодня стал работать медленно (без видимых причин)?

Использование ресурсов очень низкое:


Это дроплет с 16 ГБ памяти, 4 виртуальными CPU AMD, 200 ГБ дискового пространства, расположенный в SFO3, на базе Ubuntu 24.04 (LTS) x64, с использованием 30% дискового пространства.

Статус сервиса DigitalOcean Service status весь день был нормальным.

О медленной работе сайта сообщают пользователи из различных регионов.

yaml:
UNICORN_WORKERS: 8
db_shared_buffers: "1024MB"
db_work_mem: "40MB"

Я пересобрал систему до последней версии и выделил Sidekiq больше памяти: UNICORN_SIDEKIQ_MAX_RSS: 1000.

В консоли наблюдаются некоторые ошибки 429:


Лог ошибок за последние 3 дня:

Что происходит в безопасном режиме?

В безопасном режиме ошибок в консоли нет, но всё работает намного медленнее. Загрузка любого контента занимает около 10–15 секунд, а изображения подгружаются с трудом, будто через модем со скоростью 14,4 Кбит/с.

Загрузка страницы /logs заняла около 20 секунд. Возврат на страницу /admin занял примерно минуту.

Запрос «poll» тоже выполняется очень долго:

Кстати, вот список запущенных плагинов:

      - git clone https://github.com/discourse/docker_manager.git
      - git clone https://github.com/discourse/discourse-data-explorer.git
      - git clone https://github.com/paviliondev/discourse-locations.git
      - git clone https://github.com/discourse/discourse-affiliate.git
      - git clone https://github.com/discourse/discourse-yearly-review.git
      - git clone https://github.com/discourse/discourse-docs
      - git clone https://github.com/discourse/discourse-subscriptions
      - git clone https://github.com/paviliondev/discourse-category-lockdown
      - git clone https://github.com/discourse/discourse-reactions.git

Вот ещё несколько данных от сегодняшнего утра. Sidekiq выглядит спокойно:

Интересный график использования памяти — после пересборки приложения он составляет около 20–30%, затем во время резервного копирования резко возрастает до 46% и остаётся на этом уровне:

Установлен ли у вас печально известный компонент темы «Значки в сообщениях»?

Этот?

Ух ты! Разница между днём и ночью после удаления компонента Post Badges. Его отключение не дало результата, а удаление — да. Больше никаких ошибок в консоли.

Спасибо @Falco!

Что ж, боюсь, это не оно, или по крайней мере не всё.

Теперь я вижу битые изображения и вот что в консоли:

Загрузка всё ещё медленная или вообще не происходит, а спиннер крутится…

Интересно, связано ли это с проблемой:

Я восстановил Discourse из резервной копии около 4 недель назад, когда перенёс его со старого droplet на Ubuntu 16.4 LTS на новый с Ubuntu 24.04. Я не выполнял ручную повторную обработку.

Становится всё страннее. Это происходит при переходе из /logs в /admin, нажав на ссылку «Вернуться на сайт».

Недавно была еще одна тема с ошибкой «no route named admin».
Site Glitch Content Not Showing Up - #18 by Suresh_Suthar

Возможно, это тоже связано с Cloudflare.
Resolving "SyntaxError: Unexpected identifier #..." caused by Cloudflare Auto Minify

Хм. У меня не используется Cloudflare, но я заметил дублирующийся заголовок в Chrome, как в первом сообщении.

Я только что пересобрал систему без плагинов, кроме docker_manager, так что сообщу, как она будет работать.

Ещё один момент: когда в Chrome оно зависает, мне приходится закрывать эту вкладку и открывать её заново. Принудительная перезагрузка ничего не даёт.

Теперь ночное резервное копирование в S3 завершается с ошибкой, хотя в настройках ничего не менялось:

[2024-10-10 15:03:04] Загрузка архива...
[2024-10-10 15:14:33] ИСКЛЮЧЕНИЕ: ошибка multipart-загрузки: Net::WriteTimeout с #<TCPSocket:(closed)>

РЕДАКТИРОВАНИЕ: Два резервных копирования, запущенные вручную, завершились с той же ошибкой, но затем два следующих ручных копирования прошли успешно. При этом никаких изменений в настройках не производилось. :person_shrugging:

В консоли ошибок не видно, только периодически очень медленная загрузка:

Discourse Doctor в одном запуске показывает всё в порядке, но во втором запуске сообщает, что порт 587, вероятно, заблокирован. Это странно, так как тестовое письмо было успешно доставлено в первом запуске и снова успешно в третьем:

Соединение с портом 587 не удалось.
====================================== РЕШЕНИЕ =======================================
Наиболее вероятная проблема в том, что на вашем сервере заблокирован исходящий SMTP-трафик.
Если вы используете сервис вроде Mailgun или Sendgrid, попробуйте использовать порт 2525.

Правильно ли я думаю, что с этим дроплетом DigitalOcean что-то неладное?

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

speedtest-cli
Получение конфигурации speedtest.net...
Тестирование от Digital Ocean (24.199.xxx.xxx)...
Получение списка серверов speedtest.net...
Выбор лучшего сервера на основе пинга...
Размещено компанией Next Level Infrastructure (Санта-Клара, Калифорния) [4.38 км]: 2.242 мс
Тестирование скорости загрузки................................................................................
Загрузка: 839.25 Мбит/с
Тестирование скорости отдачи......................................................................................................
Отдача: 1.27 Мбит/с

Вот счастливый финал этой саги…

После запуска тестов пропускной способности сети speedtest-cli и iperf3, которые показали катастрофически низкую скорость между дроплетом и внешним миром, я попросил DigitalOcean провести расследование. После собственных тестов они пришли к следующему выводу:

Мы обнаружили некоторые проблемы с гипервизором, на котором размещён ваш Droplet. Мы работаем с нашей бэкенд-командой над миграцией вашего Droplet на другой гипервизор.

Всё снова в порядке.