Продолжая тему этого поста: Slow Page Loads on User Profiles
Мы снова тестируем наш импорт в Discourse после внедрения этих изменений. Наблюдается улучшение скорости загрузки профилей (особенно после первой загрузки, когда данные находятся в кэше), однако загрузка некоторых профилей всё ещё занимает 5–10 секунд. Можно ли что-то ещё сделать для улучшения ситуации? Вот, похоже, проблемные запросы:
Как вы установили Discourse?
Установите контейнер Docker, следуя инструкциям.
Сколько оперативной памяти? Какой размер базы данных?
У этой ВМ 8 ядер и 32 ГБ оперативной памяти. Полагаю, что размер базы данных составляет около 40 ГБ, но на данный момент я не уверен на 100%.
Продолжает ли медленно загружаться страница профиля, если:
вы просматриваете страницу профиля пользователя как анонимный пользователь (не авторизованный)?
вы просматриваете страницу профиля обычного пользователя по сравнению со страницей профиля сотрудника?
Да, в обоих случаях. Я тестировал с обычным пользователем, выйдя из системы, и поведение примерно одинаковое.
Я пробовал экспорт и восстановление (см. Restore Failing - Check Free Disk Space), но это, похоже, не изменило поведение. Также стоит отметить, что при попытке открыть эти страницы профилей я часто получаю ошибку. Она появляется через несколько секунд после попытки загрузки страницы.
После восстановления размер базы данных теперь составляет 104 ГБ.
Та тема в основном касалась нескольких запросов типа N+1, которые у нас были на этом маршруте; все они теперь исправлены.
Страница профиля действительно содержит некоторые ресурсоёмкие запросы, так как она выводит очень персонализированную и полную сводку о пользователе, но база данных разумного размера должна справляться с её рендерингом за менее чем 500 мс.
Это большая база данных для небольшого виртуального сервера. Вы запускаете всё на одном и том же ВМ (Web+DB+Redis)?
Вы используете последнюю версию PostgreSQL 13? Можете ли вы выполнить дополнительные задачи по производительности, описанные в обновлении PostgreSQL 13, включая vacuum и reindex?
Проблема возникает у пользователей с большим количеством сообщений. Страницы профилей пользователей с малым количеством постов загружаются мгновенно, как и ожидалось.
Возможно, мне стоит пересмотреть свои ожидания. Считается ли конфигурация из 8 ядер и 32 ГБ ОЗУ небольшой для Discourse? (Да, мы используем установку в одном контейнере.) На нашем текущем программном обеспечении этот форум легко работает на 2 ядрах и 8 ГБ ОЗУ.
Что касается базы данных, то это недавно созданный контейнер, который был запущен на версии 13.1. Будет ли необходимо выполнять вакуумирование и переиндексацию сразу после восстановления?
Для базы данных такого размера вакуумирование определённо рекомендуется.
Я запустил их вскоре после вашего сообщения. Вакуум завершился очень быстро, но переиндексация всё ещё продолжается, уже более 24 часов с момента запуска. Это нормально? Сколько времени это должно занимать? Как можно определить, какой ресурс (если вообще есть) является ограничивающим? Я не вижу, чтобы postmaster использовал более 2–4 ядер большую часть времени, и, похоже, оперативной памяти достаточно.
С сожалением сообщаю, что повторная индексация всё ещё выполняется.
@Falco @codinghorror @pfaffman
Вместе с @Ghan мы в течение последнего года пытались отладить и обеспечить корректную работу импорта для нашего сообщества. Но вопрос, который меня беспокоит, таков: есть ли какие-либо другие аспекты, которые нам следует учитывать при импорте сообщества с более чем 25 миллионами сообщений?
Существуют ли на Discourse сообщества такого масштаба?
Я заметил, просматривая публичный список клиентов, что, по крайней мере среди тех, что мне видны, никто не приближается к нашему размеру. Конечно, я понимаю, что есть ещё тысячи или десятки тысяч клиентов, которых я не вижу. Нам удалось успешно завершить импорт, и на нашей стороне всё работает, но мы постоянно сталкиваемся с такими проблемами, как перегрузка при загрузке профилей для аккаунтов с большим количеством сообщений, а теперь ещё и с проблемой повторной индексации.
Могли бы вы дать какие-либо советы, чтобы сделать этот переход более гладким?
Я нашел команду rake db:stats в другом посте.
Перестроение индекса все еще выполняется, поэтому я не уверен, являются ли эти цифры окончательными на 100%.
Да, как я уже упоминал в другой теме, у нас есть экземпляры с базами данных объемом 1 ГБ и экземпляры с базами данных объемом 500 ГБ. Однако эти экземпляры работают на виртуальных машинах совершенно разного размера.
Как обстоят дела с производительностью диска на вашем сервере? Используются ли там старые жесткие диски с вращающимися пластинами?
На сервере-хосте установлены два NVMe SSD Intel P3600 ёмкостью 1,2 ТБ каждый, настроенных в зеркале ZFS.
Следующий шаг — проверка настройки PostgreSQL. Вы используете значения по умолчанию в app.yml?
Да. Я не был уверен, установит ли лаунчер автоматически некоторые значения на основе ресурсов, обнаруженных на хост-машине, или существуют ли какие-либо рекомендуемые руководства по настройке. Есть ли где-нибудь руководство по настройке базы данных?
В app.yml есть несколько комментариев, хотя он действительно оптимизирован для небольших самохостинговых сайтов. Скорее всего, вам нужно увеличить значения некоторых настроек там (я не помню их точных названий). Для получения более подробной информации вам стоит обратиться к более общим источникам по PostgreSQL.
Дело не в том, что Discourse не может справиться с сообществом вашего размера, просто это отличается от работы с более мелким сообществом и немного сложнее.
Спасибо, обязательно посмотрю. Я не знаком с Postgres, но надеюсь, что те же принципы применимы, так как я годами работал с MySQL.
Безусловно. Мне кажется, как только мы определимся, какие именно изменения необходимо внести, всё пойдет гораздо гладче.
