Высокая загрузка CPU (Ruby)

Довольно часто наблюдаю высокую загрузку ЦП, обычно она составляет около 85%:

Ранее процесс отображался как unicorn.conf.r:

Может ли это указывать на то, что UNICORN_WORKERS установлено слишком высоко или низко?

На сервере 64 ГБ ОЗУ (обычно свободно около 40 ГБ) и 6 ядер. На сервере запущено 4 экземпляра Discourse, каждый с настройкой UNICORN_WORKERS: 8.

Есть ли какие-то идеи или советы по поводу того, что вызывает проблему, или что можно попробовать? (Один из форумов работает в режиме только для чтения и получает мало трафика — стоит ли уменьшить количество воркеров для него?)

Я не знаю, но, по-моему, вы используете гораздо больше воркеров, чем могут обеспечить ваши ядра?

Да. Я также рекомендую уменьшить количество воркеров unicorn:

Попробуйте уменьшить количество воркеров Unicorn.

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

Редактирование: Кажется, я читал об этом здесь.

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

Да… Я скорректировал так, чтобы общее количество воркеров не превышало двойное количество ядер, хотя всё ещё задаюсь вопросом — что является правильным/стандартным советом: то, что вы сказали, или то, что было в посте Нейта, где он цитирует Джеффа, говорящего о 1 воркере на ядро?

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

Посмотрите на discourse-setup, который отвечает за масштабирование для новых установок на сегодняшний день:

# UNICORN_WORKERS: 2 * ГБ для 2 ГБ или меньше, или 2 * CPU, максимум 8
  if [ "$avail_gb" -le "2" ]
  then
    unicorn_workers=$(( 2 * $avail_gb ))
  else
    unicorn_workers=$(( 2 * $avail_cores ))
  fi
  unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))

Второе утверждение, использующее удвоенное количество доступных ядер, является настройкой по умолчанию для систем с более чем 2 ГБ оперативной памяти. Похоже, что ваша проблема скорее связана с борьбой за ресурсы между вашими экземплярами (ресурсами хоста), а не с проблемой в Discourse.

Я наблюдаю то же самое после последнего обновления, которое произошло через день после оригинального поста, поэтому я не думаю, что это как-то связано с количеством воркеров unicorn. Процесс unicorn.conf.r* выглядит подозрительно, потому что оригинальный пост этой темы — единственное упоминание этого термина во всём интернете. Я полагаю, что unicorn.conf.rb было бы более нормальным.

Увеличение произошло ровно во время моего последнего обновления, 4 дня назад. Обратите внимание, что оригинальный пост был опубликован 5 дней назад. В Discourse что-то изменилось.Я использовал то же количество воркеров unicorn на том же экземпляре в течение нескольких лет и ничего не менял — просто пересобрал до версии 3.4.0.beta4-dev.

Кстати, в Sidekiq нет долгих или неудачных заданий.

Я пересобрал без плагинов (кроме Docker Manager), и проблема сохраняется, так что дело не в плагине.

Есть какие-то идеи?

Я только что обновился до последней версии Discourse и больше не вижу unicorn.conf.r* (сейчас всё, что около 80% загрузки процессора, — это просто ruby, хотя это происходит реже). Нагрузка примерно такая же (хотя ниже, чем была после моих корректировок количества воркеров).

Вы тоже обновились до последней версии? На каком оборудовании вы работаете и насколько активен ваш форум?

Да, у меня версия 3.4.0.beta4-dev. Именно после этого началось высокое использование процессора. Ничего другого не менялось.

8 ГБ ОЗУ, 2 виртуальных ядра CPU, SSD на 160 ГБ с большим запасом свободного места.

Выше я привёл данные об использовании процессора для моего рабочего сайта, где одновременно находится около 30 пользователей. Но у меня есть тестовый сайт с той же проблемой, и там абсолютно нет трафика и нет плагинов. Использование процессора до и после обновления (пики связаны с ежедневным резервным копированием):

Не уверен, связаны ли наши ситуации, Марк. Думаю, в моём случае сыграл большую часть то, что сказал Стивен:

Недавно я перенёс два других инстанса на тот же сервер и даже забыл, что воркеры Unicorn были установлены на 8, потому что раньше мы работали на сервере с большим количеством ядер (но у него были свои проблемы, поэтому мы вернулись на Xeon с меньшим количеством ядер, но с лучшей общей производительностью).

