Не удалось выделить поток после обновления до 2026.4.1

Внести вклад Ошибка
1

После обновления до версии 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'

hostname	ip-172-x-x-x-app
process_id	286281
application_version	3532c825824ee1259628545c7bd5311ecb918009
current_db	default
current_hostname	discussion.mcebuddy2x.com
message	При выполнении цикла планировщика задач
time	19:57
2

Скорее всего, это ограничение ресурсов вашего сервера. Чем сейчас занята оперативная память? Есть ли у вас подробная информация о том, какой droplet вы используете?

3

Это выделенный сервер, на котором запущен только один экземпляр Discourse. Дефицита оперативной памяти или пространства подкачки, похоже, нет.

4

Когда вы в последний раз обновляли Docker, ОС и образ Discourse? Работает ли сейчас последняя версия по всем трём компонентам?

5

В прошлую неделю запускал обновление CLI/Docker и обновление ОС. Попробую ещё раз.

IMG2572
IMG25722233×899 382 KB

IMG2571
IMG25711170×537 68 KB

Всё работало нормально в бета-версии от нескольких недель назад. Проблема появилась после обновления с бета-версии на релизную через опцию обновления в браузере.

6

Можете выполнить ./launcher enter app и

ulimit -u

это покажет максимальное количество разрешённых пользовательских процессов/потоков.

ulimit -a

это покажет все ограничения ресурсов.

cat /sys/fs/cgroup/pids.max

это проверяет максимальное количество процессов (PID), разрешённое для контейнера или системной cgroup.

Теперь используйте logout, чтобы вернуться на хост:

systemctl show docker | grep TasksMax

это проверяет, установлено ли ограничение на задачи/потоки для службы Docker через systemd.

systemctl show containerd | grep TasksMax

это выполняет аналогичную проверку, но для службы containerd вместо Docker напрямую.

docker inspect app | grep -i pid

это проверяет ограничения и настройки процессов/PID для вашего контейнера Discourse. grep -i pid фильтрует строки, содержащие „pid“ (без учёта регистра).

Если ошибки продолжают появляться, пожалуйста, скопируйте и вставьте сюда вывод этих команд — это будет очень полезно.

7

./launcher enter app

1 лайк
8

Вот информация: практически всё без ограничений

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

Пересборка через CLI, похоже, решила проблему. Буду следить за ситуацией. Похоже, что обновление браузера с бета-версии на стабильную за последнюю неделю спровоцировало это.

Должны ли быть ограничения на обновление браузера? Может ли процесс обновления браузера выявлять потенциальные проблемы, отмечать их или предотвращать запуск обновления?

1 лайк
10

Вероятно, пересборка сбросила размещение 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, это подтвердит, что контейнер достигал потолка PID cgroup во время всплесков переподключения планировщика / Redis.

Это также объясняет, почему проблема проявилась только после обновления (более высокая смена потоков) и почему пересборка временно устранила её.

  1. Сколько процессов (PID/потоков) в данный момент запущено внутри контейнера/cgroup ↩︎

  2. Максимальное количество процессов (PID/потоков), разрешённое в этом cgroup (ваш контейнер) ↩︎

1 лайк
11

Далеко не близко: текущее значение 227 против максимального 4194304

12

Спасибо — это исключает текущее давление по PIDs после пересборки.

Учитывая, что pids.current равен всего 227 против 4194304, контейнер определённо не близок к пределу cgroup по PIDs прямо сейчас.

Интересно, что ранее pids.max составлял 2285, а после пересборки теперь равен 4194304. Таким образом, пересборка, возможно, сбросила лимит cgroup (то есть обновила контейнер приложения), что объясняет отсутствие признаков активной проблемы с исчерпанием PIDs в данный момент.

Если ошибка вернётся, будет полезно скопировать и вставить следующие команды в момент её возникновения:

cat /sys/fs/cgroup/pids.current

cat /sys/fs/cgroup/pids.max

ps -eLf | wc -l

Это покажет, вызвана ли ошибка давлением по PIDs, или же стоит искать проблему в другом месте🙂