Только что установил Discourse, но страницы загружаются очень медленно из-за медленной внешней базы данных

Поддержка Самостоятельное хостинг
1

Главная страница отвечает 2–4 секунды

Started GET "/" for 219.144.218.209 at 2025-03-17 18:22:55 +0000

Processing by ListController#latest as HTML

Rendered layout layouts/application.html.erb (Duration: 1932.6ms | GC: 10.6ms)

Completed 200 OK in 2521ms (Views: 1933.4ms | ActiveRecord: 0.0ms (0 queries, 0 cached) | GC: 14.9ms)

Мой сервер имеет 2 ядра CPU и 8 ГБ оперативной памяти.

В логе видно, что layouts/application.html.erb рендерится слишком медленно.

Я удалил часть содержимого в layouts/application.html.erb, и теперь время ответа составляет 300–500 мс.

<discourse-assets>
    <discourse-assets-stylesheets>
      <%= render partial: "common/discourse_stylesheet" %>
    </discourse-assets-stylesheets>
    <discourse-assets-json>
      <div class="hidden" id="data-preloaded" data-preloaded="<%= preloaded_json %>"></div>
    </discourse-assets-json>
    <discourse-assets-icons></discourse-assets-icons>
  </discourse-assets>

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

3

Вы выполнили стандартную установку?

4

Да, я это сделал.

И я обнаружил проблему вчера.

Я использовал удаленную базу данных. Компонент макета Discourse выполняет 60+ SQL-запросов, каждый из которых занимает около 30 мс на передачу, поэтому первое отображение занимает 2–4 секунды.

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

6

Да, соответствует:

7

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

8

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

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

(понимаю, что это может быть для вас затруднительно собрать)

Если план выполнения запроса идентичен, то, несомненно, проблема должна быть в задержке или производительности внешней базы данных?

9

У меня есть план, который я составил некоторое время назад для долгого запроса:

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

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

10

Это сравнительно огромное количество времени. В вашей настройке SQL что-то очень не так.

Насколько удалена база данных?

99-й перцентиль общего времени выполнения SQL-запросов для авторизованных запросов на meta (размещено в AWS) составляет ~54 мс, а на нашем металлическом хостинге для аналогичного сайта — ~25 мс.

Для анонимных запросов это около 40 мс и 10 мс соответственно.

Похоже, что вы работаете в режиме разработки, а не в стандартной установке.