Estoy de acuerdo, ¿qué valor tiene el contenido que nadie lee? ¿Y qué personas se sentarán realmente a leer 10,000 publicaciones de principio a fin? 
Está bien que algunos temas sean chats efímeros que desaparezcan por completo con el tiempo, lo que anteriormente llamábamos tráfico de “carril rápido” versus “carril lento”.
Pequeña actualización:
Dado que se reportó y acordó cerrar todo lo que está por encima del límite (y restablecer los límites), el rendimiento parece ser mejor, mucho mejor. Todavía recibimos algunos mensajes de “Debido a una carga extrema, esto se muestra temporalmente a todos como lo vería un usuario desconectado”, pero en una medida considerablemente menor.
Dicho esto:
Una vez más, un enorme agradecimiento a todos por ayudar y dar su opinión.
Postgres 12 ayudará, ya que reduce el tamaño de las tablas y los índices en un 20% en las pruebas de @falco.
¿Ya hay una fecha objetivo para eso?
Hoy empecé a realizar pruebas de rendimiento.
Necesito dejarlo ejecutándose un tiempo aquí en Meta para detectar posibles regresiones de rendimiento antes de implementarlo en todos los entornos.
Lo siento por traer esto de nuevo, pero es un problema diferente al de la migración de PostgreSQL (que aún no puedo realizar debido al tamaño).
Desde la última reconstrucción, el tamaño de mi base de datos no deja de aumentar:
La última reconstrucción fue el 17 de mayo y, desde entonces, el tamaño de la base de datos no deja de crecer, alcanzando los 57.3 GB, y el mayor volumen se encuentra en la tabla post_timings.
Mi principal problema con esto es que estoy intentando realizar la actualización a PostgreSQL (lo cual reducirá el tamaño de los índices en un 20%, pero no resolverá esto a largo plazo). Y, según los comentarios del personal aquí, este tamaño no es lo normal, por lo que seguirá aumentando y se volverá costoso de manera pesadillesca. Cuanto más tiempo pasa, más aumenta y crea un ciclo que se vuelve infernal de mantener. Por lo tanto, mi problema principal sigue vigente: ¿hay alguna manera de abordar este asunto de post_timings? ¿Algo que pueda eliminar?
¿Puedo compactar tablas o algo similar?
Gracias a todos por su ayuda.
No hay forma de evitarlo en este momento. Si tu foro es realmente grande, tendrá una tabla de tiempos muy grande.
Meta es una instancia muy antigua, pero es de tamaño medio y tiene una tabla post_timings pequeña de 4 GB. Por otro lado, alojamos una instancia que tiene menos de 2 años y la tabla post_timings debería superar los 100 GB en este momento.
Alojar foros grandes te costará más, y no hay formas de evitarlo hoy.
¿Quizás mover tu base de datos a un droplet independiente de $20 (80 GB de disco) y poner la web en otro droplet de $10? $30 al mes para lo que parece ser una comunidad bastante grande suena razonable.
Muchas gracias por tu ayuda, @Falco.
Bueno, sí, como dije, solo preguntaba porque no hay magia cuando se trata del espacio. Estoy investigando la división, pero la aplicación se volverá demasiado lenta debido al rendimiento (larga historia; estoy tomando nota de las pruebas y las presentaré aquí más tarde para que todos puedan aprovecharlas si les resultan útiles).
Realicé la prueba que te mencioné sobre la recuperación de una copia de seguridad y cosas por el estilo, y creo que esta puede ser una buena situación para aprovechar, ya que lo que puedo ver inmediatamente es que hay un 30 % menos de uso de disco (aún estoy ejecutando algunas pruebas para verificar que no falte nada), pero ahora hay un pequeño problema con este enfoque. Así que, aunque los beneficios inmediatos son grandes, esto generará algunos problemas (aún más porque no sé si está en caché o si no funciona en absoluto en términos de imágenes almacenadas, y sí, la copia de seguridad las incluye).
Estoy tomando notas para poder actualizar la publicación original; mi idea aquí sería agregar una pequeña serie de notas para las personas que puedan preocuparse por el rendimiento y todas las cosas que he estado modificando hasta ahora.
¿Es aplicar un temporizador de “eliminar respuestas automáticamente” una buena solución desde el punto de vista técnico?
En realidad, esta es una idea bastante buena y resuelve el problema de la usabilidad (porque, como dijimos, nadie va a leer 10 mil mensajes). Así que la gran pregunta es si eso sería muy exigente para el servidor y la base de datos.
No estoy seguro de si un tema de 9000 respuestas con ~8600 de ellas eliminadas es bueno para el rendimiento, pero de alguna manera lo dudo. ¿Qué opinas @eviltrout?
Pensé que las publicaciones “ocultas” se eliminaban por completo de la base de datos después de cierto tiempo, pero ahora veo que probablemente no sea así. Por lo tanto, desde el punto de vista del rendimiento, mi idea no puede resolver el problema.
¿Existe alguna forma de “eliminar” estos datos?
Los posts eliminados se eliminan de forma suave. Sin embargo, a menudo están indexados, por lo que podrías notar algunas mejoras cuando se eliminen varios. No lo recomendaría, aunque. Si hay alguna manera de moverte a un nuevo tema una vez que uno se vuelve grande, eso podría servirte bien.
¿Qué quieres decir con esto? Tener la base de datos y la aplicación web en servidores separados debería darte más rendimiento, ya que, aunque habrá cierta latencia entre los servidores, tu Unicorn y Postmaster no tendrán que competir por CPU y RAM.
Asegúrate de que los servidores estén en la misma región de DO 
Lo siento, tienes razón, eso liberaría ambos y obtendría un mejor rendimiento que todo en uno solo (estaba comparando con los recursos que estoy usando en una sola máquina y los ajustes que he estado haciendo hasta ahora).
Esa es realmente una muy buena idea, déjame intentar resolver el problema de “no se puede reconstruir el contenedor de datos” que tengo y ese será mi próximo salto en este viaje.
He buscado a fondo en torno a este tema, pero no he encontrado documentación sobre cómo hacerlo de manera ideal. ¿Existe alguna guía?
También estamos empezando a toparnos con un límite en nuestra instalación estándar de un solo VPS. Nuestro dilema bastante único son los chats del juego, que tienen lugar durante los partidos de hockey y causan picos agudos en la actividad/carga. Especialmente si ocurre algo extraordinario en el juego.
Supongo que necesitarías algo lo suficientemente potente para soportar tus momentos de mayor actividad. O bien, aumentar el rendimiento durante esos periodos. Quizás busques un VPS que puedas pagar por hora. Una solución (continuando con el consejo anterior) sería mover el contenedor web a un VPS extremadamente potente que pagues solo unas pocas horas cuando haya juegos.
Necesitas:
Ejecutar PostgreSQL en otro lugar (un droplet o usar un servicio alojado como Worry-Free Managed Database Hosting | DigitalOcean) y mover tus datos allí.
Sigue Ejecutando Discourse con un servidor PostgreSQL separado
¿Y esto también se puede lograr utilizando los productos en contenedores de Discourse? ¿Web_only y data, correcto?
Por mi experiencia, esto no se resuelve directamente con ningún enfoque actual ni tiene una solución lineal. De hecho, separarlos en máquinas distintas no es una solución inmediata para ese problema.
También experimentamos caídas severas y mensajes como “el sitio está extremadamente ocupado, así que lo ves como alguien que no ha iniciado sesión” cuando ocurre un evento grande (como un juego, como mencionó @ljpp), y eso afecta a todo el sitio, no solo a las personas dentro de ese tema.
Así que probé dos enfoques diferentes: una configuración separada y una “máquina grande”; ambos presentan este tipo de problemas. Mis instancias se monitorean con Prometheus y los registros son visibles en Grafana, etc., por lo que tengo un control muy granular del rendimiento del hardware/contenedores, y puedo confirmar que realmente no importa qué hagas, el problema ocurre de todos modos.
Si colocas una máquina grande detrás, quizás puedas retrasarlo un poco, pero eventualmente obtendrás errores y caídas de sesiones, y la máquina estará con casi ningún uso, ya sea de disco, CPU o RAM. Esto ocurre tanto con la “instalación predeterminada” como con las instalaciones de “dos contenedores”.
Con máquinas distintas, el problema es el mismo, independientemente de si las máquinas son del mismo tipo o si una es “optimizada para CPU” y la otra “optimizada para disco”, etc. A esto debes agregar la capa adicional de posibles fallos en la conexión entre dos máquinas distintas, lo que inevitablemente causará latencia, aunque esta cantidad de latencia puede variar según cómo configures esa conexión y “qué tan lejos” estén las dos máquinas entre sí, pero obtendrás el mismo comportamiento.
Como nota, este tipo de comportamiento también ocurre con cosas como el plugin de Babel; sin embargo, me parece que el plugin de Babel puede manejar muchas más escrituras “simultáneas”, aunque los “chats” en realidad son temas ocultos. La diferencia radica en cómo se presentan y se “actualizan”/“recuperan”. Esta diferencia en el comportamiento me ha llevado a concluir que se trata de alguna correlación aplicacional que deriva de un problema del tipo FrontEnd que “crashea” la aplicación (siendo que el FrontEnd no es mi área de especialización, a diferencia del BackEnd) y las operaciones en curso al publicar y que las personas permanezcan en un tema esperando que se “actualice automáticamente” con decenas de mensajes en un solo minuto.
A esto también debes agregar el factor humano: cuando las personas sienten que el sitio está “lento” o que un tema “no se actualiza tan rápido como debería”, harán F5 sin parar, añadiendo más carga. Pero buena suerte “educando” en ese sentido
