No quiero echar agua en esta fiesta, pero en realidad, al leer los mensajes, no hay una confirmación sólida de que el proceso de respaldo de Discourse sea el causante del problema.
¿Por qué no confirmar al 100 % que este problema es causado por el proceso de respaldo diario? Hay más de un proceso ejecutándose en los archivos crontab diarios en los hosts.
¿@pnoeric ejecutó un du en el sistema de archivos /var/discourse (fuera del contenedor)?
En sus notas, @pnoeric escribe:
root@x-app:/var/www/discourse# du -h -d 1
Pero esto omitió por completo el directorio compartido de Discourse, que incluye todas las copias de seguridad y las subidas, ¡y también omitió todos los archivos de Docker (y las imágenes) en el host (que pueden crecer mucho si las imágenes no se eliminan periódicamente)!
El lugar correcto para ejecutar esta verificación es fuera del contenedor (¡no dentro del contenedor!):
Por ejemplo (fuera del contenedor):
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
Puede ver que, en este host, el directorio shared tiene 62G.
Y también desde /var del sistema de archivos (fuera del contenedor):
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
No estoy tratando de echar agua en esta fiesta, pero antes de salir a proponer una serie de “soluciones” para Discourse, sería muy bueno confirmar al 100 % que el cron de respaldo de Discourse es realmente el problema.
No hemos tenido ningún problema con el proceso actual de respaldo de Discourse y, además, gestionar el sistema de archivos en el host NO es una tarea de Discourse per se.
Aquí:
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 522668 0% /var/lib/docker/containers/63c52bc571b5f0d2544417da10efc37d3957e7a38f44bc8325145e795ee29559/mounts/shm
Veamos los archivos de Docker:
# cd /var/lib
# du -sh docker
30G docker
Y nuestras imágenes de Docker se eliminan y limpian regularmente.
@bartv sugirió correctamente comenzar aquí:
Empezaría por averiguar qué directorio está creciendo descontroladamente. Mi enfoque estándar es entrar en /var/discourse y luego ejecutar du -h -d 1. Tomar el directorio más grande, entrar en él y repetir hasta encontrar el sospechoso. Una vez que lo tengas, eso podría darte una pista sobre lo que está pasando.
Ese es un buen comienzo, pero puede haber muchos otros lugares en el sistema de archivos del host que puedan llenar el sistema de archivos, incluidos Docker, archivos de núcleo, etc.
Un gráfico que muestra un pico en el porcentaje una vez al día no es suficiente para afirmar, con autoridad, que el proceso cron de respaldo de Discourse es la causa raíz. Podría serlo, pero también podría no serlo, ¡basándonos en la evidencia hasta ahora!
Así que espero que mi régimen de copias de seguridad sea altamente inusual.
Al menos, si puedo hacer unos cálculos rápidos, podré mantener el control.