2026.4.1 업데이트 후 스레드 할당 오류

RBoy · 5월 26, 2026, 12:02오전

최근 2026.4.1(e404d9aabc) 버전으로 업데이트한 후 로그에서 이러한 오류를 확인하고 있습니다:

Message (151769 copies reported)

Job exception: can't alloc 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	While ticking scheduling manager
time	7:57 pm

sam · 5월 26, 2026, 1:35오전

이것은 아마도 서버의 리소스 제한일 것입니다. 현재 RAM 사용 현황은 어떤가요? 실행 중인 드롭렛에 대한 세부 정보를 가지고 계신가요?

RBoy · 5월 26, 2026, 1:50오전

이것은 discourse 인스턴스 하나만 실행되는 전용 머신입니다. RAM/스왑 부족은 아닌 것으로 보입니다.

sam · 5월 26, 2026, 1:53오전

마지막으로 Docker, OS, Discourse 이미지를 업그레이드한 시점은 언제인가요? 이 세 가지 모두 최신 버전으로 실행되고 있나요?

RBoy · 5월 26, 2026, 1:54오전

지난주에 CLI/Docker 업그레이드와 OS 업데이트를 실행했습니다. 다시 시도해 보겠습니다.

몇 주 전 베타 릴리스에서는 정상적으로 작동했습니다. 브라우저 업그레이드 옵션을 통해 베타에서 릴리스로 업데이트한 후에 이 문제가 시작되었습니다.

Ethsim2 · 5월 26, 2026, 2:22오후

다음 명령을 실행해 볼 수 있을까요? ./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 · 5월 26, 2026, 2:23오후

./launcher enter app

RBoy · 5월 26, 2026, 2:40오후

여기에 정보가 있습니다. 거의 모든 항목이 무제한입니다

real-time non-blocking time  (microseconds, -R)  unlimited
core file size              (blocks, -c)  unlimited
data seg size               (kbytes, -d)  unlimited
scheduling priority         (-e)  0
file size                   (blocks, -f)  unlimited
pending signals             (-i)  7617
max locked memory           (kbytes, -l)  8192
max memory size             (kbytes, -m)  unlimited
open files                  (-n)  1048576
pipe size                   (512 bytes, -p)  8
POSIX message queues        (bytes, -q)  819200
real-time priority          (-r)  0
stack size                  (kbytes, -s)  8192
cpu time                    (seconds, -t)  unlimited
max user processes          (-u)  unlimited
virtual memory              (kbytes, -v)  unlimited
file locks                  (-x)  unlimited

file locks (-x) unlimited

root@ip-__________-app:/var/www/discourse# cat /sys/
fs/cgroup/pids.max

2285

docker | grep TasksMax
TasksMax=infinity

pect app | grep -i pid

"Pid": 640806,
"PidMode": "",
"PidsLimit": null,

@Ethsim2의 요청에 따라 관리자가 코드 블록에 내용을 포함하도록 편집했습니다

RBoy · 5월 26, 2026, 2:43오후

CLI에서 재구축(rebuild)을 수행한 결과 문제가 해결된 것으로 보입니다. 상황을 계속 주시하겠습니다. 지난 주에 베타 버전에서 안정화 버전으로 브라우저 업데이트를 수행한 것이 이 문제를 유발한 것 같습니다.

브라우저 업그레이드에 제한을 두어야 할까요? 브라우저 업그레이드 시 잠재적인 문제를 감지하여 표시하거나 업그레이드 트리거를 방지할 수 있을까요?

Ethsim2 · 5월 26, 2026, 3:07오후

재구축이 컨테이너의 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가 약 2000+에 도달하여 약 2285인 최대치에 가까워진다면, 이는 컨테이너가 스케줄러/Redis 재연결 버스트 동안 cgroup PID 상한에 도달했음을 확인시켜 줍니다.

이는 또한 문제가 업그레이드 이후에만(더 높은 스레드 턴오버) 발생했고, 재구축이 이를 일시적으로 해결한 이유를 설명합니다.

컨테이너/cgroup 내에서 현재 실행 중인 프로세스(PID/스레드) 수 ↩︎
해당 cgroup(컨테이너)에서 허용되는 최대 프로세스(PID/스레드) 수 ↩︎

RBoy · 6월 18, 2026, 1:43오후

전혀 그렇지 않습니다. 현재 227개, 최대 4,194,304개

Ethsim2 · 6월 18, 2026, 4:27오후

감사합니다 - 재구축 이후 현재 PID 압력이 원인임을 배제할 수 있습니다.

pids.current가 4194304에 비해 227에 불과하므로, 컨테이너가 현재 cgroup PID 한계에 근접해 있지 않다는 것은 분명합니다.

흥미로운 점은 이전의 pids.max가 2285로 보였으나, 재구축 후에는 4194304로 변경되었다는 것입니다. 따라서 재구축이 cgroup 한계를 초기화했을 가능성이 있습니다(즉, 앱 컨테이너가 갱신된 것). 이로 인해 현재 활성 PID 고갈 문제의 증거가 없는 것이 설명됩니다.

에러가 다시 발생한다면, 실패 시점에 다음 내용을 복사하여 붙여넣는 것이 유용할 것입니다:

cat /sys/fs/cgroup/pids.current

cat /sys/fs/cgroup/pids.max

ps -eLf | wc -l

이로 인해 실패의 원인이 PID 압력인지, 아니면 다른 곳에서 원인을 찾아야 하는지 확인할 수 있습니다🙂

글		댓글	조회수
New users can't sign up, 404 errors in console Support discourse-id	25	432	3월 18, 2026
"Cannot allocate memory" when upgrading Self-hosting server-resources	24	6361	5월 24, 2016
Redis Error after upgrade Self-hosting	13	1817	6월 3, 2020
Memory is running out and Discourse stops working Bug	74	14792	2월 17, 2015
Sidekiq is consuming too much memory, restarting Self-hosting	38	9253	10월 13, 2020

2026.4.1 업데이트 후 스레드 할당 오류

Related topics