No es mi problema, pero ¿significa esto que no hay nada más?
1 me gusta
Quizás no intencionalmente, pero podría valer la pena auditar el contenido del host en busca de procesos de minería de criptomonedas, etc.
3 Me gusta
Paso 1: solucionar el problema de rendimiento ya identificado del uso del controlador vfs
7 Me gusta
Con respecto a este cambio a (idealmente) overlay2, tendré que borrar mi instalación actual y reinstalar todo. Esto se debe a que el host en el que me encuentro actualmente solo admite fuse-overlayfs o vfs, que no son ninguna de las dos opciones recomendadas.
Sin embargo, pronto habilitarán KVMs que admiten overlay2.
Por lo tanto, mi intención sería usar eso, en lugar del fuse-overlayfs que tampoco se recomienda.
Ahora, en la propia aplicación Discourse, puedo hacer copias de seguridad. ¿Qué respaldan precisamente?
¿Perdería algo del foro actual de Discourse (es decir, mensajes, chats, configuraciones, usuarios, imágenes subidas, etc.) si hiciera una copia de seguridad, reinstalara un Discourse nuevo en un servidor nuevo y luego, después de la configuración inicial de Discourse, lo sobrescribiera con la copia de seguridad?
¿Funcionaría eso?
Sí, eso funcionaría.
Lo único que no mencionaste es asegurarte de tener los mismos plugins en el nuevo Discourse que en el actual. Si reutilizas tu app.yml, también estarías bien.
3 Me gusta
De acuerdo, gracias por señalarlo, apuesto a que me habría topado con él.
Ok, entonces…
- Hacer una copia de seguridad en el área de administración de Discourse
- Solo por seguridad, por supuesto, hacer una copia de seguridad del servidor
- Hacer una copia del archivo yaml
- Volcar el servidor
- Configurar un nuevo servidor con tecnología compatible
- Instalar Docker con el controlador de almacenamiento adecuado
- Reconstruir una instancia de Discourse completamente nueva usando el archivo yaml respaldado
- Restaurar Discourse desde la copia de seguridad
Un poco sorprendido de que la copia de seguridad sea de solo 19,2 MB.
Ya tenemos varias imágenes, etc., cargadas… pero supongo que todo lo que puedo hacer es intentarlo.
Lo intentaré este fin de semana y te informaré si el cambio en el controlador de almacenamiento funcionó.
1 me gusta
Comprueba que esto esté configurado:
1 me gusta
Tenga en cuenta que esa configuración específica solo se aplica a las copias de seguridad programadas, no a las manuales. Con las copias de seguridad manuales, siempre tiene una opción explícita.
Otra configuración para habilitar es incluir miniaturas en las copias de seguridad
@smileBeda Pospondría el #4 hasta que todo funcione correctamente.
3 Me gusta
De hecho está marcado, pero Incluir miniaturas generadas en las copias de seguridad. Desactivar esto hará que las copias de seguridad sean más pequeñas, pero requiere un nuevo horneado de todas las publicaciones después de una restauración. no lo estaba.
@RGJ … cierto, buena idea, tomará más pasos ya que tendré que crear un servidor bajo una nueva entidad, pero es menor en comparación con el riesgo.
Dejaré que la copia de seguridad automatizada se active para obtener todos los datos en ella, ya que entiendo que la manual no incluiría las imágenes, etc.
Gracias…
Esa es una suposición incorrecta.
Al crear una copia de seguridad manualmente, obtienes la opción en una ventana emergente de si deseas hacer una copia de seguridad solo de la base de datos o incluir las cargas.
Al crear copias de seguridad programadas, la configuración copia de seguridad con cargas decide eso.
4 Me gusta
Ok, entendí mal tu anterior Tenga en cuenta que esa configuración específica solo se aplica a las copias de seguridad programadas, no a las manuales.
Gracias…
2 Me gusta
Hola, reutilizo este tema ya que todavía está abierto y tenemos el mismo problema después de migrar a un nuevo servidor virtual. Al igual que todos los demás dicen, nunca me tomó más de 20 minutos reconstruir nuestro Discourse, pero en este nuevo servidor lleva horas, y tiene el doble de recursos que el anterior. 
He revisado otros temas sobre actualizaciones de una hora en Meta, pero no puedo descifrar cuál es el problema con el nuestro:
Servidor: 4 GB de RAM, 2 CPU, disco de 50 GB.
Swap:
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker:
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Me parece normal, pero quizás me estoy perdiendo algo. ¿Dónde más podemos buscar?
¿Quizás un vecino ruidoso está haciendo que tu nueva VM sea más lenta que la anterior porque está usando toda la CPU que tú no obtienes?
1 me gusta
Sí, gracias, es tranquilizador que un administrador experimentado como tú no vea nada obvio en la información anterior. Y sí, estamos empezando a mirar el servidor físico y nuestro vecindario virtual. Al menos el foro funciona sin problemas perceptibles por los usuarios. Solo estamos teniendo este grave problema de rendimiento con las reconstrucciones. Ayer tardamos 4 horas en reconstruir. 
1 me gusta
Si tuviera este problema, tendría dos o tres ventanas de terminal abiertas. Una para ejecutar la reconstrucción, otra para tomar notas sobre el tiempo transcurrido y para anotar dónde ocurren las largas demoras entre las actualizaciones del registro, y la última para mantener un registro de la actividad de la máquina: probablemente ejecutando vmstat 5
Cuando llegues a un punto en el que el registro no se actualiza durante un tiempo sospechosamente largo, toma nota de la actividad informada por vmstat.
Publica aquí extractos adecuados del registro con tus notas y la salida correspondiente de vmstat.
Parece muy probable que sean partes específicas de la reconstrucción las que llevan tiempo: lo que hay que hacer es averiguar qué partes y ver qué está haciendo la máquina en esos momentos.
Probablemente también tomaría una instantánea de la actividad de la máquina con ps auxf durante las pausas.
4 Me gusta
Gracias, es muy buen consejo. La próxima vez que necesitemos reconstruir, lo haremos de esta manera.
2 Me gusta