Tu conexión de red Redis está funcionando muy mal

[markersocial]

Constantemente obtengo esto en los registros, con valores entre ~100k y ~1.35m, pero las lecturas cercanas a 100k parecen ser bastante comunes:

Tu conexión de red de Redis tiene un rendimiento extremadamente pobre. Las últimas lecturas de RTT fueron [97069, 103986, 98459, 100762, 381617], idealmente deberían ser < 1000. Asegúrate de que Redis se esté ejecutando en la misma AZ o centro de datos que Sidekiq. Si estos valores están cerca de 100 000, significa que tu proceso Sidekiq puede estar saturado de CPU; reduce tu concurrencia y/o consulta https://github.com/mperham/sidekiq/discussions/5039

¿Esto indica que quizás Redis no puede usar suficiente CPU? Sin embargo, parece haber mucho margen para la CPU y la RAM en el propio servidor.

También:
Sidekiq está consumiendo demasiada memoria (usando: 3570.19M) para 'www.example.com', reiniciando

Esto está usando la aplicación todo en uno app.yml con Discourse estable 3.3.2.

Desde el app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

También agregué esta configuración al host:

@mcdanlj

Configuración del Kernel

Redis (uno de los componentes clave sobre los que se basa Discourse) recomienda encarecidamente deshabilitar las páginas grandes transparentes cuando se utiliza persistencia en disco (lo que hace Discourse), y yo también permito la sobreasignación de memoria.

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

Información del panel de Sidekiq:

Parece que Redis no puede superar el uso de memoria de 1024M.

Si alguien tiene alguna idea, ¡lo agradecería!

[markersocial]

Para dar seguimiento a esto, tengo el mismo problema con Jobs::PostAlert:

PostAlerter job hangs/OOMs as of late

Ever since FEATURE: new watched_precedence_over_muted setting (#22252) · discourse/discourse@9cf981f · GitHub (presumably!) we’re having Sidekiq queues fill up/OOM with stuck PostAlert jobs: [image] [image] Given this commit has already had a similar regression (FIX: error when CategoryList tried to find relevant topics by lis2 · Pull Request #22339 · discourse/discourse · GitHub) it’s fairly suspect - we’ll try downgrading to a commit before the aforementioned one now though and will repor…

Con esos trabajos a menudo llegando a 15 minutos cuando se usan 4 sidekiqs con 5 hilos (predeterminado) con las pruebas actuales. Parece que la velocidad de trabajos por segundo para Sidekiq depende en gran medida de cuántos de esos trabajos se ejecutan simultáneamente y cuántos hilos están libres para los otros trabajos.

Aumentar los Sidekiqs a 6 o más (5 hilos) aumentará la velocidad de limpieza de la cola, pero postgres fallará con bastante regularidad (supongo que debido a que se ejecutan demasiados trabajos Jobs::PostAlert simultáneamente).

Esto está en Stable 3.3.2. Los cambios y correcciones del hilo enlazado ya parecen estar implementados en 3.3.2, si no me equivoco.

[supermathie (Michael Brown)]

@markersocial

postgres fallará con bastante regularidad

Postgres nunca debería fallar y, en general, indica un error de postgres o algún tipo de problema mayor.

¿Tienes registros?

[Ed_S]

¿Has reiniciado el servidor desde que hiciste esos cambios en la configuración del kernel?

@Ed_S

mi lista de diagnósticos instantáneos estándar:

cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc

Quizás

lscpu

también sería útil.

[Falco]

@markersocial

Del archivo app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Nunca deberías aumentar UNICORN_SIDEKIQS tanto, solo aumentar los workers pero

@markersocial

postgres se bloqueará con bastante regularidad

Esto nunca debería suceder.

Las posibilidades son:

1. Tienes restricciones de recursos porque o
   a) Tu sitio ha superado los recursos del servidor
   b) Estás mal asignando recursos
2. Hay un error en alguna parte de la pila

Yo empezaría haciendo

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

lo que debería liberar algo de RAM de tu servidor.

Para más información, necesitarás ejecutar los trabajos que causan el problema en una consola de PostgreSQL e informar cuál es el cuello de botella.