hostname ip-172-x-x-x-app
process_id 286281
application_version 3532c825824ee1259628545c7bd5311ecb918009
current_db default
current_hostname discussion.mcebuddy2x.com
message Durante l'aggiornamento del gestore della pianificazione
time 7:57 pm
Questo potrebbe essere probabilmente un vincolo di risorse sul tuo server. Che cosa sta facendo la RAM in questo momento? Hai qualche dettaglio sul droplet che stai eseguendo?
Funzionava correttamente nella versione beta di alcune settimane fa. Il problema è iniziato dopo l’aggiornamento dalla versione beta alla versione stabile tramite l’opzione di aggiornamento dal browser.
questo mostra il numero massimo di processi/thread utente consentiti
ulimit -a
questo mostra tutti i limiti delle risorse
cat /sys/fs/cgroup/pids.max
questo verifica il numero massimo di processi (PID) consentiti per il cgroup del container o del sistema.
ora usa logout per tornare all’host;
systemctl show docker | grep TasksMax
questo verifica se systemd ha imposto un limite di attività/thread al servizio Docker.
systemctl show containerd | grep TasksMax
questo esegue lo stesso tipo di verifica, ma per il servizio containerd invece che direttamente per Docker.
docker inspect app | grep -i pid
questo verifica i limiti e le impostazioni dei processi/PID del tuo container Discourse. Il comando grep -i pid: filtra tutto ciò che contiene „pid“ (senza distinzione tra maiuscole e minuscole).
Se continui a ricevere errori, potresti incollare qui l’output di questi comandi? Sarebbe molto utile.
Un rebuild da CLI sembra aver risolto il problema. Continuerò a monitorarlo. Sembra che un aggiornamento del browser dalla versione beta a quella stabile nella scorsa settimana abbia innescato la situazione.
Dovrebbero esserci dei limiti per l’aggiornamento del browser? L’aggiornamento può rilevare potenziali problemi, segnalarli o impedire che venga attivato?
Il ripristino ha probabilmente resettato l’assegnazione del cgroup del container, il che spiegherebbe perché è di nuovo stabile.
Considerati gli errori originali “can’t alloc thread” e il fatto che tutto il resto (ulimits, TasksMax, PIDs di Docker) sia illimitato, il sospetto rimanente è la pressione del cgroup dei PID.
Se pids.current si avvicina a ~2000+ rispetto a un massimo di ~2285, ciò confermerebbe che il container stava raggiungendo il limite dei PID del cgroup durante i picchi di riconnessione dello scheduler/Redis.
Ciò spiegherebbe anche perché il problema si è manifestato solo dopo l’aggiornamento (maggiore turnover dei thread) e perché il ripristino l’ha temporaneamente risolto.
Quanti processi (PIDs/thread) sono attualmente in esecuzione all’interno del container/cgroup ↩︎
Il numero massimo di processi (PIDs/thread) consentiti in quel cgroup (il tuo container) ↩︎
Grazie: questo esclude una pressione sui PID correnti dopo il rebuild.
Dato che pids.current è solo 227 contro 4194304, il container non è assolutamente vicino al limite PID del cgroup in questo momento.
La parte interessante è che il precedente pids.max sembrava essere 2285, mentre dopo il rebuild è ora 4194304. Quindi il rebuild potrebbe aver resettato il limite del cgroup (ovvero, ha rinnovato l’app-container), il che spiega perché non ci sono prove di un problema attivo di esaurimento dei PID al momento.
Se l’errore si ripresenta, sarebbe utile copiare e incollare questi comandi nel momento in cui fallisce:
cat /sys/fs/cgroup/pids.current
cat /sys/fs/cgroup/pids.max
ps -eLf | wc -l
Questo mostrerebbe se il fallimento è dovuto alla pressione sui PID, o se dovremmo cercare altrove
