Impossible d'allouer un thread après la mise à jour vers 2026.4.1

Contribuer Bug
1

Je constate ces erreurs dans les journaux après la mise à jour vers 2026.4.1 (e404d9aabc) récemment :

Message (151769 copies signalées)

Exception de tâche : impossible d'allouer un thread

Pile d'appels

/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'Thread.new'
/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'bloc dans Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Array#map'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:661:in 'Socket.tcp'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:122:in 'RedisClient::RubyConnection#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:48:in 'RedisClient::RubyConnection#initialize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'Class#new'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'bloc dans RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/middlewares.rb:12:in 'RedisClient::BasicMiddleware#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:848:in 'RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:824:in 'RedisClient#raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:779:in 'RedisClient#ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:372:in 'RedisClient#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/client.rb:90:in 'Redis::Client#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/rack-mini-profiler-4.0.1/lib/mini_profiler/profiling_methods.rb:90:in 'bloc dans Redis::Client#profile_method'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:152:in 'bloc dans Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Monitor#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/commands/keys.rb:256:in 'Redis::Commands::Keys#del'
/var/www/discourse/lib/discourse_redis.rb:168:in 'bloc dans DiscourseRedis#del'
/var/www/discourse/lib/discourse_redis.rb:29:in 'DiscourseRedis.ignore_readonly'
/var/www/discourse/lib/discourse_redis.rb:165:in 'DiscourseRedis#del'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:48:in 'MiniScheduler::DistributedMutex#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:15:in 'MiniScheduler::DistributedMutex.synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:365:in 'MiniScheduler::Manager#lock'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:316:in 'MiniScheduler::Manager#tick'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:74:in 'bloc (2 niveaux) dans MiniScheduler.start'

hostname	ip-172-x-x-x-app
process_id	286281
application_version	3532c825824ee1259628545c7bd5311ecb918009
current_db	default
current_hostname	discussion.mcebuddy2x.com
message	Lors du tic du gestionnaire de planification
time	19 h 57
2

Cela serait probablement dû à une limitation des ressources de votre serveur. Que fait la RAM en ce moment ? Avez-vous des détails sur le droplet que vous exécutez ?

3

C’est une machine dédiée exécutant une seule instance de Discourse. Il ne semble pas y avoir de pénurie de RAM ou d’espace d’échange.

4

Quand avez-vous dernièrement mis à niveau Docker, le système d’exploitation et l’image Discourse ? Est-ce que tout cela fonctionne avec la dernière version sur les trois ?

5

Dernière exécution d’une mise à niveau CLI/docker et d’une mise à jour du système d’exploitation la semaine dernière. Je vais réessayer.

IMG2572
IMG25722233×899 382 KB

IMG2571
IMG25711170×537 68 KB

Tout fonctionnait correctement dans la version bêta de il y a quelques semaines. Ce problème est apparu après la mise à jour de la version bêta vers la version stable via l’option de mise à jour dans le navigateur.

6

Pourriez-vous exécuter ./launcher enter app et

ulimit -u

cela affiche le nombre maximal de processus/threads utilisateur autorisés.

ulimit -a

cela affiche toutes les limites de ressources.

cat /sys/fs/cgroup/pids.max

cela vérifie le nombre maximal de processus (PIDs) autorisés pour le cgroup du conteneur ou du système.

Ensuite, utilisez logout pour revenir à l’hôte ;

systemctl show docker | grep TasksMax

cela vérifie si systemd a imposé une limite de tâches/threads au service Docker.

systemctl show containerd | grep TasksMax

cela effectue le même type de vérification, mais pour le service containerd plutôt que pour Docker directement.

docker inspect app | grep -i pid

cela vérifie les limites et paramètres de processus/PID de votre conteneur Discourse. Le grep -i pid : filtre tout ce qui contient « pid » (sans distinction de casse).

Si vous continuez à rencontrer des erreurs, pourriez-vous s’il vous plaît copier-coller ici la sortie de ces commandes, cela serait très utile.

7

./launcher enter app

1 « J'aime »
8

Voici les informations, pratiquement tout est illimité

IMG2573
IMG25731170×814 167 KB

IMG2574
IMG25741170×180 32.1 KB

IMG2575
IMG2575671×103 13.4 KB

IMG2576
IMG2576662×102 14.6 KB

IMG2577
IMG25771170×180 22.2 KB

9

Une reconstruction depuis l’interface de ligne de commande semble avoir résolu le problème. Je vais continuer à surveiller la situation. Il semble que la mise à jour du navigateur, passant de la version bêta à la version stable au cours de la dernière semaine, ait déclenché ce souci.

Devrait-il y avoir des limites imposées à la mise à niveau du navigateur ? La mise à niveau du navigateur peut-elle détecter d’éventuels problèmes, les signaler ou empêcher le déclenchement de la mise à niveau ?

1 « J'aime »
10

La reconstruction a probablement réinitialisé le placement du cgroup du conteneur, ce qui expliquerait pourquoi il est à nouveau stable.

Compte tenu des erreurs originales « can’t alloc thread » et du fait que tout le reste (ulimits, TasksMax, PIDs Docker) est illimité, le principal suspect restant est la pression du cgroup PID.

Pourriez-vous vérifier lors d’une charge normale :

cat /sys/fs/cgroup/pids.current

[1]

cat /sys/fs/cgroup/pids.max

[2]

Si pids.current approche de ~2000+ par rapport à un maximum de ~2285, cela confirmerait que le conteneur atteignait le plafond PID du cgroup lors des rafales de reconnexion du planificateur / Redis.

Cela expliquerait également pourquoi le problème n’est apparu qu’après la mise à niveau (changement accru de threads) et pourquoi la reconstruction l’a temporairement résolu.

  1. Nombre de processus (PIDs/fils d’exécution) actuellement en cours d’exécution dans le conteneur/cgroup ↩︎

  2. Nombre maximal de processus (PIDs/fils d’exécution) autorisés dans ce cgroup (votre conteneur) ↩︎

1 « J'aime »