La connessione di rete Redis sta funzionando estremamente male

[markersocial]

Ottengo costantemente questo nei log, con valori compresi tra circa 100k e circa 1,35 milioni, ma le letture vicine a 100k sembrano essere abbastanza comuni:

La tua connessione di rete Redis sta funzionando in modo estremamente scadente. Le ultime letture RTT sono state [97069, 103986, 98459, 100762, 381617], idealmente dovrebbero essere < 1000. Assicurati che Redis sia in esecuzione nella stessa AZ o data center di Sidekiq. Se questi valori sono vicini a 100.000, significa che il tuo processo Sidekiq potrebbe essere saturato di CPU; riduci la concorrenza e/o consulta https://github.com/mperham/sidekiq/discussions/5039

Questo indica che forse Redis non è in grado di utilizzare abbastanza CPU? Sembra esserci molto spazio per la CPU e la RAM sul server stesso.

Inoltre:
Sidekiq sta consumando troppa memoria (utilizzando: 3570.19M) per 'www.example.com', riavvio

Questo utilizza l’app.yml all-in-one con Discourse stable 3.3.2.

Da app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Ho aggiunto anche questa configurazione all’host:

@mcdanlj

Configurazione del kernel

Redis (uno dei componenti chiave su cui si basa Discourse) raccomanda vivamente di disabilitare le huge page trasparenti quando si utilizza la persistenza su disco (cosa che Discourse fa), e consento anche l’overcommit della 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

Informazioni sulla dashboard di Sidekiq:

Sembra proprio che Redis non sia in grado di superare l’utilizzo di memoria di 1024M.

Se qualcuno ha qualche idea, la apprezzerei!

[markersocial]

Per dare seguito a questo, sto riscontrando lo stesso 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 questi job che spesso arrivano a 15 minuti quando si utilizzano 4 sidekiq con 5 (predefiniti) thread con i test attuali. Sembra che la velocità dei job al secondo per Sidekiq dipenda principalmente da quanti di questi job vengono eseguiti contemporaneamente e quanti thread sono liberi per gli altri job.

Aumentare i Sidekiq a 6 o più (5 thread) aumenterà la velocità di svuotamento della coda, ma postgres si bloccherà abbastanza regolarmente (ipotizzo a causa di troppi job Jobs::PostAlert eseguiti contemporaneamente).

Questo è su Stable 3.3.2. Le modifiche e correzioni dal thread collegato sembrano essere già state implementate in 3.3.2, se non erro.

[supermathie (Michael Brown)]

@markersocial

postgres si bloccherà abbastanza regolarmente

Postgres non dovrebbe mai bloccarsi e in genere indica un bug di postgres o una sorta di problema più grande.

Hai dei log?

[Ed_S]

Hai riavviato il server da quando hai apportato quelle modifiche alla configurazione del kernel?

@Ed_S

il mio elenco di diagnostica istantanea standard:

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

Forse

lscpu

sarebbe anche utile

[Falco]

@markersocial

Dal file app.yml:

UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5

Non dovresti mai aumentare UNICORN_SIDEKIQS così tanto, aumentando solo i worker ma

@markersocial

postgres andrà in crash abbastanza regolarmente

Questo non dovrebbe mai succedere.

Le possibilità sono:

1. Sei limitato nelle risorse perché o
   a) Il tuo sito ha superato le risorse del server
   b) Stai allocando male le risorse
2. C’è un bug da qualche parte nello stack

Inizierei impostando

UNICORN_SIDEKIQS: 1
DISCOURSE_SIDEKIQ_WORKERS: 20

che dovrebbe liberare un po’ di RAM dal tuo server.

Per ulteriori informazioni dovrai eseguire i job in questione in una console PostgreSQL e segnalare qual è il collo di bottiglia.