Повышенное использование процессора после обновления до 3.4.0.beta4-dev (58f75ed205)

Я заметил значительный рост использования ЦП после обновления в эти выходные. Основным фактором, судя по всему, является процесс RUBY. Об этом уже упоминал другой пользователь Discourse в этой теме.

Как видно из графиков ниже, до обновления использование ЦП и нагрузка были значительно ниже, чем после. Обновление было установлено вечером 31 января.

Ниже приведены два снимка утилиты TOP, сделанные с интервалом в 33 часа:

За 33 часа наблюдается значительное использование ЦП процессом Ruby. Судя по данным TOP, за последние 33 часа нагрузка на ЦП выросла в два раза по сравнению с показателями за последние 22 дня. За 33 часа было затрачено 11 часов процессорного времени (648 минут процессорного времени на 5 идентификаторах процесса).

Дополнительные данные:

  • Трафик за последние два дня снизился примерно на 10% (данные аналитики и дашборда).
  • Стандартная установка Discourse в одном контейнере (без чата).
  • Очереди Sidekiq минимальны (от 1 до 2 тысяч задач в день).
  • В логах Discourse ничего необычного не обнаружено.
  • Сервер размещен на DO (DigitalOcean) с 8 ГБ ОЗУ и 2 виртуальными ядрами AMD.

Ситуация не критическая, сервер работает, но серверы, работающие на 5–7% нагрузки, функционируют стабильнее, чем те, что работают на 25%.

Какую информацию я могу предоставить, чтобы помочь в диагностике этой проблемы?

заранее спасибо

Оставим это на рассмотрении в поддержке, пока не выясним, есть ли ошибка.

Можете ли вы зайти в контейнер и запустить htop изнутри (вам придется его установить), чтобы определить, какой именно процесс потребляет много ресурсов процессора.

Вы можете получить немного больше информации, используя такой подход: Debugging 100% CPU usage in production Ruby on Rails systems

Однако, скорее всего, sidekiq /sidekiq каким-то образом перегружен на вашем экземпляре. (Я бы особенно обратил внимание на планировщик)

Представления htop.

Вот 30-секундное видео:

Случайные скриншоты:

Древовидный вид:

sidekiq:


Дайте знать, если вам нужно увидеть что-то конкретное. Я

Да, что-то не так:

top -H -p PID_OF_UNICORN

Подозреваю, что вы увидите там V8 DefaultWorker. Думаю, это регрессия в mini_racer… отменю это, чтобы проверить, решит ли проблему.

OK, это отменено сейчас,

Дайте знать, если коммит восстановит производительность.

Да, это решило проблему с высокой загрузкой процессора. Моя загрузка за 1 и 5 минут составляет примерно 1/3 от предыдущих значений. Это при том, что htop и netdata сейчас запущены на системе.

Видео HTOP

График Do

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

Таблица нагрузки:

время До исправления После исправления
1 мин 0.4–0.6 0.06–0.1
5 мин 0.39–0.5 0.15–0.18

Показатель за 15 минут затронут перестроением. Я опубликую ещё несколько статистических данных сегодня утром.

Спасибо за исправление, сделанное глубокой ночью.

Приносим извинения за это. Обновление mini_racer стало настоящим приключением. Надеемся, что скоро мы с этим справимся.

Спасибо за быстрый ответ и расследование.

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

Как новый пользователь Discourse, использующий его уже две недели после миграции, могу сказать, что продуктом очень приятно пользоваться.

Здесь та же история.

[Редактирование: похоже, что проблема решена после обновления до последней ветки]

Вот обзор производительности через 18 часов после восстановления. Таблица загрузки говорит сама за себя.

Таблица загрузки:

время До исправления После исправления
1 мин 0,4–0,6 0,03–0,05
5 мин 0,39–0,5 0,09
15 мин 0,68 0,12

Легенда:

  • Красная стрелка — восстановление приложения
  • Фиолетовая стрелка — отключение netdata

Обратите внимание, чтобы замкнуть круг: причиной ошибки был этот коммит:

Я обновил gem. Одно из непосредственных преимуществ заключается в том, что эта версия V8 использует немного меньше памяти, что очень приятно.

Я установил последнюю версию с исправлением вчера вечером. Загрузка процессора вернулась к историческим показателям.

Спасибо за отличную работу.