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

**URL:** https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784
**Category:** Bug
**Created:** [26.Май.2026 00:02:25 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:** 1
**Showing post:** 10

<div class="post-metadata">

### Author: ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)
#### Post date: [26.Май.2026 15:07:06 UTC](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784/10 "2026-05-26T15:07:06Z")

</div>

Вероятно, пересборка сбросила размещение cgroup контейнера, что объясняет его стабильность.

Учитывая исходные ошибки «can’t alloc thread» и тот факт, что все остальные параметры (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+ при максимуме ~2285, это подтвердит, что контейнер достигал потолка PID cgroup во время всплесков переподключения планировщика / Redis.

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

* * *

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

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

---

_[View the full topic](https://meta.discourse.org/t/cant-alloc-thread-after-updating-to-2026-4-1/403784)._