Je suis d’accord, quelle est la valeur d’un contenu que personne ne lit ? Et quelles personnes vont réellement s’asseoir et lire 10 000 messages du début à la fin ? 
Il est acceptable que certains sujets soient des conversations éphémères qui disparaissent complètement avec le temps, ce que nous appelions auparavant le trafic « voie rapide » par opposition au trafic « voie lente ».
Petite mise à jour :
Depuis que nous avons signalé et convenu de fermer tout ce qui se trouvait au-dessus de la limite (et de rétablir les limites), les performances semblent meilleures, beaucoup meilleures. Nous rencontrons encore quelques messages du type « En raison d’une charge extrême, ceci est temporairement affiché pour tout le monde comme le verrait un utilisateur non connecté », mais dans une mesure considérablement réduite.
Cela dit :
Encore une fois, un grand merci à tous pour votre aide et vos retours.
Postgres 12 aidera car il réduit la taille des tables et des index de 20 % selon les tests de @falco.
Y a-t-il déjà une date cible pour cela ?
J’ai commencé à effectuer des benchmarks aujourd’hui.
Il faut le laisser tourner un moment ici sur Meta pour surveiller les régressions de performance avant de le déployer partout.
Désolé de soulever à nouveau ce point, mais il s’agit d’un problème différent de la migration PostgreSQL (que je ne peux pas encore effectuer en raison de la taille).
Depuis la dernière reconstruction, la taille de ma base de données n’arrête pas d’augmenter :
La dernière reconstruction a eu lieu le 17 mai, et depuis, la taille de la base de données ne cesse de croître, atteignant 57,3 Go. La plus grande partie de cette taille provient de la table post_timings.
Mon principal problème est que j’essaie de réaliser la mise à jour PostgreSQL (qui réduira la taille des index de 20 %, mais ne résoudra pas ce problème à long terme). D’après les commentaires du personnel ici, cette taille n’est pas normale ; elle continuera donc d’augmenter, devenant d’une manière cauchemardesque coûteuse. Plus le temps passe, plus elle augmente, créant un cercle vicieux qui devient un enfer à maintenir. Mon problème principal demeure donc : existe-t-il un moyen de résoudre ce problème lié à post_timings ? Y a-t-il quelque chose à supprimer ?
Puis-je compacter les tables ou faire autre chose ?
Merci à tous pour votre aide.
Il n’y a pas d’échappatoire pour le moment. Si votre forum est vraiment grand, il aura une grande table de chronométrage.
Meta est une instance très ancienne, mais de taille moyenne, et sa table post_timings ne fait que 4 Go. En revanche, nous hébergeons une instance âgée de moins de deux ans, et la table post_timings devrait dépasser les 100 Go à l’heure actuelle.
L’hébergement de grands forums coûtera plus cher, et il n’y a pas d’échappatoire aujourd’hui.
Peut-être déplacer votre base de données vers un droplet autonome de 20 (80 Go de disque) et placer le site web sur un autre droplet de 10 ? 30 $ par mois pour ce qui semble être une communauté assez importante semble raisonnable.
Merci beaucoup pour votre aide, @Falco.
Eh bien, oui, comme je l’ai dit, je posais simplement la question car il n’y a pas de magie en ce qui concerne l’espace. J’examine la division, mais l’application sera trop lente en raison des performances (longue histoire, je note les tests et les présenterai ici plus tard pour que tout le monde puisse les utiliser s’ils les trouvent utiles).
J’ai effectué le test dont je vous ai parlé concernant la récupération d’une sauvegarde et autres, et je pense que cela peut être une bonne situation à exploiter, car ce que je vois immédiatement, c’est une réduction de 30 % de l’utilisation du disque (je suis toujours en train d’exécuter des tests pour vérifier qu’il ne manque rien), mais maintenant il y a un petit problème avec cette approche. Donc, même si les avantages immédiats sont importants, cela générera certains problèmes (d’autant plus que je ne sais pas si les images stockées sont mises en cache ou ne fonctionnent pas du tout, et oui, la sauvegarde les inclut).
Je prends des notes afin de pouvoir mettre à jour le sujet d’origine. Mon idée ici serait d’ajouter une petite série de notes pour les personnes qui pourraient s’inquiéter des performances et de toutes les modifications que j’ai apportées jusqu’à présent.
Est-ce que l’application d’un minuteur pour « supprimer automatiquement les réponses » constitue une bonne solution sur le plan technique ?
En fait, c’est une assez bonne idée qui résout le problème d’utilisabilité (car, comme nous l’avons dit, personne ne va lire 10 000 messages). La grande question est donc de savoir si cela serait trop lourd pour le serveur et la base de données.
Je ne suis pas sûr qu’un sujet de réponse avec 9000 messages, dont environ 8600 supprimés, soit bon pour les performances, mais j’en doute fortement. Qu’en penses-tu, @eviltrout ?
Je pensais que les publications « cachées » étaient complètement supprimées de la base de données après un certain temps, mais il semble que ce ne soit pas le cas.
Donc, d’un point de vue performance, mon idée ne peut pas résoudre le problème.
Y a-t-il un moyen de « purger » ces données ?
Les messages supprimés sont supprimés de manière douce. Cependant, ils sont souvent indexés, vous pourriez donc remarquer quelques améliorations lorsqu’un grand nombre d’entre eux sont retirés. Je ne le recommanderais pas pour autant. S’il est possible de créer un nouveau sujet dès qu’un sujet devient trop volumineux, cela pourrait vous être très utile.
Que voulez-vous dire par là ? Séparer la base de données et l’application web sur des serveurs distincts devrait améliorer vos performances. En effet, même s’il y aura une certaine latence entre les serveurs, votre Unicorn et votre Postmaster n’auront pas à se disputer le CPU et la RAM.
Assurez-vous que les serveurs sont situés dans la même région DO 
Désolé, vous avez raison, cela libérerait les deux et offrirait de meilleures performances que tout sur une seule machine (je comparais avec les ressources que j’utilise sur une seule machine et les ajustements que j’ai effectués jusqu’à présent).
C’est en fait une très bonne idée, laissez-moi essayer de résoudre le problème d’« impossibilité de reconstruire le conteneur de données » que je rencontre, et ce sera ma prochaine étape dans cette aventure.
J’ai cherché désespérément autour de ce sujet, mais je n’ai pas trouvé de documentation expliquant comment le faire de manière idéale. Existe-t-il un tel guide ?
Nous commençons également à atteindre une limite avec notre installation VPS unique standard. Notre dilemme plutôt unique concerne les discussions de jeu qui ont lieu pendant les matchs de hockey et provoquent des pics nets d’activité et de charge. Surtout si quelque chose d’extraordinaire se produit dans le jeu.
Il vous faudrait, je suppose, quelque chose de suffisamment puissant pour résister à vos moments les plus chargés. Ou alors, vous devriez augmenter les performances durant ces périodes. Peut-être chercher un VPS avec facturation à l’heure. Une solution (en suivant le conseil précédent) consisterait à déplacer le conteneur web vers un VPS extrêmement puissant, que vous ne payez que quelques heures lors des sessions de jeu.
Vous devez :
Exécuter PostgreSQL ailleurs (sur un droplet ou en utilisant un service hébergé comme Worry-Free Managed Database Hosting | DigitalOcean), et y déplacer vos données.
Cela peut également être réalisé en utilisant les produits conteneurisés de Discourse ? Web_only et data, n’est-ce pas ?
D’après mon expérience, aucun des approches actuelles ne résout directement ce problème, et il n’existe pas de solution linéaire. En fait, les séparer sur des machines différentes ne constitue pas une solution immédiate à ce problème.
Nous rencontrons également de fortes baisses de performance et des messages du type « le site est extrêmement sollicité, vous êtes affiché comme un utilisateur non connecté » lors d’événements majeurs (comme un jeu, comme l’a mentionné @ljpp), ce qui affecte l’ensemble du site, et pas seulement les personnes présentes dans ce sujet.
J’ai donc essayé deux approches différentes : une configuration séparée et une « grosse machine ». Les deux présentent ce type de problèmes. Mes instances sont surveillées avec Prometheus et les journaux sont visibles sur Grafana, etc., ce qui me donne un contrôle très granulaire sur les performances du matériel et des conteneurs. Je peux donc confirmer que, quoi que vous fassiez, le problème se produit de toute façon.
Si vous placez une grosse machine derrière, vous pouvez peut-être retarder un peu le problème, mais vous finirez par rencontrer des erreurs et des déconnexions de session, et la machine affichera une utilisation presque nulle, que ce soit pour le disque, le processeur ou la mémoire vive. Cela se produit aussi bien avec l’« installation par défaut » qu’avec les installations en « deux conteneurs ».
Avec des machines différentes, le problème reste le même, que les machines soient du même type ou que l’une soit « optimisée CPU » et l’autre « optimisée disque », etc. À cela s’ajoute la couche supplémentaire de risque de défaillance de la connexion entre deux machines distinctes, qui entraînera inévitablement des latences. Bien que cette latence puisse varier selon la manière dont vous configurez la connexion et la « distance » entre les deux machines, vous observerez le même comportement.
À noter que ce type de comportement se produit également avec des éléments comme le plugin Babel. Cependant, il me semble que le plugin Babel peut gérer beaucoup plus d’écritures « simultanées », même si les « chats » sont en réalité des sujets masqués. La différence réside dans la façon dont ils sont présentés et « actualisés »/« récupérés ». Cette différence de comportement m’a conduit à la conclusion qu’il s’agit d’une corrélation applicative découlant d’un problème côté FrontEnd « faisant planter » l’application (le FrontEnd n’étant pas mon domaine d’expertise, contrairement au BackEnd), combiné aux opérations en cours lors des publications et du fait que les utilisateurs restent sur un sujet en attendant qu’il se « mette à jour tout seul » avec des dizaines de messages en une seule minute.
À cela s’ajoute le facteur humain : lorsque les utilisateurs perçoivent le site comme « lent » ou qu’un sujet « ne se met pas à jour aussi vite qu’il le devrait », ils rafraîchissent la page à outrance (F5), ce qui ajoute encore plus de charge. Mais bonne chance pour les « éduquer » à ce sujet
