Это сообщение стало появляться почти постоянно с тех пор, как я обновил Discourse пару дней назад.
Я бы не создал тему здесь, если бы не одно обстоятельство: это не соответствует действительности. Сообщение появляется, но вы можете просматривать форум так, будто вы вошли в систему; ничего не указывает на то, что вы не авторизованы.
Проверка используемых/доступных ресурсов на хосте не показывает перегрузки системы или чего-либо подобного.
Может ли кто-то помочь мне понять, как вызывается это сообщение, чтобы я мог начать расследование причин появления этого предупреждения, хотя на самом деле проблемы нет?
Это сообщение имеет смысл: тот факт, что в вашей системе есть свободные ресурсы, скорее указывает на неправильную конфигурацию, чем на ошибочное определение.
Сколько у вас unicorn_workers?
Если на хосте ничего другого не запущено, вы выделили 16 процессов (по два на ядро)?
Если вы используете локальный Postgres, каково значение db_shared_buffers?
Я оставил настройки по умолчанию из начальной настройки ./launcher, и это было 8 воркеров.
То же самое для db_shared_buffers: 4096 МБ.
Однако из-за некоторых тестов, подробности которых можно прочитать здесь, количество воркеров было уменьшено до 4. Это не дало эффекта, поэтому я могу как минимум вернуть их к 8.
Причина, по которой это не 2× количество ядер, в том, что это виртуальная машина, и там используются виртуальные процессоры (vCPU), а не реальные ядра.
Я буду мониторить этот экземпляр некоторое время и вернусь, чтобы назначить решение, если это окажется так. Спасибо, @Stephen.
Сообщение относится к ресурсам, которые вы выделяете для Discourse, а не к ресурсам виртуальной машины (ВМ) или хоста.
Установите db_shared_buffers на уровне 25% от зарезервированной памяти и по 2 воркера unicorn на каждый процессор. Возможно, потребуется некоторая тонкая настройка.
Очевидно, что вам также необходимо управлять ресурсами за пределами ВМ, если вы считаете, что пул ресурсов ненадежен. Почти все, кто запускает Discourse, делают это на каком-либо виде VPS.
Я не эксперт в Discourse, поэтому просто запустил скрипт установки, так как, насколько я помню, он должен автоматически настраивать эти параметры в зависимости от доступной памяти и процессора.
Я восстановил количество воркеров до состояния, которое было до тестирования, и ещё раз проверю ситуацию.
Честно говоря, с этими настройками у нас проблем не возникало, но возможно, они не имеют к этому отношения или связаны лишь отчасти.
Я запомню вашу рекомендацию: 2x количество ядер для воркеров и 25% зарезервированной памяти для общих буферов БД.
Когда вы говорите о «зарезервированной памяти», вы имеете в виду память, зарезервированную для работающего контейнера? Потому что, похоже, она всегда устанавливается просто «на столько, сколько доступно на хосте»
# db_shared_buffers: 128 МБ для 1 ГБ, 256 МБ для 2 ГБ или 256 МБ * ГБ, максимум 4096 МБ
# UNICORN_WORKERS: 2 * ГБ для 2 ГБ или меньше, или 2 * CPU, максимум 8
Значение «максимум» можно воспринимать с долей скепсиса: особенно крупные сообщества получают выгоду от превышения этих показателей.
Так что да, в вашем случае должны были быть указаны максимальные значения: 8 воркеров и 4096 МБ. Если вы уменьшите количество воркеров и размер общих буферов, доступных для Discourse, система достигнет предела раньше, чем будут использованы все ресурсы виртуальной машины.
Этот пост от @mpalmer по-прежнему является хорошим руководством:
Мне кажется, что оно срабатывает, когда запросы слишком долго находятся в очереди — другими словами, когда входящие запросы обрабатываются медленнее, чем поступают. Можно задаться вопросом, почему так много запросов или почему обслуживание такое медленное. На уровне Discourse есть настраиваемые параметры, которые уже обсуждаются в этой теме, а также, например, в ошибке экстремальной нагрузки.
С тех пор всё казалось в порядке, но уже несколько дней форум иногда ощущается «медленным». Под «медленным» я имею в виду, что запросы (отправка ответов, редактирование и т. д.) обрабатываются с задержкой, и только что я снова заметил то же самое сообщение.
Я проверил дашборд Grafana, который настроил, и увидел, что сервер достиг предела по использованию процессора.
Попробовал перезапустить приложение, но нагрузка сразу после перезапуска снова поднимается до того же уровня.
Есть ли способ увидеть, какой процесс потребляет больше всего ресурсов? Я пытался проверить панель управления Sidekiq, но там показывается только список запущенных процессов/очереди и среднее время выполнения. Некоторые процессы медленные (например, занимают минуты), но сейчас я не вижу ничего в обработке или с ошибками.
Перезагрузил и VPS, на всякий случай, вдруг что-то странное происходило (хотя сомневаюсь, так как проблема началась внезапно вчера после 150 дней работы), но нет, поведение то же.
Для быстрого взгляда, конечно, он колеблется, но это среднее значение для работающих единорогов, что кажется мне аномальным, учитывая, что это продолжается со вчерашнего дня:
Средняя загрузка (load average) выше 8 на машине с 8 vCPU означает, что ваш сервер перегружен.
Между 8 воркерами Unicorn, множеством процессов PostgreSQL и остальными службами на сервере он не успевает обрабатывать входящие запросы достаточно быстро. По крайней мере, у вас достаточно памяти
Это довольно необычно для Discourse, чтобы узким местом становился процессор Unicorn. В большинстве случаев, когда я сталкивался с такой проблемой, виновником был некорректно работающий плагин. Можете ли вы поделиться своим app.yml?
Также, пожалуйста, поделитесь результатами MiniProfiler при загрузке вашей главной страницы и страницы темы.
Я попросил хостинг-провайдера проверить, не крадут ли другие VPS на нашем сервере время процессора, так как очень странно, что это произошло так внезапно, хотя с нашей стороны ничего не менялось.
Я жду, когда техническая поддержка вернётся с результатами.
В итоге всё оказалось так, как я и предполагал. На хосте был развёрнут ещё один VPS, который истощал ресурсы.
Мы были перенесены на другой хост менее чем через 24 часа после создания тикета.
Браво, Contabo
Прошу модераторов оставить эти последние ответы, даже если они не относятся напрямую к Discourse, так как они могут помочь другим понять другие возможные причины проблем с их экземпляром.
