# 更新到 2026.4.1 后无法分配线程
**URL:** https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784
**Category:** Bug
**Created:** [2026年五月26日 00:02 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784 "2026-05-26T00:02:25Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [2026年五月26日 00:02 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/1 "2026-05-26T00:02:25Z")
更新到 2026.4.1（[e404d9aabc](https://github.com/discourse/discourse/commits/e404d9aabc2cc9a7afed5cf5fad5f40b4617b746)）后，我在日志中看到了以下错误：
```plaintext
消息（已报告 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'
```
```plaintext
主机名 ip-172-x-x-x-app
进程 ID 286281
应用程序版本 3532c825824ee1259628545c7bd5311ecb918009
当前数据库 default
当前主机名 discussion.mcebuddy2x.com
消息 在执行调度管理器滴答操作时
时间 晚上 7:57
```
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2026年五月26日 01:35 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/2 "2026-05-26T01:35:35Z")
这很可能是您服务器的资源限制问题。当前内存使用情况如何？您能提供有关所运行 Droplet 的详细信息吗？
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [2026年五月26日 01:50 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/3 "2026-05-26T01:50:49Z")
这是一台专门运行单个 Discourse 实例的机器。似乎不存在内存或交换空间不足的问题。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2026年五月26日 01:53 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/4 "2026-05-26T01:53:15Z")
你上次升级 Docker、操作系统和 Discourse 镜像是什么时候？这三项是否都运行在最新版本？
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [2026年五月26日 01:54 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/5 "2026-05-26T01:54:17Z")
上周刚运行过 CLI/Docker 升级和系统更新。我会再试一次。
几周前的测试版运行时一切正常。这次问题是在通过浏览器升级选项从测试版升级到正式版后出现的。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026年五月26日 14:22 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/6 "2026-05-26T14:22:50Z")
请运行 `./launcher enter app` 并执行：
```plaintext
ulimit -u
```
这将显示允许的最大用户进程/线程数。
```plaintext
ulimit -a
```
这将显示所有资源限制。
```plaintext
cat /sys/fs/cgroup/pids.max
```
这将检查容器或系统 cgroup 允许的最大进程数（PIDs）。
* * *
现在使用 `logout` 返回到宿主机：
```plaintext
systemctl show docker | grep TasksMax
```
这将检查 systemd 是否对 Docker 服务设置了任务/线程限制。
```plaintext
systemctl show containerd | grep TasksMax
```
这将执行类似的检查，但针对的是 containerd 服务而非 Docker 本身。
```plaintext
docker inspect app | grep -i pid
```
这将检查你的 Discourse 容器的进程/PID 限制和设置。其中 `grep -i pid` 会过滤出所有包含“pid”的行（不区分大小写）。
> 如果你持续遇到错误，请将上述命令的输出粘贴到这里，这将非常有帮助。
---
### Author:  [@Lilly](https://meta.discourse.org/u/Lilly)
#### Post date: [2026年五月26日 14:23 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/7 "2026-05-26T14:23:49Z")
> [@Ethsim2](#):
>
> 能否执行 `.\launcher enter app` 并
>
> ```plaintext
>
> ```
`./launcher enter app`
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [2026年五月26日 14:40 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/8 "2026-05-26T14:40:58Z")
以下是相关信息，几乎所有内容都是无限制的
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [2026年五月26日 14:43 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/9 "2026-05-26T14:43:32Z")
通过命令行执行重建似乎已解决问题。我会继续观察。上周从 Beta 版升级到稳定版浏览器的操作可能是触发此问题的原因。
是否应对浏览器升级设置限制？浏览器升级能否检测潜在问题并标记或阻止升级触发？
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026年五月26日 15:07 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/10 "2026-05-26T15:07:06Z")
重建操作很可能重置了容器的 cgroup 位置，这可以解释为何它现在又稳定了。
鉴于最初出现了无法分配线程的错误，且其他限制（ulimits、TasksMax、Docker PIDs）均设为无限制，剩下的可疑因素是 PID cgroup 压力。
能否在正常负载下检查以下内容：
```plaintext
cat /sys/fs/cgroup/pids.current
```
\[1\]
```plaintext
cat /sys/fs/cgroup/pids.max
```
\[2\]
如果 `pids.current` 接近 2000+，而 `pids.max` 约为 2285，则表明容器在调度器/Redis 重连突发期间确实达到了 cgroup PID 上限。
这也解释了为何该问题仅在升级后出现（线程切换更频繁），以及为何重建操作能暂时解决该问题。
* * *
1. 当前容器/cgroup 内运行的进程数（PIDs/线程数）
2. 该 cgroup（即您的容器）允许的最大进程数（PIDs/线程数）
---
### Author:  [@RBoy](https://meta.discourse.org/u/RBoy)
#### Post date: [2026年六月18日 13:43 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/11 "2026-06-18T13:43:39Z")
差远了，目前只有 227，而最大值是 4194304。
---
### Author:  [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [2026年六月18日 16:27 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/12 "2026-06-18T16:27:55Z")
谢谢——这排除了重建后当前 PID 压力的问题。
鉴于 `pids.current` 仅为 `227`，而 `4194304` 是上限，容器目前肯定远未达到 cgroup PID 的上限。
有趣之处在于，之前的 `pids.max` 显示为 `2285`，而重建后现在变为 `4194304`。因此，重建可能重置了 cgroup 限制（即重新创建了应用容器），这解释了为什么目前没有发现 PID 耗尽问题的迹象。
* * *
如果错误再次出现，在故障发生时复制并粘贴以下命令的结果会很有帮助：
```plaintext
cat /sys/fs/cgroup/pids.current
```
```plaintext
cat /sys/fs/cgroup/pids.max
```
```plaintext
ps -eLf | wc -l
```
这将有助于判断故障是否由 PID 压力引起，或者我们是否应该从其他方面寻找原因🙂