Приложение не создаёт поток: проверяем TasksMax вместо памяти

Сервис сообщает resource temporarily unavailable при создании потока. Память ещё есть, файловые дескрипторы не исчерпаны. В Linux поток тоже учитывается как задача, поэтому приложение может упереться в предел количества tasks задолго до нехватки RAM. Особенно часто это видно после роста числа пулов и параллельных запросов.

Измерить число задач службы

systemctl show worker.service -p TasksCurrent -p TasksMax -p ControlGroup
ps -L -p 1234 -o pid,tid,stat,comm
cat /sys/fs/cgroup/system.slice/worker.service/pids.current
cat /sys/fs/cgroup/system.slice/worker.service/pids.events

Подставьте действующий PID и путь ControlGroup. TasksCurrent относится ко всей службе, поэтому оно может быть больше числа потоков главного процесса. В pids.events рост max означает, что создание задач блокировалось лимитом контроллера. Читайте также pids.max у родительских slices: ограничение предка тоже действует.

В описании pids controller отдельно объясняется учёт потоков. Это важное отличие от бытового понимания «не больше ста процессов»: один многопоточный процесс может занять сотни позиций.

Сравнить с другими границами

cat /proc/1234/limits
cat /proc/sys/kernel/threads-max
cat /proc/sys/kernel/pid_max

Max processes в limits — другой механизм, связанный с RLIMIT_NPROC и учётом реального UID, с исключениями для привилегированных процессов. Службы под одним пользователем могут влиять друг на друга через этот лимит. TasksMax через cgroup задаёт более явную границу для конкретного сервиса. Не меняйте оба значения одновременно: потеряете возможность понять причину.

Ошибка создания потока также может возникать из-за памяти под стек и служебные структуры. Если pids.events не меняется и число задач далеко от границ, вернитесь к точному коду ошибки и памяти. Текст библиотеки часто объединяет разные системные причины в одну фразу.

Определить нормальную потребность

Снимите число задач без нагрузки, при обычном пике и после его завершения. Если оно продолжает расти после завершения запросов, повышение лимита лишь отложит сбой. Найдите, какие типы потоков увеличиваются, и передайте данные разработчику. Возможно, каждый запрос создаёт новый пул или закрытие соединения не останавливает служебную задачу.

Если число стабилизируется и рост параллелизма оправдан, выберите TasksMax с запасом для пиков, но в рамках бюджета машины. Меняйте настройку службы через управляемую конфигурацию. Значение infinity снимает ограждение и требует отдельного обоснования; оно не является универсальным лечением.

Пример согласованного изменения

Допустим, TasksCurrent=256, TasksMax=256, а max в pids.events вырос с 0 до 40 во время нагрузки. После проверки пулов выяснилось, что нормальный пик требует около 350 задач и число затем снижается. Для стенда можно проверить отдельный drop-in:

[Service]
TasksMax=512

512 — бюджет для этого примера, не рекомендуемый общий стандарт. После сохранения конфигурации перечитайте её менеджером, примените изменение по процедуре эксплуатации и снова проверьте TasksMax, pids.max и ограничения предков. В контрольной нагрузке TasksCurrent достигает, например, 348, а max не получает новых событий. При завершении работы число возвращается к исходным 18. Именно эти три наблюдения подтверждают достаточность границы и освобождение задач.

Повторить тест до и после

Критерий успеха — ожидаемая параллельность достигается, счётчик отказов не растёт, число tasks после нагрузки возвращается к обычному уровню. Сохраните абсолютное число и приращение pids.events: накопленное старое событие не означает новый отказ после исправления.

Откройте программу Linux и Bash для DevOps-инженеров. Работа с процессами, systemd и диагностикой ресурсов нужна именно для таких случаев, когда сообщение приложения называет симптом, а реальную границу приходится искать в системе.

Ещё по теме

• Сервис пропущен без ошибки: Condition и Assert в systemd
• Плохой конфиг не должен запускать сервис: добавляем ExecStartPre