Pic d'utilisation du disque pendant la sauvegarde, Discourse s'est bloqué violemment :-(

Soutien Installation
1

Ce matin vers 5 h 35, l’utilisation de mon disque par mon forum a brusquement augmenté, provoquant un crash et une mise hors ligne complète. J’ai dû redimensionner l’image Digital Ocean pour remettre le tout en marche. Ouf.

Voici mon utilisation du disque sur les 24 dernières heures :

image
image2050×698 35.8 KB

Question : quels types de journaux ou d’analyse post-mortem puis-je examiner pour essayer de comprendre ce qui s’est passé ?! J’ai consulté les journaux dans le panneau de contrôle de Discourse, mais aucun indice n’apparaît… ils s’arrêtent simplement lorsque le site a planté, puis reprennent aussitôt que le site est revenu en ligne.

1 « J'aime »
2

Je commencerais par déterminer quel répertoire pose problème. Ma méthode habituelle consiste à entrer dans /var/discourse, puis à exécuter du -h -d 1. Prenez le plus grand répertoire, entrez-y et répétez l’opération jusqu’à ce que vous trouviez le coupable. Une fois que vous l’avez, cela pourrait vous donner une idée de ce qui se passe.

3 « J'aime »
3

Peut-être une sauvegarde automatique ?

3 « J'aime »
4

Oui, les sauvegardes sont une source courante de ce type d’échec — à quoi ressemble l’utilisation du disque sur une période de 7 jours ?

Notez également que les téléchargements locaux sont inclus dans ces sauvegardes. Ainsi, si vous avez enregistré une augmentation significative des téléchargements vers 18h00, cela aurait également augmenté la taille de l’archive de sauvegarde.

5 « J'aime »
5

Hmm. J’ai été en train de transférer des fichiers depuis S3 vers mon serveur local, mais le processus semble s’exécuter en temps réel, traitant seulement quelques centaines d’images (environ 300 Ko chacune) à la fois, soit environ 0,1 Go par lot. Au cours de la dernière semaine, j’ai peut-être exécuté le script 20 fois, ce qui donne 20 lots, soit environ 2 Go d’espace disque au total. Ce qui ne posait aucun problème car j’avais largement de la place.

Est-il possible que, même si le script semble déplacer les fichiers en temps réel (en les téléchargeant depuis S3 et en les uploadant immédiatement vers Digital Ocean), il existe aussi un certain délai lié à un travail mis en file d’attente qui se serait déclenché à 5 h 30, en rapport avec le déplacement de ces images ?

(Aussi : j’exécutais ces lots manuellement jusqu’à 21 h, donc à ma connaissance, le serveur ne faisait que des opérations normales entre 21 h et 5 h 30, moment où il s’est arrêté.)

Voici mon utilisation du disque sur 7 jours. Elle augmentait régulièrement à cause des images importées, mais vous pouvez voir où elle a atteint 100 % à 5 h 30 :

image
image2158×688 47.9 KB

Y a-t-il des fichiers journaux qui pourraient donner des indices sur ce qui s’est passé à 5 h 35, en dehors de ceux que je vois dans l’onglet ‘Journaux’ ?

1 « J'aime »
6

Hmm. Mes sauvegardes sont configurées pour être envoyées vers S3 tous les 2 jours, mais rien depuis le 9 ?

image
image1694×856 73.4 KB

Vue « Sauvegardes » de Discourse

image
image1702×744 38.3 KB

Vue Amazon S3

image
image1586×482 68.6 KB

Par ailleurs, après avoir vu ce qui précède, j’ai cliqué sur le bouton dans Discourse pour déclencher une sauvegarde. Cela a pris 28 minutes et semble avoir fonctionné correctement ; je vois maintenant ce fichier .tar.gz à la fois dans les vues des sauvegardes de Discourse et d’Amazon S3. Alors pourquoi mes sauvegardes automatiques ne se déclenchent-elles pas ?! Arghhh.

7

Je suis perplexe… aucun de ces éléments n’est particulièrement volumineux :

root@x-app:/var/www/discourse# du -h -d 1

3.5M	./lib
104K	./bin
8.0K	./.tx
148M    ./public
8.0K	./.bundle
14M     ./plugins
4.3M	./db
4.0K	./log
532M	./tmp
8.9M	./spec
17M     ./config
556M	./vendor
8.0K	./images
329M	./.git
2.0M	./script
80K	    ./docs
2.5M	./test
16K	    ./.github
17M	    ./app
1.6G	.

Même en examinant l’espace disque global à l’intérieur du conteneur Docker, il n’est pas aussi rempli qu’avant. J’avais un serveur Droplet DigitalOcean de 80 Go, c’est celui qui a atteint 100 %. Alors je l’ai redimensionné à 160 Go, le doublant. En théorie, cela signifie que l’un de ces éléments devrait être à 50 %, n’est-ce pas ?

root@x-app:/var/www/discourse# df -h

Filesystem      Size  Used Avail Use% Mounted on
overlay         155G   58G   98G  38% /
tmpfs            64M     0   64M   0% /dev
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
shm             512M  2.6M  510M   1% /dev/shm
/dev/vda1       155G   58G   98G  38% /shared
tmpfs           3.9G     0  3.9G   0% /proc/acpi
tmpfs           3.9G     0  3.9G   0% /proc/scsi
tmpfs           3.9G     0  3.9G   0% /sys/firmware
8

Vous aviez des pics presque à 100 % chaque soir auparavant — il semble que celui-ci vous ait fait basculer. Je pense que les sauvegardes précédentes ont échoué par manque d’espace lors de la création du fichier de sauvegarde local à envoyer vers S3, mais elles ont simplement échoué sans casser votre forum. Vous avez finalement remarqué le problème lorsque le manque d’espace a rendu PostgreSQL (ou Redis, ou autre, ce n’est pas vraiment important) instable au moment précis où il a fait tomber votre forum.

(Avec près de 100 Go d’images sur mon serveur, je fais des sauvegardes planifiées de Discourse sans les uploads, mais avec les miniatures. Ensuite, je fais une sauvegarde hors site basée sur les fichiers du répertoire des sauvegardes en premier, puis du répertoire des uploads en second. J’ai testé cette méthode pour la récupération ; elle a servi de base à une migration de site que j’ai effectuée l’année dernière. Stocker des archives tar de 100 Go chaque soir serait fou.)

7 « J'aime »
9

Aha, donc ces petits pics sont Discourse qui tente de faire une sauvegarde ! Cela éclaire la situation.

Voici donc à nouveau mon graphique sur les 7 derniers jours.

image
image2158×688 47.9 KB

Peut-être que ce que nous observons, c’est :

  1. À plusieurs reprises au cours de la semaine dernière, Discourse a tenté de réaliser une sauvegarde. Ce processus consomme temporairement beaucoup d’espace disque, et à chaque tentative, il n’y avait plus assez d’espace, si bien qu’aucune de ces sauvegardes n’a fonctionné.

  2. Puis, lorsqu’il a essayé à nouveau de faire une sauvegarde hier soir, il a avancé un peu plus loin, mais malheureusement, cela a fait planter le site.

Cela semble cohérent puisque la dernière sauvegarde réussie remonte au 9 juillet. Il a donc attendu 2 jours (selon mes paramètres) et a réessayé le 11 juillet. Cela a échoué, alors il a attendu 24 heures et a réessayé les 12, 13 et enfin le 14, avec cette tentative fatale.

Si c’est bien ce qui s’est passé, j’aimerais voir :

  1. De meilleures notifications de la part de Discourse lorsqu’une sauvegarde échoue

  2. Peut-être que Discourse devrait automatiquement « échouer » une sauvegarde (en générant une notification) si, au moment où elle commence, il reste moins de x % (10 % ?) d’espace disque libre. Ainsi, elle ne démarre même pas si l’espace disque est déjà trop serré.

Au fait, si c’est vraiment ce qui s’est passé, alors en regardant la première sauvegarde échouée, le 11 juillet, on voit qu’il y avait environ 40 % d’espace disque libre (ce qui équivaudrait à environ 32 Go !!!), mais cela n’a pas suffi pour que la sauvegarde se termine avec succès. Est-ce exact ?! Pourquoi Discourse aurait-il besoin d’autant d’espace temporaire ou de travail pour produire une sauvegarde ?

2 « J'aime »
10

Cela n’a pas nécessairement avancé davantage hier soir ; vous avez simplement « perdu une course » — ce qui se produit lorsque l’espace vient à manquer dépend du composant touché en premier par le problème.

Si elle échoue à créer une sauvegarde, je m’attends plutôt à ce qu’elle tente d’envoyer un message, mais si l’espace disque est épuisé, cela pourrait ne pas réussir. :scream:

Un pourcentage fixe ne vous apprend pas vraiment grand-chose ; la base de données peut être minuscule par rapport aux téléversements, ou l’inverse, et il y a des variables comme l’inclusion des vignettes et celle des téléversements. Je pourrais imaginer une exigence d’espace libre configurable afin que vous puissiez l’ajuster pour votre site, je suppose.

Je ne sais pas comment vous évaluez « démesuré » — cela ne me semble pas démesuré.

2 « J'aime »
11

C’est juste ; comme vous le soulignez, de nombreuses variables sont en jeu.

Ah, la « bonne » façon de faire consisterait à calculer la quantité d’espace nécessaire pour la sauvegarde, etc., etc. Mais pour garder les choses super simples, oui, un simple pourcentage fixe. Je me dis juste… si les deux options sont « votre site pourrait planter complètement et se mettre hors ligne » ou « voici une solution imparfaite mais rapide au problème », je choisis la seconde, merci. :wink:

Et en parlant de remerciements, merci à TOI pour toute ton aide concernant la migration et pour tes réflexions sur ce sujet. :+1:t2:

1 « J'aime »
12

Estimer l’espace nécessaire pour une sauvegarde est l’un des problèmes difficiles en informatique… C’est un cousin éloigné de la barre de progression. :wink:

Sérieusement, cela inclut un dump de base de données, et je ne sais pas comment l’estimer à l’avance. Si vous avez suffisamment d’images pour que l’espace devienne un problème, les inclure dans les archives de sauvegarde sort probablement des pratiques courantes.

Habituellement, en administration système, la surveillance de l’espace libre et l’état des sauvegardes constituent une charge administrative plutôt qu’une charge applicative. C’est en partie ce pour quoi les gens paient lorsqu’ils font héberger leur Discourse par CDCK.

Il existe de nombreuses autres façons de manquer d’espace. Je sais que vous vous concentrez sur celui qui vous a affecté, mais le problème est plus général, et je pense que cela se traite normalement comme une surcharge administrative.

4 « J'aime »
13

Sans vouloir jeter un froid sur cette fête, mais en réalité, en lisant les messages, il n’y a aucune confirmation solide que le processus de sauvegarde Discourse est à l’origine du problème.

Pourquoi ne pas confirmer à 100 % que ce problème est causé par un processus de sauvegarde quotidien ? Il y a plus d’un processus en cours d’exécution dans les fichiers crontab quotidiens sur les hôtes.

@pnoeric a-t-il effectué un du sur le système de fichiers /var/discourse (en dehors du conteneur) ?

Dans vos notes, @pnoeric écrit :

root@x-app:/var/www/discourse# du -h -d 1

Mais cela a complètement manqué le répertoire partagé Discourse, incluant toutes les sauvegardes et les téléchargements ! Et cela manque également tous les fichiers Docker (et les images) sur l’hôte (qui peuvent devenir volumineux si les images ne sont pas nettoyées au fil du temps).

L’endroit où exécuter cette vérification est en dehors du conteneur (pas dans le conteneur !) :

Par exemple (en dehors du conteneur) :

cd /var/discourse 
/var/discourse# du -sh *
4.0K	bin
4.0K	cids
56K	containers
12K	discourse-doctor
24K	discourse-setup
164K	image
24K	launcher
4.0K	LICENSE
12K	README.md
24K	samples
8.0K	scripts
62G	shared
148K	templates

Vous pouvez voir, sur cet hôte, que le répertoire shared fait 62 Go.

Et aussi depuis /var du système de fichiers (en dehors du conteneur) :

cd /var
# du -sh *
511M	cache
20K	composetest
62G	discourse
1.6G	docker
8.0K	legacy
52G	lib
4.0K	local
0	lock
4.0K	locks
5.7G	log
24K	logs
64K	mail
4.0K	opt
4.0K	registry
4.0K	shared
1.9M	spool
48K	tmp
25G	 linux_app
2.2G	www

Je ne cherche pas à jeter un froid sur cette fête, mais avant de proposer un grand nombre de « correctifs » pour Discourse, il serait très bon de confirmer à 100 % que le cron de sauvegarde Discourse est le vrai problème.

Nous n’avons eu aucun problème avec le processus de sauvegarde Discourse actuel et, de plus, la gestion du système de fichiers sur l’hôte n’est PAS une tâche Discourse en soi.

Ici :

du

Filesystem     1K-blocks      Used Available Use% Mounted on
udev            32892500         0  32892500   0% /dev
tmpfs            6584232      2136   6582096   1% /run
/dev/md2       470927632 215969956 230966124  49% /
tmpfs           32921160         0  32921160   0% /dev/shm
tmpfs               5120         0      5120   0% /run/lock
tmpfs           32921160         0  32921160   0% /sys/fs/cgroup
/dev/md0          482922     75082    382906  17% /boot
/dev/sda1         244988      4636    240353   2% /boot/efi
tmpfs            6584232         0   6584232   0% /run/user/1000
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/0f8be368b0154285423630ad50148ee2d5fdcb357c46125eafa7374ca34ef29a/merged
shm               524288      1620    522668   1% /var/lib/docker/containers/ca7b55fc5a0c123f7b2b1234ea210aa8286a34167cba9344b7929547bd323c9b/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7cd7e8b5b35b496eaed68753cc995e9303499a24721062055e2f06beb07e26c8/merged
shm                65536         0     65536   0% /var/lib/docker/containers/3cc0c90c3e3a5db6692e7b5d21727fbb1c13c8e07e48e4f6d954214fc03694a9/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/31533fdf68033eed96dab4f9df89025ea3dab172ed48b6ce6431840a8df1c8ea/merged
shm               524288         0    522668   0% /var/lib/docker/containers/631fbabedda9a430dd8204ec66fb45c7514d948025124171b960ea424e28d5d4/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/7a3ba2223ee93bc868b52b3707799d0fd7b4ca6dcc0df29f20c2c98a53903ff1/merged
shm                65536         0     65536   0% /var/lib/docker/containers/7a145366268c8ac5543a4555dc1bfc63c1e85a654e4c793e96fc2cc2e8514388/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/add4bdd7bd88df7a0e05dff21896d3ef796f7cf2ff9759e0bb04b1953f16cd95/merged
shm                65536         0     65536   0% /var/lib/docker/containers/123743e122089b94660a6bdd2a9e55055ad91b6f75cce4ac760f36066bcf14d0/mounts/shm
overlay        470927632 215969956 230966124  49% /var/lib/docker/overlay2/b376ff32eaac0c58463e8b99b6db9ec0da3405c3f7a9f00b5430f10e07d372b0/merged
shm               524288         0    524288   0% /var/lib/docker/containers/63c52bc571b5f0d2544417da10efc37d3957e7a38f44bc8325145e795ee29559/mounts/shm

Regardons les fichiers Docker :

# cd /var/lib
# du -sh docker
30G	docker

Et nos images Docker sont régulièrement nettoyées et supprimées.

@bartv a correctement suggéré de commencer ici :

Je commencerais par identifier quel répertoire explose. Ma méthode standard consiste à entrer dans /var/discourse puis à exécuter du -h -d 1. Prenez le plus grand répertoire, entrez-y et répétez jusqu’à trouver le suspect. Une fois que vous l’avez, cela pourrait vous donner une idée de ce qui se passe.

C’est un bon début, mais il peut y avoir beaucoup d’autres endroits sur le système de fichiers de l’hôte qui peuvent remplir le système de fichiers, y compris Docker, les fichiers core, etc.

Un graphique montrant un pic en pourcentage une fois par jour ne suffit pas pour affirmer, avec autorité, que le processus cron de sauvegarde Discourse est la cause racine. Cela pourrait l’être, mais cela pourrait ne pas l’être, selon les preuves jusqu’à présent !

6 « J'aime »
14

C’est super. Je vais essayer tout ce que tu as mentionné. Merci.

1 « J'aime »
15

Oui, c’est évidemment une sauvegarde.

Non, il y a largement assez de confirmations : les pics surviennent à intervalle de deux jours, à une exception près, et la fréquence des sauvegardes est réglée sur deux jours. Notre expérience passée sur Meta a montré exactement ce mode de défaillance.

Oui, c’est un plan solide pour avancer. La première recommandation pour les personnes qui commencent à atteindre la limite d’espace disque sur leur VPS est le stockage des uploads hors machine avec le mécanisme S3, bien sûr.

8 « J'aime »
16

Puisque @pnoeric tente de se déplacer hors de S3 pour les images, stocker plusieurs copies de toutes les images dans une sauvegarde qui se trouve sur S3 ne permettrait pas d’atteindre l’objectif de quitter S3. @pnoeric, cela me confond — si vous voulez quitter S3 mais ne déplacer qu’une fraction des fichiers parce que vous stockez toutes les images sur S3 en plusieurs copies de sauvegarde, quel est l’intérêt ?

Quoi qu’il en soit, je tentais de montrer à quoi ressemblent les alternatives. La sauvegarde est difficile, surtout si vous souhaitez un jour pouvoir restaurer à partir de la sauvegarde.

Je suis passé hors de « S3 » (les espaces Digital Ocean dans mon cas) après avoir eu suffisamment d’espace serveur et sans une croissance ou un trafic considérable qui justifierait de rester sur « S3 », mais je suis une exception, ce qui explique probablement pourquoi je n’ai jamais reçu le moindre commentaire sur ma PR qui résout la corruption des données lors de la migration hors de S3. :stuck_out_tongue: Je m’attends donc à ce que mon régime de sauvegarde soit très inhabituel.

4 « J'aime »
17

Dans mon cas, j’ai un grand nombre d’images, ce qui implique un important volume de transfert de données lorsque les utilisateurs consultent ces images… Ainsi, lorsque les images étaient hébergées sur Amazon S3, c’est la facture de bande passante qui m’a vraiment ruiné. Surtout quand j’ai réalisé que je pouvais stocker toutes les images sur le droplet DO et que cela serait inclus dans les frais de bande passante et de stockage que je paie déjà. (À un moment donné dans le futur, cela pourrait avoir du sens de remettre les choses sur S3, ou il pourrait aussi être plus judicieux de simplement augmenter la taille de mon droplet DO…)

J’ai donc commencé avec S3, puis j’ai réalisé mon erreur. D’où ma situation actuelle, en utilisant votre excellent code pour migrer toutes les images de S3 vers DO.

Conserver une sauvegarde complète (images incluses) sur S3 est une toute autre histoire : elle est en « stockage froid » sur S3 et n’est pas consultée sauf en cas de problème. Donc pas de grosses factures de bande passante.

En outre : j’ai réfléchi davantage à la situation des sauvegardes et de l’utilisation du disque. Je maintiens toujours qu’il manque quelque chose ici. Peut-être s’agit-il simplement d’un message d’avertissement ou d’une meilleure documentation. Mais mon instance Discourse utilisait seulement 60 % de l’espace disque, et mes sauvegardes hors site échouaient. Une sorte d’estimation de l’espace disque nécessaire, ou un avertissement en cas de manque d’espace, ou quelque chose de ce genre semblerait bien meilleur que ce qui se passe actuellement quand il n’y a pas assez d’espace, à savoir : aucune sauvegarde pendant plusieurs jours, suivie d’un plantage brutal qui a mis complètement hors ligne le forum. :-\

(@riking a même déclaré : « les sauvegardes sont une source fréquente de ce type de défaillance. » Donc les instances Discourse tombent régulièrement en panne à cause d’échecs de sauvegarde sans aucun avertissement d’un problème potentiel ?)

Autrement dit, très simplement, d’un point de vue global : il semble y avoir un défaut de conception si une fonctionnalité de base du logiciel (les sauvegardes automatiques) peut mettre l’ensemble du système hors ligne. Surtout quand il s’agit d’une fonctionnalité qui utilise simplement de l’espace disque pour préparer la sauvegarde, sans même la stocker sur le même disque.

1 « J'aime »
18

Non, il voulait dire que la prise de sauvegardes via n’importe quel logiciel sur n’importe quel serveur peut potentiellement remplir le disque et causer des problèmes.

3 « J'aime »
19

Bien sûr, mais c’est pourquoi vous devez placer un CDN devant S3. Ne servez pas les images directement depuis S3, cela va coûter un prix fou :scream:. Vous pouvez facilement placer CloudFront ou même CloudFlare devant S3. L’offre gratuite de CloudFlare permet de le faire.

Et les stocker localement est également une très mauvaise nouvelle : vous allez devoir mettre à l’échelle votre VPS inutilement. Les SSD locaux seront beaucoup plus chers.

7 « J'aime »
20

Ah, d’accord, j’ai compris.

Alors, comment puis-je savoir combien d’espace disque pourrait être nécessaire pour que Discourse prépare une sauvegarde ? Le logiciel ne me l’indique pas, alors peut-être que demain ce sera 500 Go et que cela remettra mon serveur Digital Ocean hors ligne à nouveau. :man_shrugging:t2: Au moins, si je peux faire quelques calculs approximatifs, je pourrai essayer de garder un œil dessus.

Oh wow, c’est une excellente idée. Je n’y avais jamais pensé. Donc, j’appliquerais le CDN à mon bucket Amazon, puis je dirais à Discourse d’utiliser S3 pour tous les assets ? (Comme avant ? lol)

3 « J'aime »