Não é possível alocar thread após atualizar para 2026.4.1

Contribuir Bug
1

Estou vendo esses erros nos logs após atualizar para a versão 2026.4.1 (e404d9aabc) recentemente:

Mensagem (151769 cópias reportadas)

Exceção no Job: não foi possível alocar thread

Backtrace

/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'Thread.new'
/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'block in 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 'block in 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 'block in Redis::Client#profile_method'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:152:in 'block in 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 'block in 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 'block (2 levels) in MiniScheduler.start'

hostname	ip-172-x-x-x-app
process_id	286281
application_version	3532c825824ee1259628545c7bd5311ecb918009
current_db	default
current_hostname	discussion.mcebuddy2x.com
message	Ao executar o tick do gerenciador de agendamento
time	19:57
2

Isso provavelmente seria uma limitação de recursos no seu servidor. O que a RAM está fazendo no momento? Você tem algum detalhe sobre o droplet que está executando?

3

É uma máquina dedicada executando apenas uma instância do Discourse. Não parece haver escassez de RAM/swap.

4

Quando você atualizou pela última vez o Docker, o sistema operacional e a imagem do Discourse? Isso está rodando a versão mais recente em todos os três?

5

A última execução de uma atualização do CLI/docker e do sistema operacional foi na semana passada. Vou tentar novamente.

IMG2572
IMG25722233×899 382 KB

IMG2571
IMG25711170×537 68 KB

Estava funcionando bem na versão beta de algumas semanas atrás. Isso começou após a atualização da versão beta para a release, usando a opção de atualização pelo navegador.

6

Você poderia executar ./launcher enter app e

ulimit -u

isso mostra o número máximo de processos/fios de usuário permitidos.

ulimit -a

isso mostra todos os limites de recursos.

cat /sys/fs/cgroup/pids.max

Isso verifica o número máximo de processos (PIDs) permitidos para o cgroup do contêiner ou do sistema.

agora use logout para retornar ao host;

systemctl show docker | grep TasksMax

isso verifica se o systemd impôs um limite de tarefas/fios no serviço Docker.

systemctl show containerd | grep TasksMax

isso faz o mesmo tipo de verificação, mas para o serviço containerd em vez do Docker diretamente.

docker inspect app | grep -i pid

isso verifica os limites e configurações de processo/PID do seu contêiner Discourse. O grep -i pid: filtra qualquer coisa que contenha „pid“ (sem distinção de maiúsculas/minúsculas).

Se você continuar recebendo erros, por favor, cole aqui a saída desses comandos; isso seria muito útil.

7

./launcher enter app

1 curtida
8

Aqui estão as informações, praticamente tudo é ilimitado

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

Fazer uma reconstrução pela CLI parece ter resolvido o problema. Vou ficar de olho. Algo relacionado à atualização do navegador da versão beta para a estável na última semana desencadeou isso.

Deveria haver limites para a atualização do navegador? A atualização do navegador pode detectar problemas potenciais e sinalizá-los ou impedir que a atualização seja acionada?

1 curtida
10

A reconstrução provavelmente redefiniu a alocação do cgroup do container, o que explicaria por que ele está estável novamente.

Considerando os erros originais de “can’t alloc thread” e o fato de que tudo o mais (ulimits, TasksMax, PIDs do Docker) está ilimitado, o suspeito restante é a pressão do cgroup de PIDs.

Você poderia verificar, durante a carga normal:

cat /sys/fs/cgroup/pids.current

[1]

cat /sys/fs/cgroup/pids.max

[2]

Se pids.current estiver se aproximando de ~2000+ contra um máximo de ~2285, isso confirmaria que o container estava atingindo o limite de PIDs do cgroup durante os surtos de redefinição do agendador / reconexão do Redis.

Isso também explicaria por que o problema só apareceu após a atualização (maior troca de threads) e por que a reconstrução o limpou temporariamente.

  1. Quantos processos (PIDs/threads) estão atualmente em execução dentro do container/cgroup ↩︎

  2. o número máximo de processos (PIDs/threads) permitidos naquele cgroup (seu container) ↩︎

1 curtida