Concordo, qual é o valor de conteúdo que ninguém lê? E quais pessoas vão realmente sentar e ler 10.000 posts do início ao fim? 
Está tudo bem que alguns tópicos sejam conversas efêmeras que desaparecem completamente com o tempo, o que anteriormente chamávamos de tráfego de “pista rápida” versus “pista lenta”.
Pequena Atualização:
Como foi relatado e acordado fechar tudo acima da marca (e reestabelecer os limites), o desempenho parece ter melhorado, muito melhor. Ainda recebemos algumas mensagens do tipo “Devido à carga extrema, isso está sendo temporariamente exibido para todos como um usuário deslogado veria”, mas em quantidade consideravelmente menor.
Dito isso:
Mais uma vez, um grande agradecimento a todos por ajudarem e darem feedback.
O Postgres 12 ajudará, pois reduz o tamanho das tabelas e índices em 20%, conforme os testes de @falco.
Já há uma data-alvo definida para isso?
Comecei a fazer benchmarks hoje.
Preciso deixar rodar por um tempo aqui no Meta para monitorar regressões de desempenho antes de liberar para todos.
Peço desculpas por trazer isso à tona novamente, mas este é um problema diferente da Migração do PostgreSQL. (Que ainda não consigo realizar devido ao tamanho).
Desde a última reconstrução, o tamanho do meu banco de dados não para de aumentar:
A última reconstrução foi em 17 de maio e, desde então, o tamanho do banco de dados não para de crescer, atingindo 57,3 GB, e o grande volume está na tabela post_timings.
Meu principal problema com isso é que estou tentando fazer a atualização do PostgreSQL (que reduzirá o tamanho dos índices em 20%, mas não resolverá isso a longo prazo). E, pelos comentários aqui da equipe, esse tamanho não é o normal, então continuará aumentando e se tornará pesadelosamente caro. Quanto mais tempo passa, mais aumenta e cria um loop que se torna um inferno para manter. Portanto, meu principal problema permanece: existe alguma maneira de lidar com essa questão do post_timings? Algo para excluir?
Posso compactar tabelas ou algo assim?
Obrigado a todos pela ajuda.
Não há como contornar isso no momento. Se seu fórum é realmente grande, ele terá uma tabela de tempos considerável.
O Meta é uma instância muito antiga, mas é de porte médio e possui uma tabela post_timings pequena de 4 GB. Por outro lado, hospedamos uma instância com menos de 2 anos de idade e a tabela post_timings já deveria ter mais de 100 GB.
Hospedar fóruns grandes vai custar mais, e não há como contornar isso hoje.
Talvez você possa mover seu Banco de Dados para um droplet separado de $20 (80 GB de disco) e colocar a web em outro droplet de $10? $30 em custos mensais para o que parece ser uma comunidade bastante grande soa razoável.
Muito obrigado pela sua ajuda, @Falco.
Bom, é isso mesmo, como disse, só perguntando porque não existe mágica quando se trata de espaço. Estou analisando a divisão, mas aí o aplicativo ficará muito lento devido ao desempenho (longa história; estou anotando os testes e os apresentarei aqui mais tarde para que todos possam utilizá-los, se acharem úteis).
Fiz o teste sobre o qual te perguntei, relacionado à recuperação de um backup e afins, e acho que isso pode ser uma boa situação para aproveitar, já que o que consigo ver imediatamente é que há 30% menos uso de disco (ainda estou executando alguns testes para verificar se nada está faltando), mas agora há um pequeno problema com essa abordagem. Então, embora os benefícios imediatos sejam grandes, isso gerará alguns problemas (ainda mais porque não sei se está em cache ou se não funciona de forma alguma em termos de imagens armazenadas, e sim, o backup as inclui).
Estou tomando notas para que eu possa atualizar o OP. Minha ideia aqui é adicionar uma pequena série de observações para pessoas que possam se preocupar com o desempenho e todas as coisas que tenho modificado até agora.
Aplicar um temporizador de “excluir respostas automaticamente” é uma boa solução tecnicamente?
Na verdade, essa é uma ideia bastante boa e resolve o problema de usabilidade (porque, como dissemos, ninguém vai ler 10 mil mensagens). Então, a grande questão é se isso seria pesado para o servidor e o banco de dados.
Não tenho certeza se um tópico com 9000 respostas, das quais ~8600 foram excluídas, é bom para o desempenho, mas de alguma forma duvido. O que você acha, @eviltrout?
Eu achava que posts “ocultos” fossem completamente removidos do banco de dados após algum tempo, mas agora vejo que provavelmente não é esse o caso.
Portanto, em termos de desempenho, minha ideia não consegue resolver o problema.
Existe alguma maneira de “limpar” esses dados?
Posts excluídos são excluídos de forma suave. No entanto, eles são frequentemente indexados, então você pode notar algumas melhorias quando vários forem removidos. Não recomendo isso, porém. Se houver alguma maneira de migrar para um novo tópico assim que um ficar grande, isso pode ser muito útil para você.
O que você quer dizer com isso? Ter o banco de dados e a aplicação web em servidores separados deve oferecer mais desempenho, pois, embora haja alguma latência entre os servidores, seu Unicorn e Postmaster não precisarão competir por CPU e RAM.
Certifique-se de que os servidores estejam na mesma região da DO 
Desculpe, você está certo, isso liberaria ambos e traria um desempenho melhor do que tudo em um único (eu estava comparando com os recursos que estou usando em uma única máquina e com os ajustes que tenho feito até agora).
Essa é, na verdade, uma ideia muito boa. Deixe-me tentar resolver o problema de “impossível reconstruir o contêiner de dados” que tenho, e esse será meu próximo passo nessa jornada.
Tenho procurado exaustivamente sobre esse tópico, mas não encontrei documentação sobre como fazer isso da maneira ideal. Existe algum guia assim?
Também estamos começando a atingir um limite com nossa instalação padrão em VPS único. Nosso dilema, bastante peculiar, são os chats do jogo, que ocorrem durante partidas de hóquei e causam picos agudos de atividade/carga. Especialmente se algo extraordinário acontecer no jogo.
Você precisaria ter algo poderoso o suficiente para suportar seus momentos de maior demanda, imagino. Ou precisaria aumentar o desempenho nesses períodos. Talvez pesquise VPS com pagamento por hora. Uma solução (continuando o conselho anterior) seria mover o contêiner da web para um VPS extremamente poderoso, que você paga apenas por algumas horas quando há jogos.
Você precisa:
Executar o PostgreSQL em outro lugar (um droplet ou usar um serviço hospedado como Worry-Free Managed Database Hosting | DigitalOcean) e mover seus dados para lá.
Siga Executando o Discourse com um servidor PostgreSQL separado
E isso também pode ser alcançado usando os produtos containerizados do Discourse? Web_only e data, certo?
Pela minha experiência, isso não é resolvido diretamente por nenhuma abordagem atual nem possui uma solução linear. Na verdade, separá-los em máquinas diferentes não é uma solução instantânea para esse problema.
Também enfrentamos quedas severas e mensagens como “o site está extremamente ocupado, então você está sendo visto como alguém que não está logado” quando ocorre um grande evento (como um jogo, como @ljpp mencionou), o que arrasta todo o site, não apenas as pessoas dentro daquele tópico.
Então, tentei duas abordagens diferentes: uma configuração separada e uma “máquina grande”. Ambas apresentam esse tipo de problema. Minhas instâncias são monitoradas com Prometheus e os logs são visíveis no Grafana, etc., então tenho um controle muito granular sobre o desempenho de hardware e containers, e posso confirmar que realmente não importa o que você faça, o problema ocorre de qualquer forma.
Se você colocar uma máquina grande atrás disso, talvez adie o problema um pouco, mas ainda assim terá erros, quedas de sessão e a máquina ficará com quase nenhum uso, seja de disco, CPU ou RAM. Isso acontece tanto com a “instalação padrão” quanto com as instalações de “dois containers”.
Com máquinas diferentes, o problema é o mesmo, independentemente de as máquinas serem do mesmo tipo ou uma ser “Otimizada para CPU” e a outra “Otimizada para Disco”, etc. A isso, você ainda deve adicionar a camada extra de possível falha na conexão entre duas máquinas diferentes, o que inevitavelmente causará latência, embora essa quantidade de latência possa variar dependendo de como você configura essa conexão e da “distância” entre as duas máquinas. No entanto, o comportamento será o mesmo.
Como observação, esse tipo de comportamento também ocorre com coisas como o plugin Babel; no entanto, parece-me que o Plugin Babel consegue lidar com muito mais gravações “simultâneas”, mesmo que os “chats” sejam, na verdade, tópicos ocultos. A diferença está na forma como são apresentados e “atualizados”/“puxados”. Essa diferença de comportamento me levou à conclusão de que se trata de alguma correlação aplicacional que deriva de um problema do tipo FrontEnd “travando” o aplicativo (sendo que FrontEnd não é minha área de especialidade, ao contrário de BackEnd) e das operações envolvidas ao postar e pessoas permanecendo em um tópico aguardando que ele se “atualize sozinho” com dezenas de mensagens em um único minuto.
A isso, você ainda deve adicionar o fator humano: quando as pessoas sentem que o site está “lento” ou que um tópico “não está atualizando tão rápido quanto deveria”, elas vão apertar F5 sem parar, adicionando ainda mais carga. Mas boa sorte em “educar” nesse aspecto
