Обновился до версии 3.3.0.beta3-dev вчера, а также установил плагин AI. На данный момент плагин включён только для сотрудников (5 человек).
Однако весь сайт работает крайне медленно, возникают серьёзные ошибки загрузки. Мне не удаётся понять, откуда исходит проблема — нагрузка на сервер кажется нормальной.
Подскажите, есть ли где-то места, где можно выяснить, что именно вызывает эту проблему?
Прошло ли уже много времени с момента вашего последнего обновления? Возможно, система выполняет обработку изображений или пересборку.
Вы можете зайти на /sidekiq, чтобы посмотреть, что именно происходит.
Перезагрузили — всё вернулось в норму, но теперь снова экстремальная нагрузка. Не могу понять, откуда проблема. Есть ли в Discourse какие-то инструменты, которые могли бы помочь?
Итак, три рабочих «единорога»
Заняты… но, насколько я могу судить, трафик не выше обычного, он примерно такой же, как и раньше. Единственное изменение — обновление до версии 3.3.0 и добавление плагина ИИ, который доступен только сотрудникам.
Проблемы начались вчера, 3 июня
Кажется, у нас стало немного больше краулеров.
Вот данные только по краулерам за месяц, но, опять же, это не кажется значительно выше. Сайт практически невозможно использовать
Любая помощь будет очень кстати!
Это лишь предположение, но единственное, что бросается в глаза в логах Sidekiq, — это задача NotifyMailingListSubscribers. Эта задача может потенциально создавать большое количество запросов.
Также видите ли вы какие-либо ошибки на странице Администрирование / Логи / Журнал ошибок?
Довольно много из них
Я вижу 3 ошибки, но они, похоже, не связаны… (хотя трудно сказать)
Исключение задачи: PG::DatetimeFieldOverflow: ОШИБКА: время метки вне диапазона: "271768-09-23 06:24:11.793040 BC"
СТРОКА 1: ...sers"."moderator" = FALSE AND (users.created_at < '271768-09...
^
ActionDispatch::RemoteIp::IpSpoofAttackError (Атака подмены IP?! HTTP_CLIENT_IP="10.10.121.119" HTTP_X_FORWARDED_FOR="14.140.10.244, 14.140.10.244")
app/controllers/topics_controller.rb:1298:in `track_visit_to_topic'
app/controllers/topics_controller.rb:169:in `show'
app/controllers/application_controller.rb:422:in `block in with_resolved_locale'
app/controllers/application_controller.rb:422:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:391:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-quiet_logger.rb:20:in `call'
config/initializers/100-silence_logger.rb:29:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:291:in `call'
И ещё одно исключение задачи, связанное с SMTP
Discourse осуществляет собственное ограничение скорости запросов и не полагается на robots.txt
Спасибо, Майкл,
Есть ли ещё какие-то идеи, что это может быть? Помогло бы запускать больше единорогов?
Это делается через app.yml?
Да, это, скорее всего, помогло бы.
env:
UNICORN_WORKERS: 8
в файле app.yml сделает это.
Рекомендую собирать данные о производительности с помощью плагина Prometheus, если он у вас настроен, либо воспользоваться заголовками производительности.
Анализ ваших веб-логов значительно поможет выявить причину высокой нагрузки на сервер; похоже, стоит начать с проверки действий краулеров.
Отлично, мы обновились до нового экземпляра DO, удвоили оперативную память и мощность процессора. Добавили 8 единорогов (вместо 3), выполнили реиндексацию и вакуум базы данных, и, думаю, мы снова в строю!
Спасибо за помощь.