Модель ёмкости и ресурсов
ThreadCells разделяет ёмкость, потому что работа агентов программирования в разное время может нагружать разные части хоста. Ход модели потребляет ёмкость провайдера; назначенный контекст программирования может оставаться активным, когда модель простаивает; сборка может насытить машину после прекращения вывода модели.
Обычно ускорения не даёт одновременное увеличение всех чисел. Оно может создать конкуренцию за квоту модели, давление на память, интенсивную работу диска и несколько дорогих сборок, соперничающих за один CPU.
Четыре лимита
Резидентные supervisor
Резидентный слот удерживает сессию supervisor или owner верхнего уровня, которая должна оставаться доступной между делегированиями и обратными вызовами. Он занимает резидентную ёмкость даже во время ожидания результата исполнителя.
Это выделено отдельно, потому что остановка выглядящего бездействующим supervisor может потерять контекст, отвечающий за интеграцию миссии.
Выполнение провайдером
Слот выполнения провайдером используется, пока модель/провайдер активно формирует ход. Существенны параллелизм провайдера, сетевая активность, число процессов и иногда память.
Агент, ожидающий в запросе, не нуждается в слоте выполнения провайдером.
Рабочие контексты
Слот рабочего контекста представляет делегированного исполнителя или reviewer, который сейчас владеет ограниченным контекстом. Он может удерживать управляемый worktree и полномочия writer, пока ждёт между ходами модели.
Корень сессии верхнего уровня потребляет резидентную ёмкость, а не ёмкость рабочих контекстов. Резидентный делегированный дочерний агент потребляет ёмкость рабочих контекстов.
Тяжёлые выполнения
Слот тяжёлых операций предназначен для ресурсоёмкой работы хоста: production build, запуск Chromium, большой набор тестов или сканирование всего репозитория. Допуск тяжёлых операций защищает резерв CPU, памяти и I/O.
Используйте канонический исполнитель тяжёлых команд для команд, которые подходят под это определение. Обычные небольшие тесты и просмотр файлов не требуют слота тяжёлых операций.
Начальная настройка по умолчанию
Поставляемая конфигурация 5 resident / 3 provider / 2 Work / 1 Heavy — консервативная отправная точка для небольшого хоста, а не benchmark или фиксированный лимит продукта.
Допустимый диапазон: 2–50 resident slots и 1–50 для каждого другого лимита. Значения сохраняются в runtime database и вступают в силу без перезапуска сервера.
Какие значения поставить на моей машине?
Начните консервативно, наблюдайте за давлением на память/диск и очередями, затем меняйте по одному лимиту за раз. Эти примеры показывают форму, а не гарантируют производительность.
| Пример хоста | Резидентные процессы | Выполнения провайдеров | Рабочие контексты | Тяжёлые операции | Обоснование |
|---|---|---|---|---|---|
| Малый VPS | 2 | 1 | 1 | 1 | Один supervisor и один ограниченный дочерний агент; дорогая работа выполняется последовательно. |
| Рабочая станция разработчика | 5 | 3 | 2 | 1 | Полезный параллелизм ходов модели при последовательных сборках. |
| Более крупный общий хост | 8 | 5 | 4 | 2 | Больше резидентных миссий и исполнителей с измеренным запасом для двух тяжёлых задач. |
Перед повышением лимита спросите, какая очередь действительно блокирует продвижение:
- Выполнения провайдеров заполнены, но CPU простаивает: рассмотрите ещё один слот провайдера, если позволяют квоты.
- Рабочие контексты заполнены при свободной ёмкости провайдера: выведите из эксплуатации завершённых подтверждённых дочерних агентов или осторожно поднимите лимит рабочих контекстов.
- Слоты тяжёлых операций заполнены во время сборок: второй слот помогает только если CPU, RAM и диск поддерживают параллельные сборки.
- Resident заполнен: закройте завершённые сессии верхнего уровня; не маскируйте брошенные supervisor одним повышением лимита.
Давление на память и диск
ThreadCells наблюдает за давлением хоста вместе с настроенными числами. Многие нативные CLI, панели tmux, процессы браузера, worktree, кэши сборки и журналы могут пережить короткий ход провайдера, который их создал.
Состояние диска использует точные пороги:
- GREEN: использовано менее 70 %.
- YELLOW: от 70 % до менее 85 %.
- RED: от 85 % до менее 92 %.
- CRITICAL: 92 % или выше. Агрегированный допуск остаётся RED и включает
причину
DISK_CRITICAL, а проекция, относящаяся именно к диску, показывает CRITICAL.
YELLOW — сигнал проверить рост и запланировать Обслуживание. RED может отклонять рискованную новую работу и допускать безопасную для восстановления очистку. Неизвестное состояние закрыто отклоняется; ThreadCells не считает недоступную для чтения файловую систему здоровой.
Явное решение в редакторе задач для уже резидентного рабочего процесса у ворот владельца также служит узким путём восстановления, когда RED вызван только диском: оно занимает обычную ёмкость провайдера, но не создаёт рабочий контекст. RED из-за памяти, PSI, неизвестных или смешанных причин по-прежнему закрыто отклоняется; сохранённый ход показывает причину ожидания восстановления ресурсов, не расходуя повторы транспорта.
Осушение после снижения
Снижение лимита никогда не убивает активную работу. Если текущее использование выше нового значения, эта категория начинает осушаться и отклоняет новые допуски, пока активное использование не снизится до лимита или ниже.
Пример: изменение лимита рабочих контекстов с 4 до 2, когда активны трое дочерних агентов, оставляет всех троих работающими. По мере завершения и вывода дочерних агентов из эксплуатации замена не допускается, пока использование не достигнет 2 или меньше.
Инвентарь тяжёлых операций продолжает учитывать активные слоты с номерами выше нового после снижения, поэтому изменение лимита не может скрыть дорогостоящий процесс.
Когда высвобождается ёмкость
- Ёмкость провайдера высвобождается при завершении активного хода модели.
- Ёмкость тяжёлых операций высвобождается при завершении зарегистрированной тяжёлой команды.
- Ёмкость рабочих контекстов высвобождается только после безопасного вывода делегированного контекста из эксплуатации.
- Резидентная ёмкость высвобождается при закрытии сессии supervisor/owner верхнего уровня.
Результат завершённого дочернего агента должен быть записан, доставлен, включён и подтверждён до вывода ресурса из эксплуатации. История сохраняется после высвобождения runtime capacity.
Допуск повторно проверяется на границах запуска и продолжения. Поставленный в очередь ход провайдера начинается, когда становится доступен слот провайдера. Завершение провайдера высвобождает только ёмкость выполнения провайдером; оно не закрывает открытый рабочий процесс, не отбрасывает обратный вызов и не освобождает делегированный рабочий контекст, который всё ещё владеет сохранённой работой.
Настройка и наблюдение
Используйте Settings → Orchestration Capacity для текущего использования, лимитов, рекомендаций и состояния осушения. Изменения ёмкости защищены Авторизацией оператора и аудируются.
Представление состояния в командной строке:
threadcells-resource-statusПосле изменения убедитесь, что UI и CLI совпадают. Лимит — это контроль допуска, а не обещание пропускной способности или sandbox нагрузки.
Распространённые ошибки
- Увеличивать каждый лимит, потому что одна сборка идёт медленно.
- Считать бездействующий worktree выполнением провайдером.
- Забывать о резидентных supervisor при выборе размера долгих миссий.
- Снижать лимит и ожидать завершения активных задач.
- Считать ёмкость GREEN доказательством доступности квот провайдера.
- Удалять runtime-файлы, чтобы освободить слот, вместо безопасного вывода из эксплуатации владеющего рабочего процесса.
См. Обслуживание о восстановлении диска и Рабочие процессы и сохранённые результаты о безопасном выводе дочерних агентов из эксплуатации.