Так вот, я обнаружил, что уменьшение количества воркеров Unicorn на этом сервере снижало нагрузку, но начинало вызывать таймауты, а увеличение их количества устраняло таймауты, но приводило к более высокой нагрузке — хотя всё ещё в приемлемом диапазоне. Думаю, я мог бы увеличить количество воркеров, и мы всё равно справились бы с возросшей нагрузкой, но то, что у нас есть сейчас, пока хорошо.

Тем не менее, когда я перенёс инстансы на тот же сервер, всё работало в пределах того, что я ожидал (нагрузка выросла, но незначительно), и мне казалось, что обновление привело к увеличению нагрузки… однако я не могу быть в этом уверен, и нужно помнить, что время от времени, по мере добавления новых функций в Discourse, может потребоваться более мощное оборудование или система может иногда казаться «медленнее» (у меня были инстансы Discourse на старых версиях, и они ощущались заметно быстрее — хотя, конечно, в них не было всех функций новых версий).

При этом я также считаю, что после последнего обновления Discourse (с PG 15) нагрузка на самом деле немного снизилась.

Не знаю, что посоветовать вам, Марк — может быть, поэкспериментировать с воркерами и некоторыми другими настройками? Например, db_shared_buffers и db_work_mem? Возможно, стоит создать отдельную тему в духе «Высокая загрузка CPU после обновления — нужны ли моей инстансе настройки производительности?» Или что-то в этом роде :slight_smile:

Я обновил систему сегодня вечером и сразу заметил разницу в загрузке CPU на моём сайте. Вот график до, во время и после обновления. Он охватывает один час.

Стандартная установка Discourse в одном контейнере на DO — 8 ГБ ОЗУ, 2 vCPU и 100 ГБ SSD с большим запасом места.

Посмотрим, как будет выглядеть ситуация через 12 часов.

Вот результаты через 15 часов после обновления. Процент использования процессора резко вырос в 3 раза. Фактор нагрузки увеличился в 4 раза.

Мин. Ср. До обновления После обновления
5 0,11 0,4
15 0,10 0,45

Вид за 24 часа:


Java является основным потребителем процессора. В последнем обновлении что-то резко изменилось.

Какая информация нужна команде Discourse для устранения неполадок?
Стоит ли переместить эту тему в раздел «Баги»?

Похоже, что проблема была не в воркерах Unicorn. После обновления от @sam, о котором рассказал @LotusJeff в теме, нагрузка на сервер вернулась к прежним показателям (менее половины от того, до чего она выросла)…

Это тоже решило мою проблему.

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

Есть ли у команды Discourse механизмы для оповещения о подобных проблемах? Возможно, программа волонтёров, которую администраторы могут настроить для конкретных тем, например: «Отправлять данные о нагрузке на сервер в Discourse в течение XX часов/дней/недель до/после обновления». Или ещё лучше — отслеживать это локально и оповещать администраторов, когда после обновлений замечается рост нагрузки на сервер, чтобы мы при необходимости могли опубликовать это здесь.

Я, наверное, не заметил бы этого влияния, но я внимательно слежу за сервером, так как мы мигрировали на Discourse около двух недель назад. Сейчас я глубоко погружён в различные постмиграционные проверки (запуск резервного копирования и т. д.). Через пару месяцев я бы наверняка не обратил внимания на это влияние.

Я надеюсь, что в Discourse ежедневно запускаются нагрузочные тесты. В прошлом у меня был сервер, который ежедневно пересобирался с зафиксированным кодом. На нём весь день работали симулированные пользователи. Мы измеряли ключевые метрики производительности как с точки зрения пользователя, так и с точки зрения сервера. Это позволяло нам проактивно выявлять утечки памяти, неэффективный код и неожиданные изменения в пользовательском опыте.

Тем не менее, я хочу выразить признательность Сэму и команде. Приходя из мира phpBB, где решение и исправление подобных проблем могло занять десятилетия, я считаю их быструю реакцию замечательной. (Даже если это означало оставаться на связи до 2 часов ночи по центральному времени США, что соответствует времени в Сиднее.)