Согласен, какая ценность у контента, который никто не читает? И кто вообще сядет и прочитает 10 000 постов от начала до конца? 
Нормально, что некоторые темы — это мимолётные чаты, которые со временем полностью исчезают, то, что мы ранее называли «быстрой» и «медленной» полосой движения.
Маленькое обновление:
Поскольку было сообщено и согласовано закрыть всё выше отметки (и восстановить лимиты), производительность кажется лучше, намного лучше. Мы всё ещё получаем некоторые сообщения «Из-за экстремальной нагрузки это временно отображается для всех так, как это видит неавторизованный пользователь», но значительно реже.
Сказав это:
Ещё раз огромное спасибо всем за помощь и обратную связь.
Postgres 12 поможет, так как, по результатам тестов @falco, он уменьшает размер таблиц и индексов на 20%.
Уже есть целевая дата?
Сегодня я начал проводить бенчмарки.
Нужно дать ему поработать здесь, на Meta, какое-то время, чтобы отследить регрессии производительности перед тем, как развернуть его повсеместно.
Извините, что поднимаю эту тему снова, но это другая проблема, чем миграция PostgreSQL (которую я пока не могу выполнить из-за большого размера).
После последней пересборки размер моей базы данных не перестает увеличиваться:
Последняя пересборка была 17 мая, и с тех пор размер БД продолжает расти, достигнув 57,3 ГБ, причем основной объем занимает таблица post_timings.
Моя главная проблема в том, что я пытаюсь выполнить обновление PostgreSQL (которое уменьшит размер индексов на 20%, но не решит проблему в долгосрочной перспективе). Судя по комментариям сотрудников здесь, такой размер не является нормой, поэтому он будет продолжать расти и станет кошмарно дорогим в обслуживании. Чем больше времени проходит, тем больше он увеличивается, создавая замкнутый круг, который становится адом для поддержки. Таким образом, моя основная проблема остается: есть ли способ справиться с этой таблицей post_timings? Можно ли что-то удалить?
Могу ли я сжать таблицы или сделать что-то подобное?
Спасибо всем за помощь.
На данный момент выхода нет. Если ваш форум действительно большой, таблица timings будет большой.
Meta — очень старый инстанс, но он среднего размера, и таблица post_timings в нём занимает всего 4 ГБ. С другой стороны, мы хостим один инстанс, которому меньше двух лет, и таблица post_timings в нём уже должна превышать 100 ГБ.
Хостинг больших форумов будет стоить дороже, и на сегодняшний день выхода нет.
Может быть, перенести базу данных на отдельный droplet за $20 (80 ГБ диска), а веб-часть разместить на другом droplet за $10? $30 в месяц за то, что, судя по всему, является довольно большим сообществом, звучит разумно.
Спасибо вам большое за помощь, @Falco.
Да, как я и говорил, просто спрашиваю, потому что в космосе нет никакой магии. Я изучаю вариант с разделением, но тогда приложение будет работать слишком медленно из-за проблем с производительностью (длинная история, я фиксирую результаты тестов и позже представлю их здесь, чтобы все могли ими воспользоваться, если сочтут полезными).
Я провел тест, о котором спрашивал вас, касательно восстановления резервной копии и прочего, и думаю, что это может стать хорошей возможностью, поскольку я сразу вижу снижение использования диска на 30% (я все еще провожу тесты, чтобы убедиться, что ничего не утеряно), но теперь возникла небольшая проблема с этим подходом. Поэтому, несмотря на то, что немедленные преимущества велики, это создаст некоторые проблемы (тем более, что я не знаю, используется ли кэширование или что-то не работает вовсе в отношении хранящихся изображений, хотя да, в резервную копию они включены).
Я делаю заметки, чтобы обновить исходный пост; моя идея состоит в том, чтобы добавить небольшой набор заметок для тех, кто может беспокоиться о производительности и обо всех изменениях, которые я пока внес.
Является ли применение таймера «автоудаления ответов» технически хорошим решением для этого?
На самом деле это довольно хорошая идея, и она решает проблему удобства использования (поскольку, как мы уже говорили, никто не будет читать 10 тысяч сообщений). Так что главный вопрос: не станет ли это слишком обременительным для сервера и базы данных?
Не уверен, что тема с 9000 ответов, из которых удалено около 8600, хороша для производительности, но мне почему-то кажется, что нет. Что скажете, @eviltrout?
Я думал, что «скрытые» посты полностью удаляются из базы данных через некоторое время, но теперь вижу, что, вероятно, это не так. Поэтому с точки зрения производительности моя идея не решает проблему.
Есть ли способ «очистить» эти данные?
Удалённые сообщения удаляются мягко. Однако они часто индексируются, поэтому после удаления большого количества таких сообщений вы можете заметить некоторые улучшения. Тем не менее, я бы не рекомендовал это делать. Если есть возможность перенести обсуждение в новую тему, когда текущая станет слишком большой, это может вам хорошо помочь.
Что именно вы имеете в виду? Размещение базы данных и веб-приложения на отдельных серверах должно повысить производительность, поскольку, несмотря на некоторую задержку между серверами, ваши Unicorn и Postmaster не будут конкурировать за ресурсы CPU и RAM.
Убедитесь, что серверы находятся в одном регионе DO 
Извините, вы правы, это освободит оба ресурса и обеспечит лучшую производительность по сравнению с размещением всего на одной машине (я сравнивал с ресурсами, которые использую на одном компьютере, и с оптимизациями, которые я уже применял).
Это действительно отличная идея. Позвольте мне попытаться решить проблему «невозможно пересоздать контейнер данных», с которой я столкнулся, и это станет следующим шагом в моём пути.
Я уже искал всюду по этой теме, но не смог найти документации о том, как это сделать оптимально. Существует ли такое руководство?
Мы тоже начинаем упираться в ограничения нашей стандартной установки на одном VPS. Наша довольно уникальная проблема — это игровые чаты, которые активны во время хоккейных матчей и вызывают резкие пики активности/нагрузки. Особенно если в игре происходит что-то необычное.
Наверное, вам понадобится что-то достаточно мощное, чтобы выдержать самые загруженные моменты. Или же нужно будет повышать производительность именно в эти периоды. Возможно, стоит рассмотреть VPS с почасовой оплатой. Одно из решений (продолжая предыдущий совет) — перенести веб-контейнер на очень мощный VPS, который вы будете оплачивать всего на несколько часов, когда идут игры.
Вам необходимо:
Запустить PostgreSQL на отдельном сервере (например, на droplet или используя управляемый сервис, такой как Worry-Free Managed Database Hosting | DigitalOcean) и перенести туда ваши данные.
Следуйте инструкции Запуск Discourse с отдельным сервером PostgreSQL
И этого также можно достичь, используя контейнеризованные продукты Discourse? Web_only и data, верно?
По моему опыту, ни один из текущих подходов не решает эту проблему напрямую, и линейного решения не существует. Фактически, разделение их на разных машинах не является мгновенным решением этой проблемы.
Мы также сталкиваемся с сильными сбоями и сообщениями «сайт перегружен, поэтому вы видите его как незарегистрированный пользователь», когда происходит крупное событие (например, игра, как сказал @ljpp), и это тормозит работу всего сайта, а не только участников той темы.
Поэтому я попробовал два разных подхода: отдельную настройку и «мощную машину». В обоих случаях возникают подобные проблемы. Мои экземпляры мониторятся с помощью Prometheus, логи видны в Grafana и т. д., поэтому у меня есть очень детальный контроль за производительностью оборудования и контейнеров. Я могу подтвердить, что неважно, что вы делаете, проблема всё равно возникает.
Если вы поставите мощную машину перед этим, вы можете немного отсрочить проблему, но всё равно получите ошибки и разрывы сессий, при этом машина будет почти не загружена: ни диск, ни процессор, ни оперативная память. Это происходит как при «стандартной установке», так и при установке «с двумя контейнерами».
При использовании разных машин проблема остаётся той же, независимо от того, одинакового ли они типа или одна «оптимизирована под процессор», а другая «оптимизирована под диск» и т. д. К этому также добавляется дополнительный уровень возможных сбоев соединения между двумя разными машинами, что неизбежно приведёт к задержкам. Хотя величина этих задержек может зависеть от того, как вы настроите соединение и «насколько далеко» находятся машины друг от друга, поведение останется тем же.
Как примечание: такое поведение наблюдается и с плагином Babel. Однако, по-моему, плагин Babel справляется с гораздо большим количеством «одновременных» записей, даже если «чаты» на самом деле являются скрытыми темами. Разница заключается в том, как они отображаются и «обновляются»/«извлекаются». Это различие в поведении привело меня к выводу, что проблема заключается в какой-то корреляции на уровне приложения, которая проистекает из фронтенд-проблемы, «обрушивающей» приложение (хотя фронтенд — не моя сфера экспертизы, в отличие от бэкенда), а также из операций, связанных с публикацией сообщений и ожиданием пользователями «автообновления» темы, когда за одну минуту появляется десятки сообщений.
К этому также добавляется человеческий фактор: когда люди чувствуют, что сайт «тормозит» или что тема «обновляется не так быстро, как должна», они начинают безумно обновлять страницу (F5), создавая дополнительную нагрузку. Но удачи в «обучении» этому
