Agree, what is the value of content that nobody reads? And which people are gonna actually sit down and read 10,000 posts from start to finish? 
It’s OK for some topics to be ephemeral chats which disappear entirely over time, what we’ve previously called “fast lane” versus “slow lane” traffic.
Small Update:
Since reported and agreed on closing everything above the mark (and re-establishing the limits) performance seems to be better, a lot better. We still get some “Due to extreme load, this is temporarily being shown to everyone as a logged out user would see it” but considerably lower.
With that said:
Again, a huge thanks to everyone for helping and giving feedback.
Postgres 12 will help as it reduces table and index size by 20% in @falco’s testing.
Is there a target date for that yet?
I started doing bechmarks today.
Gotta let it run for a while here on Meta so we can watch for performance regressions before rolling it out everywhere.
I’m sorry for rising this one up again, but this is a different issue from the PostGreSQL Migration. (Which I’m not able to do yet due to size).
Since last rebuild my Database Size won’t stop increasing:
Last rebuild was on May 17th and since then the DB Size won’t stop increasing, reaching 57.3GB and the big size is on the post_timings table.
My main issue with this is that I’m trying to do the PostGreSQL update (which will reduce index size by 20% but won’t solve this in the long run). And from the comments here from the Staff that size is not the norm, so it will keep increasing and becoming nightmareshly expensive. The more time passes, the more it increases and creates a loop that becomes hell to maintain. So my main issue prevails, is there a way to tackle this post_timings thing? Something to delete?
Can I compact tables or something?
Thanks to everyone for their help.
There is no way around it at the time. If your forum is really big, it will have a big timings table.
Meta is a really old instance, but it is mid-sized and has a small 4GB post_timings table. In the other hand we host one instance that is less than 2 years old and the post_timings table should be over 100GB by now.
Hosting big forums will cost you more, and there are no ways around it today.
Maybe move your Database to a standalone $20 droplet (80GB disk) and put the web in another $10 droplet? $30 in monthly costs for what appears to be a quite big community sounds reasonable.
Thank you very much for your help, @Falco.
Welp, yeah, as I said, just asking because there isn’t magic when it comes to space. I’m looking into the division but then the app one will be too slow due to perf (long story, I’m taking note of the tests and will present them here later for everyone else to make use if they find them useful).
I did the test I asked you about regarding recovering a backup and stuff and I think that this can be a good situation to leverage from since what I can immediately see is that there is 30% less disk usage (I’m still running some test to check if there isn’t anything missing) but now there is an small issue with this approach so even though the immediate benefits are great this will generate some issues (even more because I don’t know if it is cached or not working at all in terms of stored images, and yes, the backup includes them).
I’m taking notes so that I can update the OP, my idea here would be to add a small series of notes for people that may worry about performance and all the things I’ve been modifying so far.
Is applying “auto-delete replies” timer good solution to this technically wise?
Actually this is a pretty good idea and solves the problem of usability (because, as we said, no one is going to read 10K messages). So the big question is if that would be taxating to the server and database.
I’m not sure if a 9000 reply topic with ~8600 of them deleted is good for perf, but somehow I doubt it. What say you @eviltrout?
I thought that “hidden” posts are completely removed from database after some time, but now I see that is probably not the case.
So performance wise my idea can’t solve the problem.
Is there any way to “purge” this data?
Deleted posts are soft deleted. However, they are often indexed so you might notice some improvements when a bunch are removed. I wouldn’t recommend it though. If there’s any way to move to a new topic once one gets large that might serve you well.
What do you mean by this? Having the database and the web app in separate servers should give your more performance, because while there will be some latency between servers, your Unicorn and Postmaster won’t have to compete for CPU and RAM.
Make sure the servers are in the same DO region 
Sorry, you are right, that would free them both and get better performance than everything on a single one (I was comparing to the resources I’m using on a single machine and the tweaks I’ve been doing so far).
That is actually a very good idea, let me try to solve the “unable to rebuild the data container” issue I have and that will be my next jump in this journey.
Ho cercato a lungo su questo argomento, ma non sono riuscito a trovare documentazione su come farlo in modo ottimale. Esiste una guida del genere?
Stiamo anche iniziando a raggiungere un limite con la nostra installazione standard su VPS singola. Il nostro dilemma piuttosto unico riguarda le chat di gioco, che si svolgono durante le partite di hockey e causano picchi netti di attività/carico. Soprattutto se accade qualcosa di straordinario durante la partita.
Immagino che dovresti avere qualcosa di abbastanza potente da resistere ai tuoi momenti di maggiore affluenza. Oppure dovresti aumentare le prestazioni durante questi periodi. Forse cerca un VPS che puoi pagare a ore. Una soluzione (continuando il consiglio precedente) sarebbe quella di spostare il contenitore web su un VPS estremamente potente, che paghi solo per poche ore quando ci sono i giochi.
Devi:
Eseguire PostgreSQL altrove (su un droplet o utilizzando un servizio gestito come Worry-Free Managed Database Hosting | DigitalOcean) e spostare i tuoi dati lì.
Seguire la guida Eseguire Discourse con un server PostgreSQL separato
E questo può essere ottenuto anche utilizzando i prodotti containerizzati di Discourse? Web_only e data, giusto?
Dalla mia esperienza, questo problema non è risolto direttamente da alcun approccio attuale né ha una soluzione lineare. In realtà, separarli su macchine diverse non è una soluzione immediata per tale questione.
Anche noi sperimentiamo forti cali e messaggi come “il sito è estremamente occupato, quindi ti stai mostrando come se non fossi connesso” quando si verifica un evento importante (come un gioco, come ha detto @ljpp), e ciò trascina giù l’intero sito, non solo le persone all’interno di quel topic.
Quindi, ho provato due cose diverse: una configurazione separata e una “macchina grande”. Entrambe presentano questo tipo di problemi. Le mie istanze sono monitorate con Prometheus e i log sono visibili su Grafana, ecc., quindi ho un controllo molto granulare sulle prestazioni hardware/container e posso confermare che, in realtà, non importa cosa si faccia, il problema si verifica comunque.
Se metti una macchina grande dietro di essa, potresti ritardarlo leggermente, ma otterrai comunque errori e cadute di sessione, e la macchina rimarrà con un utilizzo quasi nullo, sia per disco, CPU o RAM. Questo accade sia con l’“installazione predefinita” che con le installazioni a “due container”.
Con macchine diverse, il problema è lo stesso, indipendentemente dal fatto che le macchine siano dello stesso tipo o che una sia “CPU-Optimized” e l’altra “Disk-Optimized”, ecc. A questo devi aggiungere anche il livello aggiuntivo di possibile guasto della connessione tra due macchine diverse, che inevitabilmente introdurrà latenza, sebbene questa quantità di latenza possa variare in base a come configuri tale connessione e a “quanto distanti” siano le due macchine l’una dall’altra. Tuttavia, otterrai lo stesso comportamento.
Come nota, questo tipo di comportamento si verifica anche con cose come il plugin Babel; tuttavia, mi sembra che il plugin Babel possa gestire molte più scritture “simultanee”, anche se le “chat” sono in realtà topic nascosti. La differenza sta nel modo in cui vengono presentate e “aggiornate”/“recuperate”. Questa differenza di comportamento mi ha portato alla conclusione che si tratti di una correlazione applicativa che deriva da un problema di tipo FrontEnd che “fa crashare” l’app (essendo il FrontEnd non il mio ambito di competenza, a differenza del BackEnd) e dalle operazioni in corso tramite la pubblicazione e le persone che rimangono su un topic in attesa che si “aggiorni da solo” con decine di messaggi in un singolo minuto.
A questo devi aggiungere anche il fattore umano: quando le persone percepiscono che il sito è “lento” o che un topic “non si aggiorna velocemente come dovrebbe”, premeranno F5 all’infinito, aggiungendo ulteriore carico. Ma buona fortuna nel “educare” su questo aspetto 