2026.4.1 に更新後、スレッドの割り当てに失敗

[RBoy]

2026.4.1(e404d9aabc)に更新した直後、ログに以下のエラーが表示されています：

メッセージ（151769 件のコピーが報告されました）

ジョブ例外：スレッドを割り当てできません

バックトレース

/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'

ホスト名	ip-172-x-x-x-app
プロセス ID	286281
アプリケーションバージョン	3532c825824ee1259628545c7bd5311ecb918009
現在のデータベース	default
現在のホスト名	discussion.mcebuddy2x.com
メッセージ	スケジューリングマネージャーのティック処理中
時刻	午後 7:57

[sam (Sam Saffron)]

これはおそらくサーバーのリソース制約によるものです。現在のRAMの状況はどうなっていますか？使用中のドロプレットに関する詳細はありますか？

[RBoy]

Discourse のインスタンス 1 つのみを実行する専用マシンです。RAM やスワップの不足は見当たりません。

[sam (Sam Saffron)]

Docker、OS、Discourse イメージの最終更新はいつですか？これら 3 つはすべて最新バージョンで動作していますか？

[RBoy]

先週、CLI/docker のアップグレードと OS アップデートを実行しました。再度試してみます。

数週間前のベータリリースでは正常に動作していました。ブラウザ経由のアップグレードオプションでベータ版からリリース版に更新してから、この問題が発生しました。

[Ethsim2 (Ethan)]

./launcher enter appを実行し、

ulimit -u

これは、許可されているユーザープロセス/スレッドの最大数を表示します。

ulimit -a

これは、すべてのリソース制限を表示します。

cat /sys/fs/cgroup/pids.max

これは、コンテナまたはシステム cgroup で許可されているプロセス（PID）の最大数を確認します。

---

次に、logout を使用してホストに戻ってください。

systemctl show docker | grep TasksMax

これは、systemd が Docker サービスに対してタスク/スレッド制限を課しているかどうかを確認します。

systemctl show containerd | grep TasksMax

これは、Docker 自体ではなく containerd サービスに対して同様のチェックを行います。

docker inspect app | grep -i pid

これは、Discourse コンテナのプロセス/PID 制限と設定を確認します。grep -i pid は、「pid」を含むものを大文字小文字を区別せずにフィルタリングします。

エラーが引き続き発生する場合は、これらのコマンドの出力をここに貼り付けていただけますと幸いです。

[Lilly (Lillian)]

@Ethsim2

「.\launcher enter app」と入力して

./launcher enter app

[RBoy]

ここが情報です。ほぼすべてが無制限です

[RBoy]

CLI から再ビルドを行ったところ、問題が解決したようです。引き続き監視します。先週、ブラウザをベータ版から安定版に更新したことがこの問題の引き金となったようです。

ブラウザのアップグレードに制限を設けるべきでしょうか？ブラウザのアップグレード時に潜在的な問題を検知して警告を出す、あるいはアップグレードを阻止する機能はありますか？

[Ethsim2 (Ethan)]

再構築によりコンテナの cgroup 配置がリセットされた可能性があり、これが安定性が回復した理由を説明します。

元の「can’t alloc thread」エラーや、ulimits、TasksMax、Docker PIDs などが無制限であるという事実を考慮すると、残る疑念は PID cgroup の圧力です。

通常の負荷時に以下を確認してください。

cat /sys/fs/cgroup/pids.current

^[1]

cat /sys/fs/cgroup/pids.max

^[2]

pids.current が最大値である約 2285 に対して約 2000 以上で推移している場合、スケジューラーや Redis の再接続バースト中にコンテナが cgroup の PID 上限に達していたことが確認されます。

これにより、アップグレード後（スレッドの churn 増加）にのみ問題が発生した理由、および再構築が一時的に問題を解消した理由も説明できます。

---

1. コンテナ/cgroup 内で現在実行されているプロセス数（PID/スレッド数） ↩︎

2. その cgroup（コンテナ）で許可されるプロセス数（PID/スレッド数）の最大値 ↩︎