Alojo todos mis archivos de carga en un NAS de almacenamiento (glusterfs).
Recientemente descubrí que hay un tráfico de red enorme y constante en el NAS. Y lo rastreé hasta Discourse solicitando imágenes optimizadas. ¿Hay alguna tarea que busque constantemente estas imágenes? ¿Por qué? ¿Y cómo puedo desactivarla?
btw la limpieza de la configuración del sitio de cargas está deshabilitada en mi foro.
Posiblemente el relleno @david añadió para buscar el color primario de la imagen.
Eventualmente terminará y volverá a un estado estable.
Necesitamos revisar todas las imágenes para el relleno, puede que pueda solucionarlo forzando el color de todas las imágenes a blanco o algo similar.
Por lo que veo,
Está funcionando con 25 imágenes cada 15 minutos. ¿sí? esto debería ser muy insignificante. Estoy viendo miles de archivos siendo buscados cada minuto.
Y también mirando el ancho de banda de hace 6 meses, veo el mismo comportamiento. Así que creo que debería ser algo más.
Sin embargo, estoy bastante seguro de que lo está haciendo un trabajo de discourse o algo similar, porque cuando detengo la aplicación de discourse, el ancho de banda desaparece. Sin embargo, cuando solo detengo la aplicación nginx de discourse, el ancho de banda permanece.
Echa un vistazo en /sidekiq, debería decirte qué trabajos se están ejecutando, asegúrate de hacer clic en todas las pestañas.
No hay ningún trabajo en ejecución. 
. ¿Hay algún otro trabajo que no se liste aquí?
¿O tal vez hay algo en el contenedor que intenta indexar archivos?
Toda nuestra lógica de fondo se ejecuta en trabajos de Sidekiq. Si no se está ejecutando ningún trabajo y aún tiene un alto I/O de disco, ¿podrían ser los usuarios que visitan su sitio web y las imágenes que son servidas por nginx?
¿Tiene una CDN de caché delante de los activos estáticos?
Probé esto anteriormente.
Así que no es porque los usuarios visiten el sitio web. Si fuera así, cuando detuve nginx, el tráfico debería desaparecer.
Necesitarás usar las herramientas de inspección de Linux para ver exactamente qué PIDs y llamadas al sistema se están realizando entonces.
@Falco @sam Creo que encontré la causa raíz.
Primero reinicié la aplicación de discurso para que el tráfico constante desapareciera. Luego fui al panel de administración y fui a la sección de informes masivos. Ha pasado mucho tiempo desde que los informes no se muestran correctamente aquí:
Inmediatamente después de que los informes fallan, veo el salto en el ancho de banda de la red. Y veo este error en los registros de errores:
'hijack admin/reports bulk ' todavía se está ejecutando después de 90 segundos en la base de datos predeterminada, ¡este proceso puede necesitar ser reiniciado!
¿Qué está saliendo mal aquí?
¿Está la base de datos en el mismo almacenamiento NAS?
No, la base de datos está en el disco SSD físico.
Solo la carpeta de carga está en el NAS.
Entonces no hay correlación entre ellos. Volviendo a
De hecho, creo que tal vez sí hay una correlación. En mi entorno de prueba aquí calcula el espacio utilizado.
Creo que calcular el espacio utilizado en una carpeta NAS con muchos archivos consumiría mucho tiempo y sería la causa principal de un alto ancho de banda.
¿Tengo razón?
¿Ejecutar
df -Pk
df -P
du -s
toma una cantidad significativa de tiempo en el recurso compartido de red?
estos dos fueron instantáneos
df -Pk
df -P
Sin embargo, du -s resultó en un comportamiento similar al que informé anteriormente.
Y se estuvo ejecutando durante unos 5 minutos y no terminó, por lo que tuve que terminarlo manualmente.
Ya veo. El resultado de ese informe está en caché, pero supongo que nunca termina y no se puede almacenar en caché porque su recurso compartido de red es demasiado lento.
¿Hay algo que podamos hacer para prevenir esto? Por ejemplo, tratarlo como subidas de s3 para no calcular el tamaño del disco.
