Всем привет,
Мы обновили наш сервер на CentOS 7 с версии 2.2.2 до 2.7.0.beta4, и с тех пор столкнулись с задержками при загрузке страниц. Особенно это заметно на страницах, содержащих данные из базы данных или изображения. Задержки достигли такого уровня, что система стала практически неработоспособной.
Будем очень признательны за любые рекомендации по этому вопросу.
За последние несколько лет произошло множество изменений. Было внесено изменение, требующее обработки всех изображений. Я подозреваю, что ваш сервер перегружен выполнением этой работы. Вы можете проверить очередь в /sidekiq.
Какого размера ваша база данных? Сколько изображений? Что показывает sidekiq? Вы используете SSD, верно?
Это сервер на базе виртуальной машины, поэтому я не уверен, используется ли там SSD. Я не вижу доступного Sidekiq, так как это развертывание выполнял не я, и не знаю, как получить к нему доступ.
Вы знаете, как оно было установлено? Похоже, это не стандартная установка (иначе, если бы вы были администратором, /sidekiq был бы вам доступен).
Ваш лучший путь вперед — выяснить, почему упала производительность. За годы было добавлено много фоновых задач (оптимизация изображений, повторная обработка и т. д.), которые, вероятно, сейчас выполняются и потребляют ресурсы вашего сервера. После их завершения производительность должна улучшиться.
Отличный первый шаг — зайти в /sidekiq (используя учетную запись администратора!), чтобы узнать, какие задачи выполняются.
Я наблюдаю следующую проблему с сервером: он продолжает показывать пустую очередь, даже когда я пытаюсь открыть пост, чтобы увидеть его в списке. Кроме того, портал Sidekiq зависает при загрузке поста и обновляется только после того, как пост полностью загрузится.
Кроме того, после загрузки снова отображается пустая очередь. Любая помощь или предложения будут очень кстати.
Если очередь пуста, значит у вас нет проблемы с большим количеством фоновых задач. Значит, дело в чём-то другом.
У вас есть какие-либо плагины? Есть ли компоненты темы, которые выполняют множество вызовов API?
Выше я задал ещё несколько вопросов.
Какого размера ваша база данных?
Сколько изображений?
Есть ли у вас компоненты темы, которые выполняют множество вызовов API?
Можете ли вы подсказать, как получить эту информацию в настройке на основе Docker? Я знаю, что последняя резервная копия имеет размер 135 МБ.
Что касается плагинов, да, у нас установлены следующие плагины:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
Я рекомендую удалить плагин Mermaid.
Сколько у вас постов и пользователей? Какой трафик?
Сколько оперативной памяти?
Похоже, вам подойдёт Droplet на 2 ГБ от DigitalOcean; можно создать такой и проверить, как он справится.
Возможно, есть какая-то другая проблема с вашим сервером? Он обновлён? Недавно перезагружался?
Хорошо, я удалю это.
У нас примерно 4 тысячи постов и около 350 пользователей.
Среднее количество одновременно вошедших пользователей невелико — максимум 5–10 человек.
Этот сервер был недавно запущен, у него 8 ГБ оперативной памяти и 10 ГБ пространства подкачки. На данный момент он работает уже 13 дней. Однако проблемы с производительностью возникают независимо от перезагрузки и времени безотказной работы.
С вашей установкой явно что-то не так; на этом оборудовании вы должны получать значительно более высокую производительность.
Попробуйте выполнить явный VACUUM в PostgreSQL. Если вы используете установку «всё в одном» в контейнере:
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Type "help" for help.
discourse=# VACUUM ANALYZE;
VACUUM
Сколько воркеров Unicorn у вас настроено в файле app.yml?
Вы можете попросить Discourse добавлять дополнительные заголовки производительности в ответы, добавив следующее в секцию env:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Пока вы этим занимаетесь, вы можете включить miniprofiler, следуя этому посту.
Этого должно быть вполне достаточно.
Не помню, предлагалось ли вам перезапустить discourse-setup, чтобы настроить использование памяти Discourse, или эти значения по умолчанию приемлемы с учётом других процессов, работающих на сервере.
Если вы не выполняли переиндексацию базы данных после обновления до PostgreSQL 13, возможно, стоит ознакомиться с обновлением PostgreSQL 13, где есть информация по этому вопросу.
Да, именно отсутствие статистики по таблицам (VACUUM ANALYZE) с наибольшей вероятностью является причиной здесь.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
Я выполнил эти команды и также установил заголовок в окружении, но не заметил значительной разницы во времени загрузки страниц.
У меня запущено 8 воркеров unicorn.
Вы запустили эти команды в PostgreSQL, верно?
Да, выполнил команду docker exec -it -u postgres app psql discourse до запуска вышеуказанных команд.
Что ж, это всё очень странно. У других таких проблем не было. Похоже, у вас достаточно аппаратных ресурсов. Моё единственное предположение — проблема с обратным прокси (наверное, на машине запущены и другие службы?).
Да, ещё один сервис на базе Docker. Но он совсем не требует больших вычислительных ресурсов, иначе это отразилось бы на показателях производительности машины.
